Lumbergh says: "If you voted, that would be greeaaaattt!" Login and vote now.
By jsugrue
via java.dzone.com
Published: Jul 09 2008 / 08:01
I’ve been reading a lot of articles lately outlining what defines a bad programmer. I find this to be a particularly interesting topic myself as often times I am accusing other programmers of being “bad”. Upon reflection, and after reading these articles, I must admit, this is an unfair term. The term “bad” in this context is completely subjective. By calling someone a “bad programmer,” you’re applying standards to them which aren’t universally true. It would be a fair assumption to say that we’ve all wrote “hacks” in our times, and on many occasions, those hacks were out of the necessity of the situation and not what the developer would like to do.
Comments
paul_houle replied ago:
this guy gives aid and comfort to the programmers that waste our time, give our profession a bad reputation, and cause our jobs to be outsourced to india
raveman replied ago:
maybe only india has good programmers?
killerweb replied ago:
One thing to remember is we can't all be experts at everything. I've seen some of the fastest and highly efficient algorithms sitting under the worst UIs imaginable. Does that make developer a "bad" developer? We all can't hit home runs every single time we code something. Science mixed with Art can sometimes produce weird output. Good for the author, sometimes it's hard to state things that go against the grain.
Gene Gotimer replied ago:
I've seen plenty of working, yet clearly bad code. If it isn't maintainable, understandable, portable, etc., it isn't good.
And occasionally, non-working code can even be good enough depending on when it fails.
leewalton.wordpress.com replied ago:
"Does it work" as a sole metric just doesn't cut it.
In a solution where you need scalability, flexibility, and business agility, using just "does it work" will cost you a lot of money down the line.
However, it should be the role of the architects and senior devs to nurture the "bad programmers"... it is likely that the reason why they are bad is either inexperience or through not understanding the non functional requirements of their deliverable, such as the scalability / flexibility requirements.
Voters For This Link (22)
Voters Against This Link (8)