Software Professionals vs. the other guys

As many of you know, I started a new job within my company on May 1st. And whenever you start a new job, one of the first things to do is to figure out who the “go to” guys are. The “go to” guys are the ones with excellent technical skills, a desire to do things the right way, and a desire to help others in the organization. These are the guys Managers tend to rely on. Major customer outage has taken out most of the telecommunications in Europe? That’s a problem! What should the Manager do? Ah, the answer is obvious; get “go to guy #1” on the first plane to Europe. And so the Manager congratulates himself for having the wisdom to know what to do.

In my profession (software development) the “go to” guys tend to be consummate software development professionals, rather than just guys who program computers for a living. Some of them program 8 hours a day and some of them program every waking hour. Professionalism has nothing to do with a computer obsession and it has nothing to do with social skills.

This can lead to some funny things happening. For example there was someone I will call “R”. We had problems with a standard library we obtained from an internal development group. They were unable to fix the problem. I came into work one Monday morning and found the problem had been fixed. Over the weekend, “R” hacked his way into the source code repository of this group in another country, learned the code base without the benefit of documentation, made the fix, did the unit testing, checked it in, and sent a bill to the group whose code he had just “adjusted”. OK, a touch of arrogance, but remember that “R” spent his weekend doing this, and he worked in a different group!

We also had a major problem with a program. I won’t go into details, but it was a problem we had been avoiding for years, and now it had to be fixed. So the Manager puts on his thinking cap and decides “M” would be the right person to solve the problem (congratulating himself on his wisdom for picking “M” for this job). We cut “M” his own source code stream, he went away for 9 months, and comes back with 1800 files (perhaps several hundred thousand lines of code) that needed to be checked in. This of course led to a dilemma. Normally we would require extensive code inspections by a team of trained inspectors, ut by doing so we would use up every available programmer for the rest of the release. Clearly unacceptable. At this point however I reminded myself that this was 1800 files that “M” was responsible for. So I threw open the source code repository, and he fired off his script (he wasn’t going to check in the files manually so he wrote some enhancements to our source code repository). The changes built without a problem, and as I recall there were only 2 bugs ever attributed to this massive code change.

So today I was talking to “K”. From speaking to him, clearly he was a consummate professional when it comes to programming. He now works in the test group, but he’s still a “go to” guy for them. When necessary we fly him out to some of the biggest companies in the world. Anyway, we got onto the topic of software professionalism. It was a short but interesting discussion. We discussed such techniques as design for testability, understanding the performance of your algorithm before you start coding, and degraded modes of operation. And that led me to think about some of the other practices of true software professionals. I don’t mean, build before you check in or using debuggers. I mean the design principles that separate true professionals from people who program for a living. So what separates the professionals from the other guys? Comments are welcome.