

Good Developer, Bad Developer - guynirpaz
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...
======
Spearchucker
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.

~~~
guynirpaz
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.

------
rjhackin
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_.

------
bwei
I like this "Good developer will never feel his code is good enough, and will
always continue to clean and fix."

~~~
guynirpaz
I have modeled this article after some great developers I've always wanted to
learn from, this is how they've treated their work.

~~~
pestaa
Who are they, if you don't mind me asking?

~~~
guynirpaz
It's not just one person, it's a collective set of characteristics of all the
good developers I've worked with at Totango, GigaSpaces, Mercury and other
places I've worked over the years.

------
tlogan
Bad developer might get rich, good developer will never get rich.

~~~
guynirpaz
Good developers are proud at their work... Some of them become rich while some
don't

------
cafard
"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?

------
voodoochilo
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.

