The Common Denominator of Successful Programmers

by Dana H. P'Simer

Sat, Jun 27, 2009


I just read The Common Denominator of Success by Albert N. E. Grey. Please take the time to read it now as I will be referring to concepts in it. My boss, Ashley, had suggested it as an inspirational piece. As I read the piece I was struck by how relevant it is to so much more than just Life-Insurance salesmanship. As he discussed some of the things that insurance salesmen do not like to do I started to list off in my head the things that Programmers do not like to do but should do if they want to be successful. When I read about how having a purpose makes the formation of these habits possible I started to think about what purpose a programmer would need to make forming the habits of successful programmers possible.

I consider myself a successful programmer. I have been working in this field since 1988 and have programmed in many environments and languages. I have held positions ranging from junior programmer to architect. I have written software that received awards from prominent publications and software that only a handful of people ever saw but generated significant revenue for my customers. If you are interested you can find a copy of my resume in the "People" section of this site. I have found that many of the things that I do out of habit my less successful colleagues resist doing. I have always been frustrated by this. Mr. Grey's article has given me some insight into why it is that people do not do the things that are required for success.

How can we, programmers, measure success? For insurance salesmen it is easy to measure success because the amount of money earned is directly proportional to the success of the salesperson. For programmers the story is more complicated. Success can be described in many ways. For some applications, the revenue generated by the application may very well be a good measure. However sometimes applications that make money do so despite significant flaws in the application. Another way to measure it is by looking at the numbers of bug reports and enhancement requests. Still another way could be to look at your own personal income since, generally speaking, better programmers get paid more money. Yet another way to look at success is in terms of time to market. Many applications are extremely sensitive to time to market and therefore the speed with which a product can be brought to market can determine success vs. failure. I think how you measure success depends on your purpose.

I currently work as the Technical Lead for a development group at IHG. IHG is the largest hospitality company in the world but you may never have heard of them. However, you have heard of our brands. Holiday Inn is one. As well as Holiday Inn Express, Crowne Plaza, Intercontinental Hotels, Candlewood Suites, Staybridge Suites, and Hotel Indigo. We get daily revenue reports from our VP. He obviously measures our success, at least in part, by how our revenue numbers match our target numbers. Since our group is responsible for all revenue generating technology channels, that is a fair way to measure our success. One way I, personally, measure our team's success is by keeping an eye on the number of defects that impact revenue.

How you measure success will depend, significantly, on what your purpose is. I will get back to that later down the line.

To apply the "tagline" at the top of The Common Denominator of Success we need to ask what do successful programmers do that failures do not like to do and, therefore, do not do? A number of things come to mind immediately. Like testing, code reviews, and documentation. However, I think two words sum up the habits that successful programmers have: Verification & Planning.

Successful programmers seek verification that their code works as intended. This takes the form of unit tests using tools like JUnit or TestNG, for Java. It takes the form of code reviews, design reviews, and just reaching out to our fellows to bounce ideas around. It takes the form of gathering/identifying requirements. Many of these tasks are tedious and time consuming and seem to eat up precious time to get other things done. However, those that form the habit of doing these things fit them into their normal flow of work and can therefore save the time that will be spent tracking down an elusive bug that could easily have been caught by good unit testing or a code review.

Successful programmers plan their activities. I am not talking about hyper-planning. I am talking about simple things like creating some form of requirements, creating a design that lays out what changes/new code needs to be written and how that code is to be laid out. Also, they plan how their software will be verified and how it will be documented.

Planning can also include developing tools and automation techniques that make the development of your software easier. Giving thought to how you will build and deliver your application can save hours, even days, later on down the line. The process of determining what tools will be used for development can be essential to success. Many programmers do not take the time to learn their tools, either. They learn just enough to get the code they write compiled and deployed. However, sometimes knowledge of the tool can be essential to success or allow you to cut time when it is of the essence.

Planning and Verification feedback on one another and that feedback is essential to successful software development. Just as successful programmers plan to verify they must also verify their plan. This means reviews by competent colleagues. This does not need to be a terribly onerous process.

In a previous engagement I worked for a medical device company, ResMed, and we developed a medical telemetry system for them that would transmit CPAP usage data using the narrow-band PCS wireless network. We had a device that would attach to the back of the CPAP machines and we could send queries to the device to retrieve data. As such, this product fell under the regulation of the FDA as a medical device and we had to obtain 510(k) approval to market the device in the US. The documentation requirements for software developed under 510(k) regulations are extensive. However, we devised a way to meet these requirements without creating a ponderous and onerous process. One example of the kind of documentation that was required was that we needed to devise testing plans for all features of the system. These testing plans needed to be reviewed by qualified colleagues and then executed by a member of the team other than the feature's developer. We accomplished this using ticketing system with some custom workflow capabilities and notes added to the feature/bug's ticket. Very simple and easily reproduced.

Now, back to purpose. What is the purpose that drives us as Programmers? A the end of The Common Denominator of Success, Mr Grey gives an example of a young man that he met whose purpose was to give his family a better life then he, his mother, and his sister had. If that is your purpose, then your measure of success must be the amount of compensation you receive. This is a good purpose. It has the emotional context that Mr. Grey says is necessary to carry us past our needs. It is certainly one of my purposes.

Let's be frank. Most of us work for businesses. Businesses do not write software because they like to. They do it either because they hope to generate more revenue or reduce their costs. They enter into the endeavor with an understanding that paying for the development will be out weighed by either the revenue generated or the costs saved. Therefore, the measure of success of a software solution is its impact on profit. Given that, the best way to reward the people who write the software is to give them money. There is an equilibrium between software costs and software benefits. The higher the benefit the higher the potential compensation. To maximize compensation one must know the market in the area they are working. Even the best programmers will find it hard to command compensation well outside the going rates in the local market. Even if the profit impact of the software being written is very high. How does one command the highest range of compensation? They must demonstrate through their previous work experience that they are capable of a high degree of productivity. They must also interview well and, once on the job, perform beyond expectations. To do that, one must make a habit of things which they do not like to do.

Another purpose that drives me and has just such an emotional context is my desire to leave things better then how I found them. I feel that it is the impact our life has on those around us that is the measure of our life. I am a programmer and therefore the best way for me to impact those around me is through that skill. This does not mean that I wish only to improve the code. I also wish to improve the coders. Those men and women I have been privileged to work with in this endeavor we call programming, I hope, are better programmers because of my example.

I encourage you to find a purpose that drives you beyond your needs and supports you in developing the habits necessary for success, whether you are a programmer or an insurance salesperson.