The Programming Divide

There's a flurry of great posts and comment discussions going on right now about the divide between good developers and bad developers

 

The Great Divide

Like Jeff Atwood, I do believe there is an almost binary switch between effective and ineffective developers.  I'm not exactly sure why this is, but if you'll indulge me, I've got a couple pet theories:

  • People that are good coders are able to do make code work faster, which leads to getting more experience than their slower colleagues, and spare more thought cycles for how to do things better next time.  The innately talented developer is able to get better and faster each time, which gives him or her more time to invest in getting better.  From there I think it's simply a snowball effect.
  • To Phil Haack's point that it's not entirely innate ability, any degree of contemplative thoughtfulness on the part of a developer will make that developer much better over time.  The smartest guy in the world can still be intellectually lazy (but I don't see how you *could* be smart without intellectual inquisitively).  Thoughtful people gain more valuable experience.  People who aren't thoughtful may only be practicing their typing skills.
  • Joannes added this as a prerequisite for being a great developer:  "… a passionate curiosity for software related matter …."  Every very good or great developer I've ever worked with enjoyed software development.  I've been interviewing developer candidates lately, and a passion and intellectual curiosity about software development counts far more with me than Trivial Pursuit Q&A exchanges.
  • Software development takes a very strong ability for abstract thought.  I don't think that concrete thinkers have an easy time with software that's by definition a mental model of something else.  I'd say visualization is important, but I've worked with good developers who had zero visualization ability.  All the great developers I've worked with did though.  People do think differently and have different modes of learning.  

 

You can get Better, and it's not all Coding or Ability

Like everyone else I believe that your best bet is to hire the best and brightest, but in reality you have who you have.  Maybe the hiring process gets you the wide swings in productivity, but wringing out a 10-30% productivity gain out of journeyman developers is still a substantial gain.  Training, coaching, discipline, better practices, communication techniques — they can all contribute to productivity.  "It's not the methodology, it's the man" is a hackneyed and cheap way to get some sort of imaginary high ground in any discussion, but it's partially BS.  Anybody can get better, even if it's only in the way they interract with other people in the team.  Besides, it's extremely unlikely that you can instantly go and replace poorly performing team members with better developers at will.  You're largely stuck with the folks that you have.  Making them better is probably your only option.

Following a tangent, when any debate about software practices or processes is going on some clown always pulls out this phrase:  "you should just pick the best practices from waterfall, XP, Agile, RUP, whatever…"  Hah!  I've now seized the high ground you might think.  No you haven't, you've simply indulged in the intellectual equivalent of empty calories.  It's a worthless statement.  The question "what *is* the best way to work" is still on the table.  If we knew what the best of everything was, without a shred of doubt, we wouldn't be having the debate, now would we?  Plus it's even harder than that because mix and match practices might not work well because many practices reinforce each other.  I think you could happily add TDD and CI to any methodology and get some benefits, but they shine a bit more in an adaptive process.  On the other hand, doing continuous design or adaptive project management on a codebase without automated tests and CI sounds dangerous to me.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.illede.net rüya tabiri

    Thank you

  • http://www.portraitkingdom.com portrait artist

    Web developer is truly a broad job title. But here are my personal characteristics of a person who is a certified developer. A web developer is punctual and is very conscious about time; that is they always finish their projects on time. I must say that they are geniuses in the field of programming and Internet technologies. As an added bonus, these people have unique way of showing their positive PR skills. That’s why they can work in a team and can also work even in a remote environment without sacrificing quality and deadline of their project.

  • Stephen Smith

    Just three quick comments that I would use to describe myself as a developer and I certainly would not describe myself as an expert or guru, rather as somebody who is fair dinkum about his craft.

    1) I love what I do. I love doing lots of it. And each time I do it I love doing it better, smarter based on what I have learnt from doing, from working and sharing with others.

    2) I would like to think that my effectiveness as a developer is largely determined by the power of the practices, coding and methodological, that I use.

    3) I love looking at code I have done in the past and was happy with at the time but now seems a little naive. That is an opportunity to measure progress in my craft over that time.

  • Paul Leclerc

    Jeremy,
    I definitely agree with your ‘speed’ advantage. Very early in my programming education in college, I spent hours learning, on my own, the ins and outs of Unix commands AS WELL AS learning about C, C++, Data Structures, etc. Being able to use those tools allowed me to slice and dice data, logs, and code and get to the heart of problems much quicker than my colleagues. That gave me the “slack” time in my schedule to write better code and learn more and more which allowed me to be faster and learn more and so the cycle continues.
    Twenty years later, I still amaze people when I bring up a DOS command shell, run awk/sed/perl/wc on a set of data files to show where their problems are. I meet ‘brilliant’ people who would rather spend a 1/2 day writing a Java program to do the same thing. Meanwhile, I’ve gone back to my own work doing what I’m supposed to and learning more and creating better code…
    I believe that I’m a better programmer than I was 6 months ago and 6 months before that. I’ve also sucked big time during the past year as I took the past 20 years of base knowledge to begin programming in the ASP.Net world from Java.
    Key points:
    – Learn your more about the other tools in your environment
    – Keep learning
    – Don’t repeat yourself. An existing tool probably already exists to do something that’s manual or tedious. Find them and use them.
    – Take the chance to be sucky for a time in order to be a wizard later
    – Do what you love but also be willing to help out the team by doing some of the ‘crap’ work for a time.

    This does pay off in the long run but don’t expect that you’ll go from code grunt to developer overnight.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    megaadam,

    I think you’re reading that section on coding speed a little too literally.

  • SteveJ

    megaadam – Hopefully said fast coder also quickly writes lots of fast tests :)

  • megaadam

    I question the fixation about coding speed. Of course generally a good programmer is faster, but other qualities are even more important. He/She has to produce readable code, code that will live for a long time, code that anybody can read, a long time after the original author has quit.

    And also: Fast coding is not the same thing as solid coding. A phenomenally fast programmer will be able to do really nifty tricks with pointers and whatnots, that is an admirable skill, but is such stuff solid enough to control the Space Shuttle? Methinks not!

  • ChrisK

    In regards to visualization, it also serves the purpose of simplifying the problem, in terms of grasping what’s needed. So in that vein, I prefer pictures, just as how they help with a word problem in math to consolodate the pieces in a visual reference, I can better see the big picture.

    If not, then I don’t think flow charting would have been such a hit.

  • SteveJ

    I agree with Steven above (obviously a genius), about the Visualization sidebar. To add a new wrinkle though, people that can create visualizations from stories/concepts have another tool in the toolbox; they can translate a concept yet another way to better communicate with the team. On my team we have people that need pictures and others that need a requirements spec. My first order language is very close to code, so I have to translate from that to communicate my ideas to the rest of the team. It’s quite possibly the most challenging barrier to effective team collaboration.

  • http://www.edmblog.com James Taylor

    While I think there are “problems” with programmers (http://www.edmblog.com/weblog/2006/11/the_problem_wit.html), I do think that most people don’t want to write code (http://www.edmblog.com/weblog/2007/01/does_everyone_e.html), and could not if they wanted to. The fundamental problem is that programmers and business users have a different perspective (http://www.edmblog.com/weblog/2005/08/different_persp.html)
    JT
    http://www.edmblog.com

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Steven,

    You’re probably right, but I was thinking about visual versus auditory or verbal learning styles. I’ve worked with people who can “tell” a story about a design in a kind of metaphor, but can’t really picture the various moving parts and understand how they hook together. That’s when I learned that UML models are not universally applicable.

    Jeremy

  • Steven

    “Software development takes a very strong ability for abstract thought. I don’t think that concrete thinkers have an easy time with software that’s by definition a mental model of something else. I’d say visualization is important, but I’ve worked with good developers who had zero visualization ability. All the great developers I’ve worked with did though.”

    Isn’t visualization just taking something abstract and fitting it into more concrete terms? Is that always advisable? Personally I find visualization a waste of time, but as you say, people do treat things differently.