Get Off My Lawn! (Code Ownership)

Ever met a programmer that is territorial about his or her code? Are you that programmer? I’m going to take a couple of minutes to explain why I think that’s a bad idea.

First, let’s consider why a programmer might want to keep other programmers out of “their” code (or, at least, what I assume is their reasoning when I encounter it.)

In order of suspected likelihood:

  1. They don’t trust the other programmers on their team.
  2. They don’t have confidence in their own abilities and are afraid of getting “found out.”
  3. They think that being the only person that understands a particular piece of code grants them job security.

Assuming one of the reasons above is why a person wants exclusive code ownership, here is what they might be missing:

  1. If you don’t trust your team members, you should find out why you feel that way. Perhaps it is an opportunity to mentor someone. This is as beneficial, if not more, to you as it is to them. You gain better understanding of something when you teach it. Also, any decent manager will recognize the value of an employee that improves the people around them.
  2. If you lack confidence in your abilities, maybe you need a mentor. It is much easier to improve if you enlist the help of others trying to reach the same goal. Also, if you involve others and the code ends up failing, the blame is shared by the team and not just you.
  3. Nobody is irreplaceable. I don’t care how good you are or how much you know, there is always someone else that can pick up where you left off. Actually, the easier it is for someone else to learn your code, the better job you did. The reverse is true, too.

One last thing. If you’re working for someone other than yourself, the code probably doesn’t belong to you anyway. It belongs to whoever paid for it.

Failure as a Catalyst for Growth

Several years ago I was contacted by a recruiter from Google. I was really excited and incredibly humbled that I had even been noticed by a company with their reputation. So, I pulled out my Cormen book (Introduction to Algorithms) and started franticly working through random problems using an IDE. My preparation was not only incomplete, but it was also ill-conceived. My naivety and lack of adequate preparation got me about as far as you might expect: nowhere.

Until recently, I only told a few people about this experience. I was embarrassed. I had failed. The funny thing was that I felt like I was at the top of my game at my current job. I had solved some memory management problems that were plaguing our product. I had been the champion for introducing automated testing to our team’s products. My yearly reviews indicated that I was doing exceptionally well. So, where was the disconnect?

The company I was working for afforded me many interesting projects. I even got to work on some machine learning code. Unfortunately, I hadn’t spent a lot of time thinking about how I would explain that work to a non-coworker. Instead, I ended up responding frequently to questions about my resume with: “I don’t remember the details.”

Next was a coding problem. It wasn’t a very hard coding problem. However, there were a few things that I hadn’t rehearsed that made things difficult.

1) I had been practicing in an IDE with code completion and didn’t realize how much I had been relying on it. I had to write my code in a basic text editor, so I didn’t have all my fancy productivity tools like autocompletion.

2) I had not practiced talking about what I was doing as I was doing it. It turns out that this is something that isn’t hard to master with a little practice.

3) I didn’t work nearly enough problems when I was preparing.

As soon as I hung up the phone with the interviewer, I pulled up my IDE and spit out a working solution in 5 minutes. I was so angry with myself.

Of course, this isn’t the end of my story. It turns out that nothing in my career, to this day, has motivated me more than this single experience. I started buying and reading lots of software development and computer science books. I had missed out on so much! I wish I had found Clean Code, The Pragmatic Programmer, and Code Complete when I was in college. But, there is no point in dwelling on the past. I needed to have these gaps exposed in order to fill them.

In an interview years later, I was told by an interviewer, “You should be careful about putting big words like ‘Metaheuristic Optimization’ on your resume because someone might ask you about that.” I was able to confidently respond with, “I came prepared to talk about that in as much detail as you’d like.” I was disappointed when the interviewer’s response was, “No, no need for that.” However, I did get a job offer after that interview.

All this to say, don’t be discouraged by your failures. Seize them as an opportunity to improve. If you aren’t failing frequently, you probably aren’t growing, so make sure to challenge yourself on a regular basis.

Growth Mindset

One of the main themes of this blog is learning. A lot of people, including myself, were raised with the understanding that IQ is fixed and that you do the best with what you’ve got. I didn’t realize how limiting that belief was until I discovered that it wasn’t true! More and more research is showing that we are, in fact, able to increase our intelligence.

As it turns out, one of the most helpful things you can do when trying to increase your intelligence is to simply believe that you can. One thing that I’ve observed during my career–and, I am sure is documented by many other sources–is that the people who solve the most insurmountable problems are the ones who don’t know that they are impossible. It seems that the older I get, the harder it is to not quickly dismiss something before giving it a shot. I can’t stress the importance of overcoming this “sad path.” Just try it! You may be very surprised at the result.

Another key factor is learning to embrace failure as merely another mechanism for learning. By pruning the decision trees that represent things unknown to us, we gain a much deeper understanding of whatever it is we’re seeking. In other words, to better understand what is, it is helpful to understand what is not. All those failures start to work like gutter guards (you know, those things that we use to help children learn to bowl) to keep you on a path to success.

Embracing failure as a learning opportunity is a very important part of something called a growth mindset. I first encountered the growth mindset while taking a MOOC taught by Jo Boaler, a renowned professor at Stanford, on learning and teaching math. I highly recommend her course, How to Learn Math. In the course, she talks about some of Carol Dweck’s work, which ended up being a jumping-off point for me. Also, Khan Academy, one of my favorite resources, is also endorsing the growth mindset. Check out their short video about it here.

Do yourself a favor and do a little digging for yourself. Start with the video I linked above and then maybe see what you can find out about Carol Dweck and her research. Check out Jo Boaler’s blog. Get inspired!

Who the lit the fire?

It had been my intention for years to create a blog so that I could share all the interesting things I was learning in my software development career. For whatever reason, I never mustered the required energy to follow through. Enter John Sonmez of simpleprogrammer.com and his free email course on how to start your own blog.

John’s course lays out everything you need to know, step-by-step, to get your blog started and on its way to success. Setting up the blog, in the unadulterated words of Saliva, was as simple as “click, click, boom!” (as I typed that, I felt the immediate need to apologize.) After getting things set up, he shows you how to prepare so that it is easier to maintain momentum as you build your content. And, finally, he shares some tips on how to grow your audience. The coolest part, in my opinion, was the personal encouragement I received from John. What a guy!

I am also about halfway through John’s new book, Soft Skills: The Software Developer’s Life Manual, and recommend it to any software developer looking to up their career game. (And who doesn’t want to do that?) The book is very accessible and chock-full of information that I really wish I had 10 years ago; don’t worry, the information is every bit as valuable today.