Advice for a Younger Me

Today is my work anniversary; I've now been programming professionally for three years. I've learned quite a bit and desire to learn even more. Without a doubt, I absolutely love being a programmer and want to continue doing it for a very long time.

Looking back, I'd tell a younger Tom (or anyone else new to the field) the following:

• Learn the Single Responsibility Principle and DRY (Don't Repeat Yourself) and let them guide how you write code.
• Unit test, unit test, unit test, and unit test some more.
• If you're writing .Net code with Visual Studio, you must use ReSharper.
• Don't be afraid to ask questions. Be comfortable with what you know; be even more comfortable with what you don't know. Realize your shortcomings and always desire to get better.
• The software industry demands constant learning, and if you're not trying to continually improve and learn new things, your skills will stagnate and become outdated in three years. You're in control of your career, so don't expect management or anyone else to push you along.
• Don't be afraid to change code. Make small, incremental changes and don't fret or over think it, as you'll most likely be changing it again shortly. You only have to worry about changing code when you know it will be the final time you touch it - which doesn't happen when you accept the mindset of incremental development and refactoring.
• Speak up and voice your opinions (respectfully, of course).

Got any more advice for a younger Tom - or current Tom?

Software Companies vs Companies That Make Software

There's software companies, and there's companies that make software. These sound the same, but they are actually different.

Software companies:

• Value developers and put them first. For instance, they realize that developers require top-of-the-line computers and thus don't give them the standard-issue computers that everyone else in the company receives. This appreciation often stems from the fact that management and other higher-ups were once developers themselves.
• Recognize the uniqueness of software and don't try to blindly apply management techniques and processes transplanted from other industries. They may use ideas from other industries but adapt them to specifically work for software development.
• Realize that software development is a rapidly-changing industry and thus actively encourage and facilitate continuous learning.
• Have employees who willingly maintain up-to-date technical skills and awareness of industry trends. Even managers and others who don't write code every day still have relatively sharp technical skills.
• Fully leverage all available technologies and paradigms and aren't afraid of making changes when appropriate (when they know the change should lead to improvement), as opposed to sticking to a certain technology or process simply because that's what has been used in the past.
• Value and exploit innovation by creating environments that foster design thinking and creativity from all employees.

I think you're getting the gist here. Companies that make software treat the creation of software as they would any other product or service, but software companies tailor their decisions, culture, business processes, and everything else specifically to making software. I don't know about you, but I know what kind of company I want to work for.

Doh!

A few days ago I experienced the most embarrassing moment thus far in my career. I was trying to figure out why our Outlook addin wouldn't load correctly. I had spent parts of the previous two days looking into the issue but was only making slow progress. I narrowed it down to the fact that our bootstrapper wasn't executing and was thus trying to determine how some third-party code or weird COM issue might be causing this to occur. That's when I noticed the following in one of our classes:

//bootstrapper.Run();

That's right, the bootstrapper wasn't running because that line of code was commented out. Seriously.

I feel silly that it took me that long to identify the problem. It made my debugging ability and troubleshooting skills look amateurish. I think one of those monkeys that can move robotic arms with their minds could have identified the problem sooner.

But that's not the worse part. I actually saw that line of code the day before and didn't think anything of it. At that time I checked the log for our code repository and noticed that the lead developer for the addin was the one who made the change, and the comment for that commit indicated that it was for some fix. Thus I didn't think twice about the commented out code. So not only did I struggle to find an obvious bug, but I could have found it much sooner if I had thought critically and not have blindly accepted things. Just downright stupidity and laziness on my part - and that's what's so embarrassing.

At the very least I need to take this as a learning experience and remind myself of some important things:

• Actively question things; don’t just take them for granted. The person who committed that commented-out line of code is a much better programmer than me, but that doesn't mean he isn't capable of making mistakes. I should have saw that line of code and discussed it with him instead of automatically assuming it was correct.


• The simplest explanation is usually the most likely and the best. The addin was working not too long ago, and then stopped working. Instead of digging into third-party stuff, I should have taken a step back and looked at the recent changes to the addin, as the simplest explanation is that one of our team's changes caused the problem.


• Don't commit prototypes and other exploratory code into the production codebase. That commented-out line of code was actually part of a prototype, and if it would have been committed to a separate branch instead of the production code branch, this issue never would have occurred (and I wouldn't have looked so stupid). Prototypes typically aren’t written with the same rigor and level of quality as production code, so the two shouldn’t be mixed.


• Commented-out code is terribly misleading and a waste of space. If the code is not needed, then just delete it. This point doesn't really apply to the abovementioned situation (and in fact, having that line there probably cut down on the time it took to identify the issue). Nonetheless, commented-out code is confusing and should thus be avoided.

Thoughts On My First Pair Programming Experience

I work for a company that does not pair program (at least not in recent memory). However, after listening to some people advocate pair programming, I wanted to attempt it and see whether it could be useful within our company. My boss allowed me to try it out this release, and another developer graciously agreed to pair with me for a couple of weeks. Thus I wanted to provide my initial impressions of the experience.

• We moved faster than a single developer (based on estimates), but we weren't twice as fast. I'm not sure how much more quality the two of us combined added, in terms of things like bugs being found earlier (particularly logic bugs), better designs being uncovered, and better practices being followed, but I suspect that, in general, working together did produce better software. Eventually I'd like to try to do some more objective analysis around this.
• Pair programming absolutely helped with focus. Not only was I able to focus faster (the "activation energy" that Amy once described), but I was also able to maintain my focus for much longer. I'd start pairing, and then two or three hours would fly by without me even realizing it. This improved concentration is great, but it also would be nice to find a better balance, so that I'm not delaying other time-sensitive tasks or tiring out faster from the exhausting demands of long, intensive focus. I was thinking of trying something like the Pomodoro technique, where I’d work for 25 minutes and then break for 5 minutes or work for 50 minutes and break for 10.
• Knowledge transfer seemed to flow seamlessly during our work, as opposed to being a disruptive act (like when a developer has to interrupt another to ask a question). My partner was able to acquaint me with parts of the codebase much quicker than I could have done myself, while I think I was able to give him a better understanding of TDD than he had before pairing.
• It's become obvious to me that pairing demands strict discipline from both developers, and it's pointless to pair if the two agree to cut corners, ignore good practices, or do anything else to compromise quality.
• On a selfish note, I really missed putting on my headphones and listening to 4-7 albums a day. It would be nice to incorporate music into the pairing session. Also, if you use disposable cups like my partner and I did, make sure you each label your cup. And interestingly, I found that my partner was particularly agreeable with my ideas on the day I used a steak night to cut an apple (yes, I was paring while pairing).

Despite neither of us having any experience or much knowledge about pairing, I think our initial attempt was a positive one. I certainly agree with this post, which asserts that you can't force pair programming on a team, as the successful adoption of pair programming requires that the team actually have an interest in legitimately trying it. Pairing is definitely a major change, and I wouldn't want others to be required to do it without them first trying it out and personally approving it. And as for my company, I can't imagine us suddenly adopting pair programming for all development, but I wonder whether there are certain situations that are well-suited for pairing. Perhaps at the start of a release, when two programmers can work together to get one of them up-to-speed on a codebase. Or maybe on a piece of functionality that is complex, risky, or larger in scope, where having an additional opinion and another set of eyes might yield a better design and more quality than a single person could (and then later the two programmers could break out to do smaller, lower-risk tasks on their own). I also think having new hires pair with someone else for a release would be useful, but this is more teaching/shadowing and not really pair programming, where both developers are actively participating.

I had fun pair programming, and I encourage others to at least try it.