Monday, January 27, 2014

Her

Anyone that knows me well knows that I love books and movies. I love getting entrenched in a good story line. I really and truly believe that a story, whether written or performed, can be a window into another persons perspective of the world. When taken in aggregation these stories are a really good way to get a pulse on the topics that are on the forefront of our global consciousness.

My wife and I went and saw Her by Spike Jones recently. This isn't going to be a movie review so it should be spoiler free. Instead this is going to be a commentary on a particular aspect of the movie. But I'll start off saying that Her is one of the best movies I have seen recently and I would suggest that you take some time to go see it.

The story-line has many levels to it and you can choose to invest yourself as deep as you'd like and still feel like you 'get it' when you walk out of the movie. I like these types of movies because I can watch them over and over and pick up on a new level to the story each time.

What really impressed me about this film initially is it's use of technology. The movie is set in the not to distant future. But honestly, the way Spike Jones made this it doesn't really matter when. He did such a wonderful job of making it feel like the future while also making it feel like it is our future. Most movies in the genre go too far, IMO, in trying to clue the viewer in that they're watching the future that they make me feel disconnected.

Her kept me feeling connected for a few reasons. First, the technology felt real. What I mean by that is that while most of the technology isn't really possible today it didn't feel like it would be too much of a stretch for us to get there from where we're at. Second, I think Her answers a question that we've been trying to answer for the past half decade. And that question is: what would it really look like to live in a world where we don't have to think about integrating our devices together? A world where the technology boundaries exist but don't feel present.

In the movie the main character is interacting with his operating system via an all-in-one computer at home, the cloud, a mobile device, and an ear piece very akin to how Ender and Jane communicate in the Enders Game series. This interaction is seamless and flawless in my opinion. The mobile device is context aware and multipurpose. At one point it's a second screen used to help illustrate a conversation, in another it's used as we would to check email, and yet in another it's a video input device used to provide context.

What makes these interactions really work is that I don't have to think about the interactions. I don't have to be aware of how the mobile and the all-in-one are connected. I don't have to think about how the cloud is setup (and neither do the characters in the movie). This movie really does a good job of positing what the world could look like if we continue down the path of always connected while simultaneously fixing our current problem of integration. It makes this a world I could imagine living in and enjoying.

Monday, January 20, 2014

Encrypting and Decrypting local files

One thing that I love about living in the internet age is the fact that I can have access to my information from almost anywhere in the world on any device. Some benefits of this are being able to listen to my music or watch my movies on many devices any time. I'm able to use a password manager (like KeePass) so that I can use strong passwords and take them with me so I don't have to remember them.

Often I find that I want that same convenient access to files that contain sensitive information (like bank account numbers) and such. Of course I don't want these files readable and accessible to just anyone and I honestly don't trust putting them in something like DropBox where they're supposed to be encrypted but I don't know how well their security is managed.

Like my music and my movies the convenience of being able to access these files from anywhere is a must. So what I've chosen to do in order to keep these files secure and publicly available to me on the internet is to encrypt the individual files.

This is actually not a really difficult thing to do because of OpenSSL. OpenSSL is available on most (if not all) *nix distributions as well as being available as a Windows Package.

To encrypt a file using OpenSSL you would do the following:

$ openssl des3 -salt -in "SOME_FILE" -out "SOME_FILE.encrypted"

To decrypt that same file using OpenSSL you would do the following:

openssl des3 -d -salt -in "SOME_FILE.encrypted" -out "SOME_FILE"

Monday, January 13, 2014

Learn To Say 'I Was Wrong'

If there is one thing over the past decade plus that I've learned that has helped me to succeed it was learning to say I was wrong.

I think there's a bad stigma associated with admitting you're wrong. I think most people tend to believe that if they admit they're wrong they're admitting that they're weak, that they're not as good as their peers, or that they don't know enough. I think this is especially true in the technology industry.

As a professional technologist I'm competing against people that are younger, people that are older, people that have more experience, people that have better educations, people that have better intuition, and so on and so on. I'm constantly comparing myself to my peers and to the people I want to be my peers. That doesn't lend to an atmosphere where it feels like it is okay to be wrong.

Being able to admit you are wrong helps you build trust. It sends the signal to others that you're a person that puts doing the correct thing ahead of your own pride. It gives people insight and clarity into your intentions.

Being able to admit you are wrong is a sign of maturity. As humans one of the ways we learn and course correct is by looking back at things we have failed at . We analyze the situation identifying what we did correct and what we did incorrect and then trying to do more of what we've done correct. When you are able to admit you were wrong what you're doing is showing others that you are aware of this process and that you are actively trying to learn from your mistakes.

One of the best benefits of being able to admit you are wrong is that you'll no longer have to continually say I was right. Constantly having to tell people you were right in a situation is a sign that you're not owning up to when you were wrong. It's a sign that you feel the need to justify your position. Once you've gained trust and you've gained empathy you will have built trust in your skills and your decision making ability. You will have less stress from having to worry about what people think of your choices because your transparency will lead others to be more transparent.

Sure, there are going to be folks out there that are going to try to take advantage of this. But what I've noticed over the past decade plus is that once you set the expectation that you're a person that can admit fault or wrongness people are willing to help defend your right to be wrong. I believe this is because they want to work somewhere where it's okay to not be perfect.

Another positive outcome of admitting you were wrong is that you'll receive better constructive criticism. People will be less focused on trying to get you to realize that you were wrong and will start to focus on helping you understand and learn from why you were wrong. You will then have the ability to take that constructive criticism and learn from it. All the while you're gaining trust and empathy for you.

So next time you're confronted with having made a bad decision, the incorrect choice in technology, or whatever try admitting you were wrong and then commit to using what you've learned by being wrong to be better. You're company, your project, your team, and your career will all benefit from it.

Monday, January 6, 2014

The Intelligent Code Completion Nightmare

The other day I wrote a blog post on why I don't use a traditional IDE. If you haven't read you go check it out. I got an interesting email response (a comment would have been better) from a friend of mine about a particular part of that post; Intelligent Code Completion. Here's what my friend had to say about ICC.
I am arguing against the idea that it either discourages or encourages the learning of a new system - instead, it can assist with either!"
my argument is basically that one's desire to grok a particular system is a personal one, driven by various motivations ("to each his own"?), and that although ICC makes it easier to avoid diving into the nuts and bolts, it greatly helps those that do want to learn
After reading this I can see that my argument against ICC is one sided. It only focuses on the negative side of ICC. That's mostly due to the fact that, in my experience, I've seen it have a negative impact on more people than it's had a positive impact on. But my friend is correct that it can be used as a tool to help those who truly want to learn.

I think I understand why I've seen it have more of a negative impact than a positive one. I think that people tend to fall into 4 general categories when it comes to learning.
  • Want to learn and are disciplined
  • Want to learn but are not disciplined
  • Don't want to learn and are disciplined
  • Don't want to learn and are not disciplined 
People in the first category are the folks that you interact with that "just get it." They're the ones that tend to grok things quickly because they've learned discipline around learning and have become efficient at it and have learned how to learn things that are difficult for them. These people are VERY successful in their jobs. I think this group makes up like 5% - 10% of the average software development shop. These people benefit from ICC.

People in the second category are people who "are hard workers". They tend to understand systems but it takes a lot of work. Usually a lot of trial and error. These people tend to gravitate towards particular types of learning (learn by example, classes, learn by reading, etc...). These people are successful in their jobs. Some of them are really successful and some are just mildly successful. I think this group makes up anywhere between 50% - 70% of the average software development shop. These people are, in general, hindered by ICC but believe that it helps them. They are not typically aware that it takes them more effort to learn because of their lack of discipline.

People in the third category are the people that "just get by". They don't tend to make it very long in any particular organization. They stay for a year or so before they get fired or they get frustrated and leave. They tend to be satisfied finding solutions to their work on Google or Stack Overflow and leave it at that. They don't typically dive in to find out why the Google or Stack Overflow answer works. They're pretty efficient at finding the answer though because their discipline helps them out. These people are hindered in the long run (i.e. growing in their career) by ICC but are helped in the short term. I think this group makes up anywhere between 20% - 30% of the average software development shop.

People in the last group are just there to collect a paycheck. They don't really care about technology, they only care that technology jobs pay well. ICC actually helps these people stay in their jobs because it removes some of the tediousness of learning. ICC hinders their employers in rooting them out and moving them on sooner because they can do just enough to get by. I think this group makes up like 5% - 10% of the average software development shop.

Because the second and third category of people make up the vast majority of people in the office, and are in general hindered by ICC, I tend to see ICC as a negative.

What are your thoughts?