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.
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.
Reference: Good Developer, Bad Developer from our JCG partner Guy Nirpaz at the Thoughts from my startup journey blog.
I (sadly) know some bad developers. Not the best people to work with…
You make a lot of good points, however, you left a key component out: A good programmer is productive.
I’ve worked with a number of developers who have many of the attributes you mention in your article but are consistently late, deliver over-engineered work, use “new” technologies that fail to deliver (often to build up their own egos / resumes), or build features that no one wants.
While most want to be a craftsman in our profession, a good programmer knows what is “good enough” and knows how to get the job done.
Otherwise great article.
So your are not programmer! a programmer never ever talk like this , Its better to change the title as “Slave developer, Bad developer”, I prefer to be bad developer instead of your good developer. bye the way I am agree with some part(20%)!
Probably your “good” developer is not real developer, it is like most of project which a lot of company made` good for costumer, but technically bad, always fails , bad performance, bad architecture . Every project the first must be well made and well architect, because you know costumers does not know what they want, but developer must understand technical solutions for prevent customers every day changed requirements.
I agree with some parts, but not with all of them.it’s different to work in a software house and distribute software for other companies and different to work in a company as an inhouse developer that is more bussiness oriented. You have to know the specific bussiness requirements so to fully understand the business that you are working on, and if you a part of a team you have to document your code well. So at least with these last too your good developer is a bad one ;)
very true..