Bad code gone wild
I've been writing software for quite some time (first computer) and have seen a lot of strange stuff.One thing I realized is that there are fundamentally two types of bad programmers.
#1 bad programmers that gets better.
#2 bad programmer that don't.
I can tell you I'm a #1: I routinely do things that are not optimal and "could have been done a better way", but don't beat myself up about. It is what it is and as long as the code "gets the job done", I'm OK with that. In addition, I'm OK with developers writing occasionally bad (wrong/suboptimal) stuff because I believe most folks can learn and get better. To this end, I found this amusing Bad Code Offsets
But occasionally I run across a #2: There are people who do things in broken and difficult manners and no amount of exposure to "better ways of doing things" will yield fruit. These folks, once they find "a way", it becomes magically "the only way" and will likely never find a "better" way. They will copy-paste write entire applications from snippets found on the internet. They will write functions that do the OPPOSITE of the the function says. They will do things that make you stop and ponder if they are deliberately trying to do the wrong thing (industrial espionage?).
For my own example, I can thing of a developer many years ago who was writing an asp application that was connected to a database with millions of rows. Their initial decision was to use a client side cursor and iterate through the resultset filtering rows that way. It worked fine on their dev box with 100 rows of data, but once they started testing, (with millions of rows) it seemed to just "hang" and never come back.
I overheard a pretty heated discussion between the developer and a DBA about why this was a bad idea, but the DBA seemed to not be getting through. I chimed in and tried to help out by drawing pictures but nothing seemed to help. To make matters worse this "developer" then complained to management that they where not getting "any help" in resolving the "performance problems with the test database".
From this developer's perspective the problem was really caused by the DBA team not setting up the test database server properly. It had nothing at all to do with this person's code because it worked on their machine.
For more fun stories, read The Daily WTF
One of my personal faves THE ULTIMATE STATE SELECTOR
#1 bad programmers that gets better.
#2 bad programmer that don't.
I can tell you I'm a #1: I routinely do things that are not optimal and "could have been done a better way", but don't beat myself up about. It is what it is and as long as the code "gets the job done", I'm OK with that. In addition, I'm OK with developers writing occasionally bad (wrong/suboptimal) stuff because I believe most folks can learn and get better. To this end, I found this amusing Bad Code Offsets
But occasionally I run across a #2: There are people who do things in broken and difficult manners and no amount of exposure to "better ways of doing things" will yield fruit. These folks, once they find "a way", it becomes magically "the only way" and will likely never find a "better" way. They will copy-paste write entire applications from snippets found on the internet. They will write functions that do the OPPOSITE of the the function says. They will do things that make you stop and ponder if they are deliberately trying to do the wrong thing (industrial espionage?).
For my own example, I can thing of a developer many years ago who was writing an asp application that was connected to a database with millions of rows. Their initial decision was to use a client side cursor and iterate through the resultset filtering rows that way. It worked fine on their dev box with 100 rows of data, but once they started testing, (with millions of rows) it seemed to just "hang" and never come back.
I overheard a pretty heated discussion between the developer and a DBA about why this was a bad idea, but the DBA seemed to not be getting through. I chimed in and tried to help out by drawing pictures but nothing seemed to help. To make matters worse this "developer" then complained to management that they where not getting "any help" in resolving the "performance problems with the test database".
From this developer's perspective the problem was really caused by the DBA team not setting up the test database server properly. It had nothing at all to do with this person's code because it worked on their machine.
For more fun stories, read The Daily WTF
One of my personal faves THE ULTIMATE STATE SELECTOR
Comments
Can you say the word team? Programmer one will not exist without the support of a strong team or mentor. The likelihood of the programmer being a natural is small so they're going to need someone to spitball ideas with and point out alternative angles.
You're absolutely right, some people just can't be helped but I think the reasons for the rise and fall of the programmer is a rich and deep story.
Good times.