The 3 Levels of Programmers: The Good, The Bad, and the Lazy

Programmers can be divided into those that build libraries and toolkits, those that know of and use these libraries, and those that mistakenly believe they can build everything themselves. Agree or disagree? Sound off below...

Everyone in software development has probably heard about mythical uber-programmers who are at least 10 times more productive than their average brethren. I'm not sure it's so easy to segment programmers into just these two groups. My experience has been there is a wide variance in programmer productivity and that programmers fall all along the continuum.

One factor I think which figures heavily in determining a programmers productivity is toolkit usage. Call them what you will: libraries, toolkits, or frameworks, but using them can have a big impact on how quickly and effectively you complete programming tasks. In this vein, I'm starting to think there are three types of programmers out there...

Starting at the bottom, we have developers who when faced with a problem, draw upon their current programming knowledge and start coding. Infrequently, this is the right thing to do. For example, the problem requires implementing a business-rule specific to that particular project. Many times however, the first question to ask is whether this problem has already been solved, typically by someone smarter than you.

The middle-class of developers are the lazy ones. They know building everything from scratch will take too long. As well, they don't trust the quality of their brand new code, knowing that real world usage and a good suite of unit tests are the only way to "prove" code quality. These programmers spend time at lunch reading tech blogs to keep up-to-date with the latest tools, libraries and techniques. Drawing on this knowledge is key to knowing when a problem can be solved successfully using an existing library.

The top of the pyramid consists of a very select group of developers who have built and released libraries and toolkits which are now used successfully by the programmers in the level below.

To illustrate, consider the problem of data persistence routinely faced by developers today. When needing to move data back and forth between storage (typically a database) and the business layer (typically objects) there are a few responses:

• Bottom of Pyramid: Developer starts creating model objects and writes mediator code to run SQL queries directly for loading and saving these model objects. For extra points, use verbose XML to add an unnecessary level of complexity! No attempt is made to look for existing toolkits or libraries.
• Middle of Pyramid: Developer evaluates best-of-breed ORM for their language and platform, selects the best one for their project, and quickly wires persistence up.
• Top of Pyramid: Developer evaluates the best-of-breed persistence libraries for their platform and finds them wanting. This developer then writes their own well-designed library and releases it to acclaim from other developers. A good example is Gavin King, the author of the Hibernate persistence framework for Java.

Now, most of us will never join the upper echelon of programmers who've built widely used and successful toolkits. I'm pretty sure I never will, as I am lazy by nature. I'm always reaching for open-source tools to accomplish my projects.

So, why am complaining? Does the "build-it-myself" mentality of many programmers really impact me? You bet! Any time I am doing maintenance work on the code written by these code cowboys, I have to deal with the clean-up.

To continue the persistence example, imagine being asked to switch from eager loading of data to lazy loading to improve GUI responsiveness. If the original developers had chosen a good ORM framework like Hibernate, only a small configuration change is required. However, the "in-house" persistence code can't do this without completely changing the data structure. (i.e. Here's a grid of data where before you had a tree of data to work with) Very slow and very frustrating!

So what's a lazy, middle-tier developer to do? Always ask "why are we building that in-house" when discussing new functionality. Look for quality toolkits to accomplish any generic tasks your application needs to perform. You should be writing the small percentage of code which is specific to your business problem and provides your users with real value. Don't waste your time schelping bits back and forth from a database! That problem has been solved years ago...

P.S. Isn't it interesting how the migration path to get to the top-level of the pyramid seems to be from the bottom layer. For example, Gavin King said "I can build it myself!", and he was right. How many other developers started down that road though, failed miserably and are still stuck in the bottom tier?

P.P.S These aren't exclusive sets, every developer can have traits of all three types.

Posted by Guy | Posted on 2008-01-09 at 12:43 PM | Public Post

>> These programmers spend time at lunch reading >> tech blogs to keep up-to-date with the latest tools, >> libraries and techniques. I chuckled at that as I took another bite of my turkey sandwich. I am making my first attempt at poking the pinnacle. Check out architecturerules.googlecode.com sometime and help me climb a little higher ( : Good article. Thanks.

I have to say, I have far more respect for a programmer - no matter how incompetent - who is keen to come up with his own solutions to a problem, rather than somone who simply borrows others' code. Writing code to solve problems is what programming is about. It is challenging and satisfying all at once. If you have no desire to solve coding problems yourself, but instead always reach for an off the shelf solution, then I don't think you are a programmer. You might do programming as a career but you are no a programmer. You are not someone who relishes tackling a problem that you haven't encountered before. Of course, there is nothing wrong with simply doing programming as a job. But having the temerity to criticise those who love coding so much that they want to tackle every coding challenge themselves, well...that really pisses me off.

@AJK79: There will always be developers who think they are smarter than everyone else and insist on building everything themselves. I think they're a pain in the ass to work with.

By using existing libraries and toolkits to solve the common problems we all face as developers, we have the free time to build custom solutions to truly novel problems. Trust me, there will always be interesting problems for good programmers to work on where they get to exercise their creativity. But they sure won't get that opportunity if they waste their time re-inventing the wheel.

I partially disagree with you: most programmers consider that building framework is the highest level of programming. So they tend to ...build framework, even if it's not needed, just in case of... Building a good framework is a complex thing, but using others framework to build a complex thing is also a very challenging thing....

Great discussion. I agree with your hierarchy and even some of your value judgments about build-vs-buy (so to speak) but I couldn't disagree more with what it means about developer productivity. First, I'd say your pyramid is, at the very least, inverted. You don't say, but if the width of your pyramid represents number of developers practicing higher levels of toolkit usage, then my experience is directly opposite of yours. In my experience, the vast number of immature/green developers rely (to a fault) on frameworks that are handed to them or that they have grown accustomed to by habit. They are productive only insofar as the framework supports the requirements of the project. On the other hand, a few seasoned developers on a team often recognize the limitations and biases of their frameworks while having the nuts and bolts experience to work around them. I've seen too many cases where an expert "toolkit" developer will spend days trying to hack the edges of framework into solving a problem that a "build-it-myself" developer could code from scratch an a few hours. You are right to point out that "build-it-myself" development can be a time sink as well when taken to extremes. But, misguidedly trying to contort an Orange framework to build Apples can be an even worse time sink. None of that is evident in your linear pyramid. As an alternative, I'd suggest you could capture these truths better if you changed your diagram to a bell curve. An evolving developer would naturally move left-to-right through four phases: "builds-just-because" to "dependent-on-frameworks" to "uses-frameworks-and-builds-as-appropriate" to "builds frameworks." The sweet spot for an ideal, productive developer would then be between Use and Build frameworks, able to move back and forth as needed. Your select group of framework builders would off the high-end of the bell curve (not necessarily directly "productive" themselves but making the organization more productive as a whole).

@SJones: Very good points. You're right that my article is an over-simplification. Good programmers do need to be able to switch between between the "build-it-myself" versus "integrating a library, toolkit, or framework" modes. Knowing when to use each approach is probably one of the key skills that separate the great from average programmers.

My article was slanted against weak "build-it-yourselfers" since that was ticking me off yesterday. I probably would have written the opposite opinion if I was dealing with a developer whose response to every problem was to say "J2EE can do that!".

Guy, I appreciate your good natured response to my counterpoint since I never really wanted to rain on your valuable rant against "build-it-yourselfers". On reflection, I think one source of our opposite points of view comes from different environments: Linux/Java culture vs. Windows/.NET culture. I've worked in both kinds of groups and found that they are generally skewed toward the two kinds of ignorance/arrogance we're complaining about. In my experience, Windows shops tend to be "Catholic" and accept the framework doctrine handed down from above. Linux shops tend to be "Protestant" and believe that the only framework they need is their personal relationship to their code. Maybe what we're both saying is that development salvation lies somewhere in the middle.

Awesome post. "Reinventing the Wheel" is one of the great anti-patterns among programmers.

Part of the build vs. buy predicament is that, from an architectural point of view, the options are often extremely poorly documented. Take NHibernate - I'm sure its a good ORM. But for the life of me, I cannot find an easy way to evaluate it against my particular needs. It would take weeks to properly evaluate, because it's high level architectural documentation simply does not exist.

On the surface, it would seem relying on frameworks is the obvious thing to do. In practice, frameworks are more often than not handcuffs and shackles. How many misguided designs based on "good" J(2)EE practice? EJB all over again! "You ain't gonna need it", "I'd rather use a socket" are good slogans to keep in mind.