A recent meme running on programming sites across the Web is a generally humorous discussion of the attributes of bad programmers. If we put aside the humor everyone has a war story here in my experience, bad programmers fall into two main categories: the dim and the reckless. The dim ones generally have a small skill and are unaware of its limitations. They generally avoid deep technical conversations, but when they do speak, they often greatly overreach in the estimation of what they’re capable of doing or what they know. Curiously, I regularly receive article manuscripts from these folks (“Want an article on building your own DBMS in less than 100 lines of JavaScript?”) and it’s difficult to respond courteously to the proposals, so I often beg off by simply citing that the pieces are not what we’re looking for.
The other group, the reckless, consists of those who have the skills but don’t have the discipline. They are the cowboy programmers of yore. They code according to their own desires, do nothing to integrate their work with that of others, scrimp on basic discipline, and cause work for other team members. Fortunately, this model is dying out (somewhat too slowly) as IT becomes aware that their cost is rarely ever offset by their benefits.
I guess you could add a third grouping of folks, the jerks, who wield their roles so poorly that they drag down the entire team. They often come from one of the other two previous groups, but have been given enough responsibility that they can make life miserable for others. The only solution when faced with them is to hope that they eventually are let go or to leave yourself.
The Good Guys
To happier topics: Good programmers are, I believe, the core of the profession. They are competent, desire the right outcomes, and strive to contribute to the team. They frequently have well-defined skills, a good understanding of development disciplines, and are open to new approaches as long as the material can be integrated with what they already know. They write solid code, although only occasionally does it show a truly imaginative solution. More commonly, when faced with a difficult problem, they will lapse into quick and dirty hacking. They block themselves from greatness by not having the curiosity or know-how at their command to be more than they are. That is, they refine their skills principally by continued application, not by learning new technologies unless required to do so by job demands. Such programmers are at risk of slipping into the lower grouping by letting their skills atrophy. I discussed several examples of this in my previous editorial on coding from within the echo chamber.
Really good programmers have another dimension to them: They carry an abiding passion for programming. They like to solve challenging problems and they like to solve them well. They are not satisfied with writing one more CRUD app. They want the magical work that is hard and requires extended effort to bring to fruition. If they can’t find this satisfaction in the workplace, they find it in personal projects or by contributing to open-source projects. They frequently test new technologies, try out new languages, explore new tools, and read about programming. Dr. Dobb’s readers are found in great numbers in this group, I believe. Dr. Dobb’s has no exclusive franchise here. These developers are interested, consume programming books, and hide out in developer forums as well. They revel in challenge and have a constant sense of searching. They’re looking for the best answer to a problem, or the most elegant.
The Greats
The next tier up the final tier consists of great programmers who have supernormal gifts that enable them to do easily what good programmers find difficult. Due to my work in the press, I’ve met more than my share of these talents, although I’ve not had the opportunity to work with many of them. To my eye, the traits that most stand out are three in number: an excellent memory, a conspicuously wide knowledge of programming techniques and the judgment to know when to apply which, and a deep ability to relate details to the larger picture. The last trait being capable of quickly shifting registers from the large picture to small details and back again relies on the strong memory and operates on an almost automatic basis. There is an effortlessness to it, which makes them particularly good architects.
There’s one discipline they all share as well, which appears only in varying degrees in the earlier levels: Without exception, they possess a very deep and intimate knowledge of their tools. Be it the editor, the compiler, or the framework, they know the ins and outs of its features and they navigate efficiently. They use a much wider array of features because they know exactly how the tools work.
Knowledge of tools, coupled with an extensive, tested palette of programming techniques, and the ability to remember large amounts of the code base, while relating low-level details to the whole with unconscious ease these are the traits I see most often in great programmers. And they’re the skills I continue to aspire to in my work.
— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy
