in Company Execution

Good Developer, Bad Developer

I recently read Ben Horowitz’s piece on the importance of training people in startup companies. At the end of this article he put together a document “Good Product Manager, Bad Product Manager”. Here’s my spin on it: Good Developer, Bad Developer. Enjoy, I look forward to your comments!

Good Developer, Bad Developer

Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code.

Good developer understands the problems of the customers. Bad developer understands only the technical problem at hand. Good developer does not define the why, but constantly strives to understand why. He’s responsible for the how, and still sees the big picture. Bad developer is focused on building classes and methods and configuration files, but does not get the big picture.

Good developer understands the complete architecture of the product. Bad developer knows only the components he’s written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally.

Good developer is not afraid of new technologies but embraces them by quickly getting a grip. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative.

Good developer is constantly learning and improving his skills. Good developer reads technical articles, and finishes several technical books a year. Bad developer does not have time to learn. He’s always too busy with other stuff.

Good developer cares about the product quality. He is also very much concerned with the process quality. Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix.

Good developer develops features which create value for customers. Bad developer completes tasks. Good developer will never claim the requirements are incomplete, and will make sure to fully understand the features he’s working on. Bad developer will wait until the finest details are available. To emphasize: good developer is the CEO of the feature – he’s going to make sure he always has the information needed to accomplish the feature, and in case information is missing he’ll make sure he gets it.

Good developer is not afraid to go into anyone’s code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify.

Good developer will never feel his code is good enough, and will always continue to clean and fix. Good developer always strives to create elegant solutions but understands that his job is to deliver value to customers. Bad developer thinks only about the elegance of his code and leave the job of delivering value to others.

Is that all? Did I miss anything or got some of these wrong? Feel free to chime in the comments below!

Guy Nirpaz
Co-Founder & CEO, Totango

Write a comment...

Comment

81 Comments

    • The real problem is not such. It is getting business/manager to understand that things require time and explanation. Most of time, we do not get proper explanations and when we demand, the time is much passed and we are forced to deliver whatever we can and still we are not sure of its 100% what’s needed!

  1. I agree with everything you’ve written here save that very first sentence:

    “Good developer is an artist, a craftsman who enjoys the process of creation.”

    I think that artistry and craftsmanship for their own sake are at odds with the points you make later about solving customer problems. I think that writing elegant, performant and easy-to-follow code *is* often in the best interest of solving customer problems, but the latter should inform the former.

    Your point about code reviews and the Bad Developer Who Fears Them is especially well said.

    • I agree…I think the problem is *opening* with this statement. It’s true, and probably wouldn’t have stuck out at all if it had occurred later in the list.

      Might have been better to open with the 2nd paragraph: “Good developer understands the problems of the customers” — and would have been nicely followed with “and then solves them with artistry, craftsmanship, discipline, and skill.”

  2. Good developer wants another developer to read his code because that makes it possible for at least one of them to learn something.

  3. Thank you for this. It reminds me of the “Goofus and Gallant” comic in the “Highlights” magazine I read as a child.

    This topic is one that I have been struggling with recently. I find that I am both the good developer and the bad developer. For some reason the big picture eludes me and I seem to draw the wrong conclusions when presented with a situation. I am ashamed of my code and am apologetic to the extreme when others have to maintain my code. I am not resistant to change but I find that I have little traction when trying new technologies.

    On the other hand, I want to learn and I go out of my way to learn new techniques and technologies and have some success at that when I really put an extreme effort. I also don’t require a perfect spec and am able to craft solutions that meet the needs of my business partners even though I have regrets once I am done.

    I can learn to write better code, but how does one learn to look at the big picture? How does one learn to look at the facts and draw the right conclusions? How does one learn to learn?

    • I don’t usually bother with “fluffy” topics like this (you should know whether you are a good developer or not and not need an article to tell you), however, on this occasion the article does make some good points and I was moved enough by your response to respond… :-) Let’s look at the points you raised in sequence:

      1. “This topic is one that I have been struggling with recently. I find that I am both the good developer and the bad developer. For some reason the big picture eludes me and I seem to draw the wrong conclusions when presented with a situation. I am ashamed of my code and am apologetic to the extreme when others have to maintain my code”

      Stop needing the approval of others. Never be ashamed of your code, provided you did the best you know how. There will always be SOMEONE who is more adept than you at coding; that doesn’t mean your code is worthless or needs apology. If it works and does what it is supposed to, it is not worthless code.

      2. “…I want to learn …”
      That is really all there is to being a successful programmer (not to mention being a successful Human Being :-)). Constantly review what you did and try to improve it, learn from books, your own mistakes, and others who are really good at what you are trying to do. Do NOT go into a decline because you find out your code was not perfect. If you did your best and the code worked, you have nothing to be guilty for. Accept that as you gain experience, you will get better at it. (I’ve been programming computers since 1965; I’m still learning but I don’t apologise for the code I write whether it is C#, Java, COBOL, Fortran, scripting, or Assembler on any one of half a dozen platforms. I know there are people who can write any of these languages better than me, but my code works, my applications are maintained by others without grumbling, and I always try to give end users more than they expected.)

      Finally: “I can learn to write better code, but how does one learn to look at the big picture? How does one learn to look at the facts and draw the right conclusions? How does one learn to learn?”

      These are all the “right” questions :-). (The right questions are every bit as important as the right answers…) How to see the “big picture”? Interact with some end users. Spend a day on the “shop floor”. Listen to them, watch what they have to do, think about ways you can apply your skill to make their lives easier. Don’t thrust solutions upon them; iterate and interact, refining the solution and letting it evolve until it is really useful. You can have the most elegant code in the world, but if it doesn’t help somebody or make their life easier, you might as well have not written it.

      Looking at facts and drawing conclusions is part of why you are a programmer. If you can’t reason logically, quit now and work in local government or run for politics.

      One learns to learn the same way a baby learns to walk. By experience and many failures. It helps if you have supportive family who will encourage the “yearning for learning” in you at an early age, but even without this you can learn by developing a healthy curiosity about EVERYTHING; don’t accept a solution until you are comfortable with your understanding of it. Never be fobbed off by someone who doesn’t know, telling you it is beyond your understanding; you will be amazed at what you are capable of understanding. Many years ago I asked a person who was senior to me to explain what a “parameter” was. He said “it’s like rhubarb, you either get it or you don’t…” I realised in that instant that he had no idea and was just being a jerk. Since then I have gone to pains to give proper explanations when anyone asks me to explain something and I check they have it before I move on :-)

      My advice to you: Stop worrying and recognise your own insecurity is unwarranted. You are much better than you think you are and you have every right to call yourself a programmer. Continue with the most important processes in your life: your personal and professional development. (you will find they are interrelated, but never let your job define you as a person… :-))

      I wish you every success.

      Pete.

      • I too never bother to comment on posts, but I really appreciate your response to the OP and believe that its the best advice that I have seen in years for someone trying to improve themselves.

      • Pete,

        Thank you for your response. I guess I was throwing my message in a bottle into the void. It was a pleasant surprise to see a bottle come back out. I appreciate your words and the confidence you express is exactly what I want to feel and reflect.

        Years ago, I thought I was a great programmer. I look back now and realize that what I was lacking was humility and introspection. Perhaps I’ve swung back to far on the pendulum and question each line of code I write, but I won’t give up searching for the middle ground where I can trust what I create while continuing to find room for improvement.

        Thanks again.

  4. Good Developer uses processes and tools that make sense to solve problems. Bad Developer uses processes and tools as excuses and crutches for why nothing is really getting done.

  5. There are definitely a few gems in here, thanks! I’ve voted up a few that I thought were bang on!

    * Good developer is constantly learning and improving his skills. Good developer reads technical articles, and finishes several technical books a year. Bad developer does not have time to learn. He’s always too busy with other stuff. ***YES***
    * Good developer is not afraid of new technologies but embraces them by quickly getting a grip. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative. ***YES***
    * Good developer is not afraid to go into anyone’s code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify. ***YES*** Our bad developer in the office seems to have this paranoia in spades
    * Good Developer uses processes and tools that make sense to solve problems. Bad Developer uses processes and tools as excuses and crutches for why nothing is really getting done. ***YES***, again, we’ve got one of these too!

    Thanks!

  6. “Good developer will never claim the requirements are incomplete”

    I don’t know about this one, and it is contradicted in the clarification:

    “[Good developer is] going to make sure he always has the information needed to accomplish the feature, and in case information is missing he’ll make sure he gets it”

    So I’m reading this as “the requirements are always complete unless they are incomplete,” but I don’t think that is what you meant. Maybe something along the lines of “Good developer assumes the requirements are complete” for the first blurb about requirements.

    Anyway, great post and I’m glad to see that I’m hitting most of the “good developer” points, and only a few for the “bad developer.”

    • Matt, thanks for pointing this out.

      My assumption is that the requirements will always be incomplete, will never be 100%. Being able to understand what needs to be delivered to satisfy the end-users requires elaboration and discussion on top of formal specification.

      Makes sense?

      • Formal specs are a legacy of the Waterfall development we did in the last century. Yes, you need something to get a programmer going but I have seen specs used as an excuse by malcontent programmers too often. I fired someone once (something I very rarely do) because he dliberately coded a spec as it was written, knowing full well it could never work. He did it because he was having a personal feud with the analyst who wrote the spec and he figured he could make the guy look bad. When I confronted him about it (after our team spent days fixing the damage) he said: “You can’t touch me; I coded it according to the spec.” I fired him on the spot and he was lucky I didn’t hit him… :-)

        If you MUST write a spec, make it functional and make it identify the inputs process and outputs. Don’t even attempt to dot the “i”s and cross the ‘t”s. Explain what needs to be done with the desired results and grant a programmer the creativity to deliver it, supporting that programmer with interaction and explanation when required. You work in a TEAM; never throw a programmer (or anbody else…) to the wolves.

  7. I used to really beat myself up over this, at the end of every iteration I’d look back like “what was I thinking?”

    I found that instead of being shocked by my own incompetance, I do better if I take it for granted. The goal is to suck a little less each time. I make sure the relevant stakeholders know the limitations of the solution and that there are always backups and backup plans.

    What I’m learning is that while I have a very long way to go before I’m a good developer, I can still be a good worker and a conscientious developer, and very few people can tell the difference.

  8. Good developer will do some research before writing codes to make sure the methodology he is going to use to tackle a problem is a reasonably better way. While bad developer always tackle a problem using whatever that comes into his mind.

    • Planning is good, but sometimes you spend too much time researching the problem and not enough time working (getting your hands dirty).
      Programming and developing are not an exact science. Sometimes, we really are trying to fit a round peg into a square hole.

  9. Really Good Artical
    I think every Developer should read it .. It gives ideas where should developer focus on .
    Thank You for this artical

  10. Not an interesting read but I liked the first paragraph, “Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code”

  11. I’ve always said that I’m a lousy programmer but a good developer, and I define ‘development’ as the process of solving problems in order to meet the requirements of the business / customer / priority stakeholders in a cost effective and timely manner.
    I’ve been in software development as a hobbyist or professional since the 1970s and the above philosophy was one I started adhering to in the mid 1980s when I started earning a living through software.
    The bottom line is development is peripherally about technology – development is about effective, practical, problem solving.

  12. Why is “Bad developer” still a developer? Is it because he is also Junior developer and learning to become as good as Good developer, or is he allowed to continue work to as a bad developer for as long as he produces code anyway? If the latter, is he really then a bad developer?

    Or is he transitioning into a non-developer role, like test manager, project manager or something?

  13. Did you just wrote down a specification of your Ideal Programmer? You know that no coder exists to fit profile. If there’s one, he’s not a coder but a project manager who’s hand-on in writing codes.

    • I beg to disagree. I’ve met my share of good programmers, they are almost all self-managing and self-taught. They are so passionate about what they do that they learn things from all the surrounding fields. Good programmers are a rare breed.

      A project manager with coding abilities will not have the insights of a good programmer with managing abilities.

  14. @Marcin Gorecki: There are two main types of bad developers;
    1-Ability to absorb and accept and share problems.
    2- Sharing problems for solutions but with fake solutions
    The first kind of developer has the capability to convert into good one. Because they know and accept the leakes of their code and their deficiencies. Although they are not always self learner —to convert them into good one, one has to stick with them always telling the efficient manners. One best characteristics they will always have –they will never say I knew the solution but it was taking much time to implement(shattered in their mind)after someone fixed them. The worst thing in them is that they will never give you the credit too.
    In the other hand the second type of bad developer is a worst kind of its own. They have each bad habits as human can. They will try to fix their problem(actually they don’t know event the problem) by just staring onto it for hours then will consult with someone which can help. But when they are helped and problem resolved they will be found telling that “I had an idea but I couldn’t write into words in the code editor . And when the solver want to elaborate the reasons of the problem they will say in no time that “Yeah I knew the solution which you did but they were not in arranged and organized form”. Then the helper will start to hate in the heart. They will also never give you the credit.
    But they will always ping you about their problems. Therefore you have to fix only to keep them silent.

  15. Good developer collaborates with everyone. Bad developer blaims everybody – management, designers, testers, customers – and everything – computers, tools, systems, processes.

  16. Great article! I’ve been developing software for a living since the 80’s. I have a characteristic of a bad developer (not reading enough tech books). Fortunately I have more characteristics of a good developer: careful attention to end-user requirements, constant self-improvement, teamwork. Thanks for a thought-provoking read!

  17. As someone with many years of development management experience, I can tell : the author of the post has no clue about “Software Development” ! What is written might work for construction projects though !

          • okay, on a serious note, your concept might work for junior developers, developing a vanilla product, but if you have senior developer who is dealing with high performance design and another senior developer who is dealing with advanced graphics, they might stick to their own work and not dig into eachothers work. They also might prefer to stick to a certain technology, since a change brings its own risks.

    • I have close to ten years of software development experience and there’s one thing I can say: bad developers are practically everywhere. From my point of view, the author is almost 100% correct in this post.

      I hate it when people stick to their respective work areas. Nobody ever gets the full picture and the broader perspective it brings. In the end the project *always* suffers from it. Developers rely on management to keep things organized and management is usually clueless. We work in a domain where knowledge is FAR more important than solving problems.

      I meet Good Developers quite often, they can outperform dozens to hundreds of proper “Software Development” people on their own, effortlessly. What you are describing is the very inefficient corporate structure of software development, whose roots are closer to military slavery than creative innovation. Good Developers also aren’t afraid of new technologies, you can’t innovate without taking risks.

      To me, the risk is sticking to old technologies and seeing all the competition outperform you. Good Developers are critical to evaluating these risks.

  18. I agree with the good developer description, but think you may have missed the bad developer a bit.
    Personally, I’ve never counted lines of code. I don’t believe philosophically it matters how many lines of code in the program. But, some people obsess over the lines of code… does this make them bad or just obsessive for the wrong reason?
    I take pride in all the code I write, and try to make the code as forward thinking as possible. But, some can’t see the light ahead through the specification and obsess at just doing the bare minimum to satisfy the customer… does this make them bad or just trying to meet the deadline (that is always unreasonable).
    Most managers, I’ve had seem to use this rule: Take the developer’s estimate, multiply it by 1/2, then take away 3/4 of that total and propose that time as the completion time for the project and changes.
    Also, for some reason management has this idea that if a project is late just throw more resources at it and it will get done quicker. Believe me you will spend more time trying to get the other people up to speed on the project far longer than it will take you to do the job yourself. Meetings seem to kill time even though they may be productive. It’s not to say management isn’t under pressures as well. Remember the time given above.

    I’ve done many amazing things over my life as a programmer and developer; but, I’ve never boasted about what I’ve done or taken credit for others works, I’ve had a few of those types around before.

    The junior programmers and developers aren’t bad programmers as some may suggest, as long as they have a passion to program and aren’t just in it to count lines or push the clock. Like all, greatness, is a lifelong learning process even for those that have been around for a long time. We all strive for it but like all greatness never seem to get there all the way. Every program and project could have been done better, more efficiently, or for less cost … the idea is not to loose sight of the ideal and always strive to do your best.

    • I do assess the lines of code and try to keep a file under 1000. I aim for about 200-400 per file these days, any bigger and I can’t grok it all at the one time.

      The less lines of code the easier it is to understand as a general rule. Not always true of course.

      I also Stylecop all my code to make it easier to understand.

  19. Good developer doesn’t immediately jump on the “latest and greatest”. Good developer is able to distinguish hype from substance. Good developer is not sucked in by buzzwords with nothing behind them.

    RE: Pete Dashwood’s comment “you should know whether you are a good developer or not and not need an article to tell you”, I refer him to the paper “Unskilled and Unaware of it” by Justin Kruger and David Dunning, available at http://www.wepapers.com/Papers/70939/Unskilled_and_Unaware_of_It_-_How_Difficulties_in_Recognizing_One%27s_Own_Incompetence_Lead_to_Inflated_Self-Assessments

    In a nutshell it states that, in general, people who are competent in an area of expertise tend to underrate their ability while those who are incompetent tend to overrate their ability. It’s an excellent paper that anyone in a technical job should read.

  20. So you say geeks are bad programmers and managers or system architectures are good programmers. Let’s train the later to be developers and see.

    Good or bad, it really depends on which organization you are in.

  21. Good developers are like good citizens or parents… They are born with intrinsic qualities, and the life did not spoiled them.
    You can learn a trade only to a certain level, the rest is a gift that you have or not. And this is particularly for the big picture… You either see it or not.
    But studying seriously and learning from others can make you an honest developer, useful and reasonably pride of your work…

  22. I agree with this post completely and strive to be the “good developer” in it.

    It’s important, though, to understand that these are characteristics of good developers, not a list of things to do in order to be a good developer. To make the point, here is an interesting exercise: transliterate “good” and “bad” throughout the article, and see which of the points still make some sort of sense:

    “Bad developer is constantly learning and improving his skills… instead of meeting practical goals.”

    “Good developer knows only the components he’s written… and does not rely on undocumented or unsupported behavior of other components.”

  23. I think one was missed…

    Good developer brews more coffee when the pot becomes empty. Bad developer only takes coffee from the pot.

  24. “Bad developer always needs to allocate extra time to document and simplify.”
    “Good developer will never feel his code is good enough, and will always continue to clean and fix.”

    Sounds a little bit double…

  25. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative. Just like my old IT Chief…

  26. Having co-founded three startups with software development reporting to me, I believe the post is spot on. My observation is that every instance of “good developer” could be replaced with “good development organization”.

    Two aspects are critical in an innovative development organization: 1) have a large proportion of exceptional thought leaders mixed with bright people who can learn, and 2) create a corporate culture that embraces the attributes you embraced in this blog post. Of course it is important that it is a “learning organization” where the though leaders freely share with the whole organization.

    In a startup, you have control of this (though it is difficult). In an established software development organization, you have to transform it leading the willing (that are bright enough), and frankly, purging those that don’t (sorry to be harsh). You can’t accept to accept mediocrity.

    I work with some traditional on-premise software companies looking to transform to SaaS. Some development organizations culturally are rooted in the past (can’t move beyond WPF), and some embrace the change. It is clearly evident who can succeed.

    My views in the attributes needed for a development organization to move to a new SaaS model are in my last blog post http://www.cloudstrategies.biz/why-software-development-for-saas-is-different/.

  27. Good developer has a deep understanding of the abstractions he works with. Bad developer sees abstractions as opaque things that are just there to get the job done.

  28. Good developer does not explain and describe technical details to the customer. He/She knows that the customer doesn’t care so much

  29. > Good developer will never feel his code is good enough, and will always continue to clean and fix

    That might just be quite an annoying habit with regards to revision control. :-)

  30. > Good developer will never feel his code is good enough, and will always continue to clean and fix

    You mean a good developer has an inferiority complex?

    A good developer should know when to stop changing code and move on.