The Unselfish Programmer

Like many out there, I started programming at an early age, maybe 15. So that means I started sometime in the mid 15th century with a computer built from spare parts and the March issue of Popular Electronics.

I cut my chops at Wolfram Research, and then moved on to a larger company, and quickly ran to a startup. It wasn’t just the dotCom that was the lure, it was the vibe of a small company. Jack of all trades. Brilliant people. Crazy deadlines. Do or die. It doesn’t get any better than that. You do learn quickly that going fast has issues, chaos ensues, and without managing that chaos, you end up in an unhappy place.

Over the last five years or so I’ve found myself in the world of management, Manger, Director, VP and CTO. I think anyone who has busted their ass from the lowest rung on ladder to the boardroom has a different perspective — thoughts on what works, and what sucks — but more importantly WHY.

I like to think of myself as someone who learns from their mistakes, or even just from their experience. I believe reflection is the key to management. The way to succeed going forward is to measure both success and failure with any project, tie it to key events or metrics, and apply it going forward toward a goal. To that end I look at making my team happier, more efficient and less prone to error. I want folks joining my team to get up to speed quickly and contribute. I want the company as a whole to never think product and development are the bottlenecks to being successful, but instead are the resource to leverage to make ideas come alive and implement strategy.

It’s funny, I bring people on my team and they reminisce about their last job where they laugh and say “Noone wanted to touch that code”, “it was impossible to maintain”, “it didn’t work”, “we had five libraries that did the same thing” or “we kept changing things so we never finished”.

Ahh, if I had a dime for every time…

Over the years methodologies come and go, waterfall, XP, agile, whatever, and after doing alot of research and watching my own teams in action, I’ve come to a single simple conclusion:

Successful software is made by being unselfish..

Here, successful is defined as software that

• does what it is supposed to do
• is easy to maintain
• is easy to change
• is easy to learn
• is not the bottleneck for the business
• doesn’t scare the shit out of the people working on it

The less impact any change has on others or the system as a whole, the more unselfish it is.

The more burden an individual takes on to reduce the impact on others, the more unselfish it is.

That about sums it up. This blog is dedicated to the furtherment of those principles and how they can be applied in successful software development.