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.