About Guy Nirpaz

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.

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.

7. Android UI Design

and many more ....

6 comments

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.

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 ;)

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.