Saturday, September 22, 2007

Confessions of a Terrible Programmer

I’m a terrible programmer. You would think that having done this for nearly 25 years that I should be pretty good at it by now. But nope, I still put bugs in my code, use the wrong types for variables or subprogram arguments, forget to make the right library calls, mess up the expression in an if statement, and on and on and on now for 25 years.

Sometimes the code won’t compile, and I can fix those bugs right away, but the rest of the time I have to actually run the program to be made aware of my failings. If I’m “lucky”, the program will start up and then crash in a blaze of error message glory that I can then pick through and use to figure out what I did wrong. If I’m not so lucky, the program will start and then almost immediately exit (assuming that wasn’t what it was supposed to do), or go off into la-la land, neither doing what it’s supposed to do, nor exiting. Or worse, look like it’s working just fine, and only when I’ve worked my way to some corner of the program’s functionality will something go subtly awry—occasionally so subtly that it’s not even noticed for awhile. Then of course there’s the non-deterministic bugs that manifest themselves only when a sequence of events (which may originate externally to my program) occurs in a particular order over a particular set of time intervals. The program may run right 999 times out of 1000, but that 1000th run may lock up the entire system. (Been there, done that, found the vendor library’s bug.)

The odd thing though about the programs I design and write is that once they’re delivered to the customer or as a baseline release they usually work like they’re supposed to, which would seem to be surprising given that such a terrible programmer wrote them. I mean I usually deliver the system on time, with the required functionality, and with very few bugs.

So what’s my secret?

Well, it’s one of these pseudo-Zen made-up Ancient Software Master’s secrets:

You will never become a Great Programmer until you acknowledge that you will always be a Terrible Programmer.

And as you saw in the very first sentence, I fully concede that I am a terrible programmer. So since I love programming and this is my chosen career, I have to deal with it.

Fortunately there’s a lot of ways I can cover up the fact that I’m a terrible programmer:

1) If I get to pick the programming language for a particular program, my “go to” language is Ada. Yeah, I know it’s pretty much unheard of today outside of the defense industry, and even there it's struggling, but it has few peers when it comes to pointing out to a terrible programmer just how bad they really are. With all the language’s typing and run-time checks, it’s little wonder that programmers didn’t like Ada, since it was constantly pointing out bugs in their code!

If I can’t use Ada, well, then Java is the next best choice, since it’s got a lot of the same built-in bug detection capabilities.

But please, please don’t make me use C++ any more, which is definitely the enabler of terrible programmer egos. It lets most everything through, so a) I feel good about getting my code clean compiled and “done”, and b) I get a huge ego boost after the Jolt-fueled marathon debugging session that's needed to successfully get the program mostly working.

2) I use programming assertions, a lot. If some variable should never be null, I assert that it’s not null, even if Grady Booch has sworn on a stack of UML standards that it will never be null. Here’s how paranoid I am about being found out: even when I control both sides of an interface, I’ll assert the validity of what the data provider is providing, and assert what the receiver is receiving. Why? Because I’ve been known to change one side of an interface and forgotten to alter the other, so the assertions catch those for me right away.

3) Be a testing masochist, i.e., I ruthlessly try to break my own code. No programmer likes doing this, we’re usually happy to just get the damn thing running the way it’s supposed to with the test case data, so why go looking for trouble? I admit that it’s a mental challenge to intentionally attempt to break one’s own code, but if I don’t, somebody else will, and my secret terrible programmer identity would be revealed.

4) Have other programmers inspect my code. Despite everything I do, as a terrible programmer there’s still going to be bugs in my code. So I need other programmers, especially other Great Programmers, to look at my code and find those bugs. And I’m serious about these inspections, I don’t want some cursory glance that simply makes sure I’ve included the right file header information, I want an inspection, dammit! I had to pound on one of my inspectors once because he was “doing me a favor” by not recording all the defects he found, because he didn’t want me to “feel bad”. Look, I have no self-image as a programmer, so “feeling bad” isn’t something I get hung up on. I need to end up with Great Code, so as a Terrible Programmer I need all the help I can get!

With these and other terrible-programmer-obfuscating techniques, my code often does come out looking like it was written by a great programmer. And I’ve done well by those techniques over the years, during my career I’ve had the opportunity to work on the real-time executive and aero data analysis for flight simulations, did a clean sheet redesign of a major defense system’s command and control planning system, taken sole responsibility for rehosting a large command and control system, done data mining and event correlation in an XML framework for another large defense system, and replaced a legacy wargaming operator console with a net-centric ready version. Outside of my day job I write open source software (in Ada!) and some of it has been picked up and used by a company supporting the European Space Agency. (I’m goin’ to the moon! Helping, anyway.)

So I’ve been successful in hiding the fact that I’m a terrible programmer up to this point, and I need to make sure that I can continue in this career path until my retirement. Heeding Han Solo’s admonition ("Great kid, don't get cocky."), we come to the second fake Zen Old Software Master italicized aphorism:

You will remain a Great Programmer for only as long as you acknowledge that you are still a Terrible Programmer.

Over the years I’ve learned more ways to hide my programming failings. One technique: let the program crash—This works, just stay with me. I’d joined a development project where the original developers had so many problems with run-time exceptions that they simply starting including “null exception handlers”, i.e., catch all unexpected exceptions, suppress them, and keep on going. Needless to say, the system would run fine for awhile, sometimes hours, and then slowly start to...hmm..."veer off".

When I got the chance to redesign the system, one thing I immediately forbade was those null exception handlers (though handlers for recognized exceptional conditions were permitted). If an exception occurred, I wanted it to propagate up until it took the application down so that we would know about it and could fix it right then and there. I got my wish, but was almost found out in the process. The program manager got wind that we were seeing a lot of system crashes during testing, and he wanted to know why the redesigned system was crashing so much more often than the one it was replacing. Explaining that we were uncovering errors and getting them fixed now, and fixed right, didn’t really give him the warm fuzzy he was looking for, as there were deadlines approaching and the reported error rate wasn’t declining as fast as he liked. The team stuck with this practice, though, and when we were done (on time and on budget) the system ran reliably and correctly for days under both light and heavy loads.

For me, this cemented my self-image as a terrible programmer. If I could bring this kind of a system to fruition, meeting all its requirements and budget and schedule constraints, just by conscientiously applying a slew of techniques for uncovering my programming failings before they got into the final product, then I knew that I would be able to fake it for the rest of my career.

Now if you look at my code you might find it to be pretty bad, and that’s normal, pretty much any programmer that looks at almost any other programmer’s code will judge it to be a pile of offal and then proclaim that the only way to fix it is to rewrite it. (I wonder why this is?)

But if you want to sit down with me and go over my code, and tell me what’s wrong with it, then I think we can work together to fix those problems and make it truly great code. And who knows, maybe you’ll end up being as terrible a programmer as I am.

99 comments:

Anonymous said...

While acknowledging you're a Terrible Programmer may be necessary to becoming a Great Programmer, it's not sufficient.

dgurba said...

I think you're taking the right steps to becoming a better programmer and using sound reasoning to get you there.

I learned Ada[95] as my first programming language in Junior College for basic programming logic and then data structures. I too really like Ada from a strict, hard to make errors, and readability standpoint.

I now use PHP and Ruby alot for web work ... and haven't touched Ada in a few years ... but it will always have a soft spot in my heart :)

-dg
davidgurba.com

The Flomblog said...

Just one word: COBOL

Mike said...

I can relate, but you definitely should try Python (or Ruby). For problems for which they are appropriate, it's much easier to reach "bug-free nirvana", IMHO.

Wilson said...

I wasn't going to mention this, but someone else already mentioned Ruby, so hey, the ice is broken.

In Ruby, I use a very nice tool called Heckle:
http://ruby.sadi.st/Heckle.html
..that modifies the application code to help assert that your unit tests give you full coverage.

I don't know if Ada has something similar, but it seems like it would be even easier to implement there, with the vastly greater static analysis available to you.

Anonymous said...

You meet deadlines and produce results, at least you have not caused any deaths or caused WW3 (I hope). Perhaps you're a good coder but not a good designer. Pick up Code Complete or design patterns book and start improving your design and approach skills.

Anonymous said...

Good explanation of egoless programming theory and praxis, although distinctly dry.
Unfortunate that most of the comments appear to be based on the title alone. The author is obviously a gun programmer, and generous enough to share his insights; IMHO, he is not seeking programming advice from those who demonstrate their ignorance (and avoidance) of egoless programming.

Lucian said...

Most of the guys here didn't get it, did they? But I'm a terrible reader so..

Anonymous said...

wow, so no-one actually read the article did they?

Instant bookmark and reference :) on my part.

Anonymous said...

I completely agree on each point. Code reviews, Asserts and Static typing are the 3 greatest tools to save a programmer. It's nice to see that my personal ethos has done you well: let it crash.

One of the scariest things for me is writing a few hours of code between compiles and then: it compiles and runs. It shouldn't ever do that - I should have *some* compile errors and *some* Asserts fire on completely new code. I then get paranoid that the subtle bugs you describe are hiding in waiting for me.

Two last tid-bits of wisdom. The greatest programmer I met was a kid with a degree in Maths. He was legendary for the least fix-failed and knock-on bugs. One day I sat next to him as we went through a bug I found in his code. He fixed it quickly (it was a minor error) but spent 15 minutes going through _every_ code path he had changed. Line-by-line in the debugger inspecting each variable in scope verifying everything. I was amazed - he was not actually more talented than me, he was more rigorous. Second was a bloke who put a break point after each open { in the code he wrote. Whenever a break-point was hit the first time he stepped through the code verifying it. If a breakpoint was going stale (had sat un-hit for a long amount of time) he examined the code to find out why. I haven't yet learned such rigor as these two - but they stand in my mind as pinnacles of our art.

Aaron Denney said...

On the static typing front, you really should take a look at Haskell.

Anonymous said...

...it is time for you to leave the Monastery Grasshopper...

...we have nothing more to teach you...

Anonymous said...

... and then proclaim that the only way to fix it is to rewrite it. (I wonder why this is?)

Hmmm... Does the impulse to rewrite existing code come from a desire to have complete understanding which can only come from implementation? Or is it just a primal instinct to control and take ownership? I feel the answer to your question would say something profound about us and how we build software.

Johan Idstam said...

Hello

My name is Johan and I am a Terrible programmer...

Ognjen said...

My name is Ognjen and I am Terrible programmer too. Btw, great article.

Laur said...

You're not only a Terrible Programmer, but a Terrible Writer as well.

For which we humbly thank you.

Anonymous said...

I love all the idiots completely not getting it and offering advice, brilliant!

Anonymous said...

Two techniques I use to overcome my own failings are:

(1) After I write a program, before I try anything else such as a compile, I print it out and read it line by line, slowly. It's surprising how much gets left out by the fingers and brain in the original entry, or was just plain wrong. Also I check each variable definition and use and cross them off.

(2) After a compile, I check each "if" to make sure it actually gets tripped, and tripped for the reasons I expect. I ensure all exceptions/messages are fired as expected. Isn't it a truism that writing the required algorithm is the easy part? The time- and code-consuming part is putting in all the stuff that filters the execution path to follow the algorithm and not wander off elsewhere due to unexpected input or whatever.

Not terrifically formal, and nowhere as professional as the author's techniques. Just something I do for my own stuff.

datatype said...

My secrets:

(1) Never, ever, copy and paste code.

(2) Use a statically typed language. (Ruby and Python people: dynamic typing is NOT helping you catch bugs earlier! Why would you think that?!)

Anonymous said...

I write the code from beginning to end without stopping or reviewing. Then I release it as "beta".

Rik said...

Really enjoyed reading this, I am a terrible coder too :)

Marc said...

Thanks for the comments, I'm glad this resonates with other developers.

A couple other things I do, as also mentioned above, include frequent compilation and making the first run of new code within a debugger.

If I'm doing Java in Eclipse instant compilation obviously happens pretty much automatically.

With Ada or C++ I compile usually after each procedure or function, if it's small, or after writing a "code block" within more extensive functions. For me it's "check early, check often". I know people who write all the code of a package or class before compiling it, and it works for them; I would probably have to go back and rewrite half the thing if I did that :-)

The first time I run through a new chunk of code I usually do as some others here have mentioned, and go through it in the debugger to just monitor that everything is working as expected. And when something goes awry, I've got the entire context of data and execution path that got me to the bug.

Wilson said...

The people commenting on the comments (and calling those who offer advice idiots) are the ones not getting it.

Are you saying that the author of a blog post like this is ready to stop learning about new ideas and techniques?

Mike said...

The commenters who are offering suggestions are the Great Programmers. They just want to help out the Terrible Programmer.

Frank C said...

"If I tell you I'm good, you would probably think I'm boasting. If I tell you I'm no good, you know I'm lying." - Bruce Lee

Anonymous said...

This is a great post for self-improvement and introspection, it really inspired some personal reflections (and maybe a little type hinting).
I have to rewrite some code now...


class MyBrain extends MarcsBrain{
public function __construct(){
if(Conscience::aknowledgement() == true){
echo 'You are a terrible programmer!';
}else{
echo 'You are a really terrible programmer!';
}
}
}

Sean said...

Profound and wise.

I find that the more I learn, the more I realize I don't know (and therefore want to learn).

I've found that something between your approach and TDD works well for me, and that code inspections are priceless.

Keep it up.

timmay said...

The commmenters who are posting comments on the original comment posters are the ones who aren't understanding the commenters of the author's original post comments and they are the ones who are the turning the Terrible Programmers into Great Programmers in the first commented sense of the word.

And if anyone comments that I'm not getting it, then they haven't properly deconstructed the comments made by the Terrible Programmers who were commenting on the original comments in the first place, the one who proclaimed to not be getting it by the original commenters commenting on the posted comments by the so-called Great Programmers. I should know because I was once a Terrible Programmer who has turned into a Great Programmer and now is relegated to commenting on comments by posters who comment on how the original commenters who commmented on comments made by Great Programmers just don't get it.

Dinu said...

LMAO!!! Awesome post.

My name is Dinu, and I'm a Terrible Programmer as well.....

Mario Gleichmann said...

Seems like i'm more a terrible paranoid programmer, as i'm feeling impelled to run all of my tests after each and every little implementation task.

Even worse, i meanwhile feel forced to write a test to specifiy intended behaviour. Without that kind of spec i can't write any line of code any more. Isn't that a terrible big spleen?

;o)

Anonymous said...

ok i'll accept, i'm a good programmer, i dont use assertions and i dont know wat ADA looks like, heard she was dead or somethin.

But i'll say it, thanx terrible programmers, at least now i hav a yard stick to measure how good i am....

this is Mohsin Alam the good programmer.

Objecto Permanente said...

Hi. I'm not even a programmer, but your post was inspiring.

Anonymous said...

Heh. I wish I was a Terrible Programmer. As it stands, I'm just a terrible programmer. But hopefully I'll earn the capital letters some day.

Anonymous said...

i think debbuging is bad idea, logging is much better .. you dont have to log everything, but can do if condition for logging. when you log you dont have to remember array of values, you see it and make better judgment.

TDD is great, idea but ... it still takes too long to use it. plus you cant TDD everything.

domus.vita said...

Ada.NET? Anyone? Anyone? No? Okay.

Toup said...

I wish I were a terrible programmer. Instead of this, I tend to find myself good at times.

Hopefully this (terrible, thanks !) article will help me getting a lil less great, overtime :)

Anonymous said...

I wish some day to become a Terrible Programmer. It is only by discipline and sacrifice that I may aspire one day to be truly Terrible. Right now I'm just a BoneHead Coder. And yet I get the impression that I know more about coding than at least 80% of DragAndDrop crowd. Which is truly Terrible itself.

Marc said...

Re: "Ada.NET? Anyone? Anyone? No? Okay."


"AdaCore First to Bring True .NET Integration to Ada"

codevigilante said...

Very inspiring for an "older" person new to programming. I shall strive to became a Terrible Programmer, ans shall work on it every day.

Pedro Galván said...

Marc,
I am an editor of a software development magazine (in spanish). I would like to translate and publish this article, providing the reference to the original. Could you please contact me let me know if you are ok with this?

Pedro Galvan,
pedro@softwareguru.com.mx

Jon C said...

I too am a Terrible Programmer.

Another fantastic tip is not only to get someone else to look at your code, but to try and explain it to them and encourage them to ask questions. Make sure you ask them to go through it on their own first though so you don't sully any observations they might have made with your own assumptions!

Fantastic article and it's a pleasure to meet a fellow Terrible Programmer :-)

@anonymous (about logging):

What makes you thinking logging a programs operation is not a form of debugging?!

Anonymous said...

I am framing this, so good...

It is truly zen, the best advice you could give a novice (or any, for that matter) programmer, yet the worst since the novice is going to look at you with his or her eyes glazed over only to find out about 10 years later you where right

Anonymous said...

... and by the way, i aspire to be a Terrible Programmer someday.

Guido

Marc said...

Guido(?) wrote:

"the novice is going to look at you with his or her eyes glazed over only to find out about 10 years later you where right"

See Dinosaur Programmers Know More Than You Do

Anonymous said...

What a Terrible Article. Makes me want be become a Terrible programmer from the Great programmer I am now.. a long way to go.

Some of the Terrible programming techniques I follow without realizing they were Terrible:
- Frequent compilation
- tracing like crazy
- meaningful variable and method names
- Get a peer to look at the code when I cant get the 'bug' after 30 minutes!

One major Great technique I am not going follow.
- Jump to code as soon as possible - I need to spend more time with a paper and pencil!

Will read this Terrible article more often, you inspired me to make my second comment on the internet.

Anonymous said...

Well, I guess you guys don't have to maintain programs that are 25000 lines of proprietary 4GL "database-independent" code...

Tjerk said...

Human make errors, until there is a program verification tool that can verify the logical correcetness of the programmer we have to use defensive programmer

Ruby is NOT the solution. Ruby lacks Strong Typing. And Strong typing is a typical tool to help support defensive programming... The compiler should check as much as possible.

Currently at our university we are working on ModelCheckers.. These tool can check whether some piece of software is correct ( no deadlocks, no race conditions, and asserting certain states will eventual become true (temporal logic)).

Serious, programming is at its heart a mathimatical construct

Anonymous said...

I keep my coding issues under control, by:
1. Logging each normal event, so you know what happened OK before a program issue.
2. Logging anything suspect.
3. Throw an exception in incomplete code, as a nasty reminder that you haven't finished the code.
4. Throw an exception if an unexpected state or data type/value is encountered.
5. Log ALL exceptions, even fatal ones.
6. NEVER allow non-fatal exceptions to 'crash'a program; there maybe many other terrible bugs which need to be logged, so that many bugs can be found and fixed in less iterations.
7. Never allow live software to 'crash' unless it reduces customer hassle; the customer only case about the bottom line, not programmer convenience!
8. Make damned sure someone is assigned responsibility to monitor application logs, otherwise terrible data and code can go unnoticed for months!!!

Chinmay said...

Nice n thought provoking post...! Makes me wonder if Programmers at Yahoo/Google/Microsoft/Adobe think so too :-)

Enjoyed reading this interesting post..!

Duke Ganote said...

I'm a Terrified Programmer: terrified that someone will call me in the wee hours of the morning to fix something I wrote. So:

1. ADA <~> PL/SQL
2. Instrumentation
3. Find a mentor. There's always someone better than you in any given area.

Dangote said...

I use Test Driven Development to help me.

href="http://www.agiledata.org/essays/tdd.html

http://c2.com/cgi/wiki?TestDrivenDevelopment

http://en.wikipedia.org/wiki/Test-driven_development

So I write unit tests first, then i write the code to make it pass. This has many advantages.

Whenever I find a bug, I do my best to write a unit test first to replicate it, then I go fix it. That way, the bug will not reappear (else the test will fail first)

Tony said...

I fully agree that TDD is the way to go, and to the person who said earlier you can't TDD everything, I heard that many times and decided to prove what you can and cant test. In the Java world, the only think you cant test that I've found is calls to System.exit.

I've published my TDD lessons here

http://homepage.mac.com/hey.you/lessons.html

oh, and by the way, my name is Tony and I'm a terrible programmer. Thanks for the great article.

Sherwood said...

Very cool. I kept reading, thinking "I'll stop at the end of this paragraph". I ended up reading the whole thing. Very good. I hate it when I read something that points out my own failings. the Terrible Programmer did this quite well. Perhaps this is why so many did not like it.

Anonymous said...

Wow. I am pretty sure that anyone finding this blog entry is going to be sure that I wrote it but I think you are being too hard on yourself. I prefer to think of myself as extremely adequate.

Anonymous said...

This was a great read. I wish I was a terrible programmer :]

Anonymous said...

Hi, I'm Stew and I've been a Terrible Programmer for almost 25 years.

Great article. I'm glad to learn it's not just me! Thanks for the tips.

For me, the rigor of TDD really improved my code quality. I went through a phase where I was releasing really bad code about 5 years ago and had to get the TDD "religion" to get back on track. Now I find I don't need to be that rigorous anymore, but I still use unit testing to keep anyone else from seeing my terrible code.

The language I work in didn't have a unit-test tool that I liked, so I built my own (and tested it thoroughly!). That time was well-spent.

Another simple tool I've found to help is a Code Beautifier right in my IDE editor. Even before the compiler checks over my terrible code, if the Beautifier can't figure my code out, then there's got to be something wrong.

Good luck to the other Terrible Programmers out there.

Anonymous said...

Hi!
I'm Katarina and have been a really terrible programmer for 3 years now.
I have been fooling myself that I'm going to get better but I guess I am not going to. :)

Great article by the way.

Joe Kueser said...

I've sucked for about 15 years now, but at least I've learned to unsuck quickly.

I often (meaning rarely) have naive junior programmers and interns ask me, as I find their mistakes very fast, "how did you get so good?" My answer is always the same: "Me? Good? Nah, I suck. I've made every mistake a programmer could possibly make...and continue to do so. I make the same mistakes so often that I just know how to fix my mistakes quickly."

They usually think I'm pulling their leg, and shake their head with that "oh that Joe" look, not knowing that I'm being honest. I suck.

Marc said...

Joe said:

"I've made every mistake a programmer could possibly make...

Which of course is why you find bugs in other programmer's code so easily :-)

And which is why I became a serious pain in the ass to two software development groups when I spent several months doing system test.

Anonymous said...

This is a very good article. And that's terrible.

Bala said...

Great Article man!!

Anonymous said...

Hi.

I'm a terrible programmer.

Here are some of the wise things I do to ensure that my software is good though.

- You should maybe do the same.

What a terrible programmer I am to do such things!

.. or AM I ? *hint* *hint*

BTW, if you follow my advice, you can become as "terrible" a programmer as I am!

Did I mention I'm a bad programmer?

nwaringa said...

Great article.

However, I have an uneasy feeling in the pit of my stomach. It groans that this article should be entirely re-written.

jhordies said...

Great article !
I'm only hiding for 8 years now, but i would like to share another tip.
I usually start coding by writing all the comments.It becomes kind of a todo list.So when comes the time of the hide and seek party with a bug, i just read what i thought i was doing and compare it with what i actually did. And eventually it will reveal to me how stupid i am. So if you read my code don't laugh when you see that kind of thing.
//Close the stream
stream.Close();
That's how i keep my job ;)

Anonymous said...

http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande

Anonymous said...

Interesting article in the New Yorker about the limits on our ability to deal with complexity and a simple crutch.

Anonymous said...

I do the same thing with comments, I make an outline of comments, and then fill in the blanks. Kudos on the article. I've been interested in Ada for a while, and this may be the tipping point I needed to jump right in.

Worthless Programmer said...

Thanks for the article, but it didn't make me feel good. I'm just a Mediocre Programmer, and have given up all hope to become a Terrible Programmer, because I'm sometimes still a Great Programmer. I haven't implemented all your terrible practices. Seriously, I don't know what I'm doing in this profession, but I think I'll such more in any other profession.

@Tjerk: who's going to verify the program verification tool?

beeradg said...

It really does seem that many have had trouble seeing your post in all its glory. I love some of the heartfelt and complete suggestions. I believe that you are a great programmer. It is ok, cause I am certain you will wholeheartedly disagree with me. But I'm horrible as well, so what does my opinion matter.

Anonymous said...

bookmarked! thanks for sharing your experience to help people like me suck.

Anonymous said...

I am not a programer, I am a BA, but found this article fascinating, wondering why i found it so interesting. I appreciate Terrible Programmers like you who test their own stuff before it goes to QA, Otherwise I get calls from QA to understand why the system works differently than was outlined in the business requirements.

Press on and hope you succeed till retirement.

Anonymous said...

I am not a programer, I am a BA, but found this article fascinating, wondering why i found it so interesting. I appreciate Terrible Programmers like you who test their own stuff before it goes to QA, Otherwise I get calls from QA to understand why the system works differently than was outlined in the business requirements.

Press on and hope you succeed till retirement.

Anonymous said...

Well I'm not quite terrible yet - but I am striving to be worse. In fact one of my favorite books is "The Ten Worst Moves in Chess" - not that I'm defensive or anything.

Anonymous said...

If the code compiles on the first try without errors, something is very very wrong...

If a variable can only have a value between 0-5 it will probably get the value of 6 sometime...

and so on... =)

/M

Aatch said...

The first thing I do on my first successful compile. Try to crash the program at runtime.

If you have a short debugging phase, you are either letting things slide, or you have some logic or hidden bugs.

On that note, if something I write doesn't work the /exact/ way I want it. It doesn't work.

Hans Worst said...

hey, i just paid a friend 50 euros to make him code a php-fontsize-magnification-function for me because i'm the most terrible programmer here, did i make that clear?! (it worked out btw)

Jaassu said...

I am 43 and programming has been kind of hobby.
I have often wondered why it seems so that many popular languages are so cryptic and illogical(C++, PERL, Unix shell scripts).
It is probably just great to write code that makes us bad/mediocore programmers suffer.
I have always felt that simple languages like BASIC, and PASCAL are more fun and one can do most things with those except writing Linux kernel(yet).
Because your article I just started learning ADA basics, and it really seems to be very nice language, I just wish that there were jobs in Finland to do some ADA work.

Marc said...

@jaassu:

Tidorum, Ltd. is in Finland and uses Ada. While they may not have any openings, they're more likely to know the state of Ada in Finland and elsewhere in Europe. Send them an email at info@tidorum.fi

Good luck!

Martin said...

I just love this post. It's so true. Especially the part about C++-programming and type-checking. How often did I hear someone saying: "This value can not be null, so there's no point in checking it..."

Greetings from Germany,
Martin

Anonymous said...

Respect all the way, you're a great guy. And I believe you are a good programmer from your descriptions.

Anonymous said...

I copy & paste
I don't test anywhere near enough
I don't comment anywhere near enough
I am constantly suprised to find some application I wrote still in production years after I wrote it.
I tell people I am not a good programmer.

Yet oddly, people still want me to write software. I don't get it!

Nice blog though.

Jim said...

I wish I was a Terrible Programmer...

Actually, I'd be happy if I was a Not-So-Good Programmer.

ldso said...

I'm a little turned around at this point, not only did I read the article, but also all of the comments. So let me back up from the Terrible==good idiom for a moment. I mean this as a compliment; this was a great article!

It also struck a chord with me, as recently someone felt it necessary to personally attack me, by verbally letting me know what a novice programmer I am. I will not assume that novice is anywhere near Terrible, but if I'm working at a novice skill level, then novice is okay by me :)

I too make programs that crash. When the system is in a state that I don't think it should ever be in, I am novice enough to think that we should know about the problem. Maybe someday I'll learn better.

I also write programs that poke around the API. I am novice enough to think that sometimes the API might not have been implemented correctly.

So thank you from a fine juvenile delinquent novice programmer! And may your chest swell with pride at your Terribleness.

Michele said...

I aspire to reaching Terrible Programmer status...

Thank you for a wonderful post :)

Anonymous said...

Great article. Wish I could become a Terrible Programmer, but my manager wants my software tomorrow and I've just received a new feature request from the user. Thank you again inventor of copy paste.

Anonymous said...

Enjoyed your article, thanks for posting it.

noodle said...

This is interesting. I posted a blog recently that contained a similar concept. Accepting that you are not the best programmer is the first step to being the best programmer. Weird eh?

Check it out

http://joelinpointform.blogspot.com/2009/03/7-steps-to-happiness-as-software.html

Anonymous said...

My name is alan, and I'm a terrible programmer... actually i am getting to the point (after 25 years - i started at 13) i don't even know if i can even program anymore - is that akin to an outer body experience ?

you rock man. so true.

Sam said...

Wow! Almost 2 years worth of comments. You definitely struck a nerve with this article.

I stumbled onto this article and find myself unable to avoid commenting as well (everyone who programs thinks they have something they can add).

I'm a Python coder and for those ADA, C++, and Java weenies, I've coded in all those languages except for one (ADA). I like Java but hate the speed of execution. I love C++, but hate the fact that it's not really designed for the web.

All tools are designed for specific tasks and this includes the Ruby, Python, Perl, PHP, and other similar languages. Before you hop on a high horse and assume that the language you code in is the *best*, think about the application of your code. Is it limited to specific areas (in my case mostly on the web)?

I love Python and would be much less fond of programming if I had to do it strictly in Perl, but that doesn't mean I won't use Perl, it just means I'll try to avoid it ;)

Well, I guess if you really pressed me you'd find out that I just plain love to write code. I guess if Python didn't exist, then I'd either be designing a similar language right now or I'd be getting by with C and C++

Maybe that's the difference between the bad programmers (like me and some others) and the good programmers: the bad programmers are the ones who'll write code in any language you require of them (griping notwithstanding), and the good programmers are the ones who will demand that the language be changed to meet their needs.

Tim said...

Hi, I am Tim and I strive to become a terrible programmer someday. I also read the article and the comments - superb article and even some suberb comments!

I'll now add this comment, let the spellchecker run, compile it, assert that it was added and review your articles code to see if this comment is what I wanted to add.

anollipian said...

This Post is Amazing
I Really Like it So Much
Thanks alot
Hope I could someday be a terrible programmer just like U ..

Ofer said...

My name is Ofer, and I'm a Terrible Programmer.

Having used Ada at NYU, I can say that it is the Nazi Germany of compilers. That language will shout at you for anything and is pretty much designed to prevent you from running your program at any opportunity. This is probably why most programmers don't like it. Getting your garbage code in C or C++ to compile and then crash at runtime seems more satisfying to most people for some reason... However, in truth, the more problems one's program get weeded out, the better, so having a strict compile-time guards against most of this sort of stuff... And static-typing helps too. I can't tell you how many errors in Perl I've seen confusing a string with an integer (or vice versa) that happen MONTHS or YEARS after the final product shipped.

I agree that if something might crash, better to let it crash, preferably with as much info as possible. (If your company allows you, then keep that debug mode on for production-level code. You will locate & fix problems much quicker when your customers complain.) Of course customers generally hate crashes more than incorrect numbers/behaviors, even though in most cases, the crashes are easier to fix... Though sometimes, PROPERLY fixing crashes or incorrect behaviors/numbers is more of an art than a science...

Ofer said...

BTW, most "Terrible" Programmers are better than the people proclaiming themselves to be "Outstanding" Programmers (meaning the "Terrible" programmers are more careful in how they code & therefore produce better products by the end of a project). The "Outstanding" programmers are the ones managers should really be cautious about.

W K said...

This post was humorous and it really lifted my spirits. I've been programming C++ for about a Month now and I stink at it! My codes are absolutely terrible!
Nonetheless - I still like C++ for the very reason that it lets everything go - It's more exciting to use a language which lets things go wrong - I learn more that way.

Yaseen Abbas said...

I also missed that because i aven't touched Ada from many years.


online sweepstakes
church software
blackjack software

Anonymous said...

A comp.lang.python just referenced this post of yours. It made me laugh, and it's true! I want to be a Terrible Programmer, too!

Rustom Mody said...
This comment has been removed by the author.
Rustom Mody said...

Thought provoking post -- Thanks for that

Ive written a complementary
post

Anonymous said...

At first, it (the politically, gender and what-ever correct phrasing) thinks it understands everything, then it learns it understands nothing, then it is again lured into thinking it understands something ...

Being a Terrible Programmer is not the goal, it is the Path ;-)