Good Developer, Bad Developer(guynirpaz.com)
guynirpaz.com
Good Developer, Bad Developer
http://www.guynirpaz.com/2012/06/11/good-developer-bad-developer/
What makes good developers great, and what's missing in those who are not...
11 comments
I've read a lot of these types of posts and (sorry, rant) feel they're written only to make "good developers" feel better about themselves. I see no other value in such posts because "bad developers" won't learn these things by reading about them ...or they'd be good developers.
That said, the list is subjective. I, for example, fall nicely through the cracks of this particular categorization:
"Bad developer only sticks to what he knows ... reaction to any technical change is negative"
A the moment I'm most definitely avoiding change because I have 64k LOC that I can either a) finish, or b) migrate to .NET 4.5.
"Good developer ... finishes several technical books a year."
I haven't read a technical book in at least 4 years. But after 21 years' programming I own more tech books than many I work with have read, and I've read each and every one I own. So I'm actually quite comfortable with that.
"Good developer ... also very much concerned with the process quality"
Definitely not me. I had my process fix in the mid 90's and could no longer care less. Where I'm the architect I get on with it. Where I'm a program manager I tell the team what I need, and couldn't care less who does it, how or where it's done, or by how many. I care only about if, when, and quality.
"Bad developer completes tasks."
So should good developers. If all you ever do is to develop features which create value for customers, you're never going to get a product out the door.
"Bad developer always needs to allocate extra time to document and simplify."
This one is definitely me. My design may evolve. The next feature may highlight a bad design decision in the last, but the temptation is always there to work on the next-next feature, rather than refactoring something you know needs it. It's just time management. Also, this is at odds with "Good developer will ... always continue to clean and fix."
There are no absolutes. You just do what you're able. If you're bad and smart enough to recognize that fact you'll become good. Q.E.D.
That said, the list is subjective. I, for example, fall nicely through the cracks of this particular categorization:
"Bad developer only sticks to what he knows ... reaction to any technical change is negative"
A the moment I'm most definitely avoiding change because I have 64k LOC that I can either a) finish, or b) migrate to .NET 4.5.
"Good developer ... finishes several technical books a year."
I haven't read a technical book in at least 4 years. But after 21 years' programming I own more tech books than many I work with have read, and I've read each and every one I own. So I'm actually quite comfortable with that.
"Good developer ... also very much concerned with the process quality"
Definitely not me. I had my process fix in the mid 90's and could no longer care less. Where I'm the architect I get on with it. Where I'm a program manager I tell the team what I need, and couldn't care less who does it, how or where it's done, or by how many. I care only about if, when, and quality.
"Bad developer completes tasks."
So should good developers. If all you ever do is to develop features which create value for customers, you're never going to get a product out the door.
"Bad developer always needs to allocate extra time to document and simplify."
This one is definitely me. My design may evolve. The next feature may highlight a bad design decision in the last, but the temptation is always there to work on the next-next feature, rather than refactoring something you know needs it. It's just time management. Also, this is at odds with "Good developer will ... always continue to clean and fix."
There are no absolutes. You just do what you're able. If you're bad and smart enough to recognize that fact you'll become good. Q.E.D.
Fair enough...
The reason for good/bad developer statements is to help developers ares they'd like to improve at. And yes, this is a very subjective view of the developers I'd like to work with.
The reason for good/bad developer statements is to help developers ares they'd like to improve at. And yes, this is a very subjective view of the developers I'd like to work with.
I am sure every good developer should have crossed bad developer phase at some point in his life as a developer. Here is a different take on some of the points (sorry if you find offensive) -
Bad developer considers himself as a programmer, responsible for generating lines of code
Generating lines of code that still works is not bad and it’s not uncommon. As long as the developer knows the language and makes something work, it’s not a bad thing.
Bad developer understands only the technical problem at hand.
Bad developer is focused on building classes and methods and configuration files, but does not get the big picture.
Bad developer knows only the components he’s written.
It’s fairly common to have a workplace where the developer doesn’t get to know all the details because of restriction but as long as he codes the problem to spec and gets everything correct, he is not a bad developer.
Bad developer only sticks to what he knows.
Bad developer does not have time to learn.
Developers cannot be tagged bad just because they don’t learn technologies apart from what they are using. Some stick to one technology and they are pro in that.
Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix.
Even developers termed good tend to let QA find bugs.
Bad developer completes tasks.
What more is required other than getting the task complete.
Bad developer will wait until the finest details are available.
Without proper specs defined, even a good developer will have a hard time finishing a task. The more you think and question upfront, the better it is to code.
Bad developer thinks only about the elegance of his code and leave the job of delivering value to others.
True, he did his part and now it’s up to other teams from the chain to carry forward.
A developer who can solve a complex problem in a code that is easier for any developer to read and understand is a good developer. A developer termed good who writes code that is harder to read and understand by any other programmer is bad.
Bad developer considers himself as a programmer, responsible for generating lines of code
Generating lines of code that still works is not bad and it’s not uncommon. As long as the developer knows the language and makes something work, it’s not a bad thing.
Bad developer understands only the technical problem at hand.
Bad developer is focused on building classes and methods and configuration files, but does not get the big picture.
Bad developer knows only the components he’s written.
It’s fairly common to have a workplace where the developer doesn’t get to know all the details because of restriction but as long as he codes the problem to spec and gets everything correct, he is not a bad developer.
Bad developer only sticks to what he knows.
Bad developer does not have time to learn.
Developers cannot be tagged bad just because they don’t learn technologies apart from what they are using. Some stick to one technology and they are pro in that.
Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix.
Even developers termed good tend to let QA find bugs.
Bad developer completes tasks.
What more is required other than getting the task complete.
Bad developer will wait until the finest details are available.
Without proper specs defined, even a good developer will have a hard time finishing a task. The more you think and question upfront, the better it is to code.
Bad developer thinks only about the elegance of his code and leave the job of delivering value to others.
True, he did his part and now it’s up to other teams from the chain to carry forward.
A developer who can solve a complex problem in a code that is easier for any developer to read and understand is a good developer. A developer termed good who writes code that is harder to read and understand by any other programmer is bad.
I like this "Good developer will never feel his code is good enough, and will always continue to clean and fix."
I have modeled this article after some great developers I've always wanted to learn from, this is how they've treated their work.
"Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code."
In the long run or the short run?
In the long run or the short run?
these "good" and "bad" things are two nice little categories - they make thinking so much easier. i think this is the reason why i don't like this hegel guy.