Signs You're a Crappy Programmer (and don't know it)

http://damienkatz.net/2006/05/signs_youre_a_c.html

by hhm • 19 years ago

35 65 19 years ago

damienkatz.net

edu• 19 years ago

Oh, well I'm not crappy then. Neither I'm a good one though...

DarrenStuart• 19 years ago

I think it should have been "Signs you are a day coder (and don't know it)"

I am amazed how many programmers I have worked with who are not up to date and just do their job and are not interested in it.

edw51914• 19 years ago

"...and it often simplifies the code to have multiple returns."

Today. And what happens after 10 other programmers modify your slick little multi-return function? Nobody will ever be able to modify it again because the entries and exits are lost among the garbage. This is the ongoing debate I've had for years with "clever programmers". They're missing one critical point: the guidelines of structured programming are not meant to make your life easier; they're meant to keep the code alive longer by making life easier for the poor schmuck who has maintain it (usually me).

Another Sign You're a Crappy Programmer:

You make your own rules in direct violation of effective established principles because you think you know better.

boucher7• 19 years ago

Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs.

It isn't always about being clever.

edw51914• 19 years ago

"I'd rather detect an error and bail then have a slew of nested ifs."

And here's what inevitably happens when you do that:

14 mods are applied and your early exit(s) get lost in the muck.

Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months.

Then I come along, find the errors, fix the data base, advise the user of the effects of the damage, and rewrite the whole program with single entry/single exit processing so that this never happens again. And then post to a board like this only to re-engage in the same old debate.

Aside from poorly named variables, violation of "single entry/single exit" is the biggest lifespan reducing problem of code bases I've ever seen.

This is the future speaking. Please don't do that.

Tichy5• 19 years ago

That's what the other rule is for, to not make functions span too many lines ;-)

akkartik5• 19 years ago

Don't worry so much about how you or others will modify it, and how it may look when it's 10 times hairier. That's what refactoring is for.

BitGeek2• 19 years ago

The number one sign you're a crappy programmer:

1. You foist idiocy upon others and refuse to listen when they point it out as such, because someone told you that the idiocy was "effective established principles".

Your "effective established principles" seem to be neither effective, nor established, nor principled.

edw51914• 19 years ago

"neither effective, nor established, nor principled"

http://en.wikipedia.org/wiki/Structured_programming

Isaac Newton "stood upon the shoulders of giants." Interesting to see that you know better.

-----------------------

"...someone told you..."

Actually, I learned what I'm sharing in this thread (and much, much more) from MANY excellent mentors. I hope you find some, too.

----------------------

"The number one sign you're a crappy programmer"

I have hundreds of (well paying) clients that would disagree with you.

----------------------

I "foist" standards only upon those who work for me. You won't ever have to worry about that.

imsteve• 19 years ago

I'll give you the vote because very often hard-set rules in programming are not good.

edw51914• 19 years ago

10 Real Signs You're a Crappy Programmer:

10. The exact same code is in multiple places because you didn't bother to put in into a common function.

9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished).

8. You have early exits from loops because you don't know how to properly code a recursion.

7. You execute too much code because you don't know the difference between "if" and "case".

6. You use 10 lines of code when 1 line would do because you don't know any better.

5. You need to run batch jobs from time to time to clean up your data base because you don't know how to debug well enough to find what's messing it up.

4. A third grader doesn't know what your variable names mean.

3. You think "Third Normal Form" is paperwork you need to fill out for one of your 8 bosses.

2. No programmer who has to maintain your code would ever want to work with you.

1. Any programmer that has to maintain your code would be more than happy to accept the consequences of first degree murder.

omouse2• 19 years ago

0. You refuse to use recursion even when working with a language that supports it properly because you think it's horribly slow.

boucher7• 19 years ago

"a language that supports it properly..."

Meaning what exactly? A language that automatically optimized for tail recursion? Are there languages which don't support recursion "properly?"

boucher7• 19 years ago

"8. You have early exits from loops because you don't know how to properly code a recursion."

Wow. Not every problem calls for recursion. If you really hate early exits from loops, maybe you should just code the loop's condition differently.

edw51914• 19 years ago

"If you really hate early exits from loops, maybe you should just code the loop's condition differently."

Exactly.

Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

Goladus7• 19 years ago

(6) Happens even when you know better.

(10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.

edw51914• 19 years ago

"...obsessing over a few bits of code duplication is often a complete waste of time."

For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then.

Minutes "obsessing" today usually saves hours testing tomorrow.

DanielBMarkham6• 19 years ago

"obsessing over a few bits of code duplication..."

Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.

DanielBMarkham6• 19 years ago

I have to disagree with #6. You can either write code for the compiler or the human. I prefer to write it for the human, because a lot of times the compiler understands exactly what's going on, but I'm pretty clueless when I come back after only a few days. I think you meant not understanding how the language works so using a lot of extra commands when one would do. However it's common to "dumb down" your code, especially if it is tricky, for the poor schmuck that has to maintain it. Remember -- writing code should not be like writing a mystery novel.

at• 19 years ago

"You are adamantly opposed to function/methods over 20 lines of code."

There are (at least) 2 problems with long funtions/methods: 1) They typically lead to more duplicated (and less reusable) code, e.g. repeated blocks of code between functions that could have been replaced with to-the-point short functions. A typical sign of where to extract a function is when you see a long block with a comment above it inside an even longer function, then replace the block with a function with a name inspired by the comment.

2) The methods becomes harder to test, and possibly even more important, the test code becomes harder to maintain (and untested code of some complexity usually doesn't work), e.g. what happens to your existing tests if you add some new conditions at the top of a long method?

Tichy5• 19 years ago

A good argument might be chunking: the (average) human brain can keep only about six or seven chunks of information in short term memory.

A method with 20 lines of codes is roughly 20 chunks. Move some parts of those 20 lines into other functions, and you have created more effective chunks. Presumably, the brain has a much easier time understanding things it can actually keep in memory.

One idea is to create functions instead of comments, that is instead of writing "compute the rank" followed by some code, create and call a method computeRank().

BitGeek2• 19 years ago

I expected this list to be written by a crappy programmer who didn't know it... but it turns out it isn't.

I'll add two items to this list:

1. You believe anyone who doesn't write unit tests is a crappy programmer. (I'm done trying to explain this to carppy programmers- not only are they crappy they think that unit tests make them not crappy, and so they can't concieve of the reason unit tests are bad (and often they are...) If you want to write unit tests for yourself, that's fine, but if you've ever told someone else that they should write unit tests, you're a crappy programmer.

2. You believe in Scrum. Like global warming, Scrum is a religion... back in the old days, when programmers had to actually program, we used to use the "daily status meeting" as an example of the height of absurdity that pointy-haired-bosses could achieve. Now crappy programmers think that it makes them less crappy. (No, it doesn't, it actually means your code is crappy... especially if you think scum is an improvement.)

Really.

I know I am speaking crazy talk-- at least most programmers under 30 seem to think its crazy talk-- but it isn't.

The reason we have crappy programmers now? I think its cause they are going to colleges and getting CS degrees. Back in the "old days" when you had to write code to become a programmer, when you had to learn and you cared about getting things done well, we had to self teach and the learning curve was higher.... nowadays really crappy programmers train crappy programmers by the ten-score at universities who's primary goal is separating fools from their money (and I mean any university other than maybe caltech and MIT this applies to.) and they just teach really crappy programming practics. Those that can do, you know.

Speaking of which, you gotta be poor at math to go to univeristy in the first place-- teach yourself and start working right out of high school, after 4 years you're senior software developer, you're much better than the people who have been taught bad practices at university, and instead of being up to your armpits in debt, you'll have a good job and a great income... and four years later- a8 years into your career and 4 years after your friends got out of college, they might have paid off their student loans but you'll still be making twice what they were.

But then, I'm expecting to get pounced on because this is a site full of university grads. :-) Sorry, this has been my experience, and I've interviewed a LOT of programmers in my time.

In fact, I've found that PhDs in CS are useless, Masters in MS are good for grunt work, if you watch them close but generally shouldnt' be hired, and people with jsut a BS degree can usually be retrained if you can get them focused... if they get a job at a big corp right out of school, though, they are lost forever. (Most of them anyway.)

All the really brilliant programmers I've known didn't go to college. (BTW, I did, so I know first hand it was a waste of time.)

Anyway.....here's a bonus "how to know you're a crappy programmer":

You're a crappy programmer if you think while (foo) { stuff }

is wrong because the curly brace goes on the same line as the while. Generally ,the sloppy programmers who think they are really productive but produce nothing but shite are adamant about that... the ones who think about what they are writing and are useful, put the brace on the next line.

Really should use that as an interview question.

emfle• 19 years ago

How many of your bosses did not go to college?

DanielBMarkham6• 19 years ago

I think it's about time somebody stood up for the "curly braces stand alone" school.

I mean, we can debate silly stuff all day, like LISP versus C, Firefox vs. IE, Mac vs. PC, web 1.0 vs web 2.0, etc. But these "braces on the same line" guys are just completely out of their minds. :) <-- Smiley face means humor was used in this comment.

Tichy5• 19 years ago

I've seen whole projects fail over that discussion.

Maybe it really should be used as an interview question. There is no point in mixing same-liners and new-liners together.

Only remedy might be to use a programming language without curly braces.

Tichy5• 19 years ago

Hate to break it to you, but you are just like all the others: every programmer thinks he is the only good programmer and all the others are crap.

edw51914• 19 years ago

My follow-up thread:

http://news.ycombinator.com/item?id=83196

mironathetin• 19 years ago

You know that you are a lousy programmer (and also lousy at doing other things) if you start to make rules although smart people know:

- rules are for people who cannot think

- every rule has a context where it fits perfectly, but

- every rule has many contexts where it doesn't fit at all

Rules only reflect your current knowledge and your current working situation. This is subject to change.

Signs You're a Crappy Programmer (and don't know it)

Related Stories