Live data from Hacker News

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

damienkatz.net

41–50 of 66 posts

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

#41
"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?

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

#42
post #15
post #12

Earlier quoted context omitted.

"Minutes "obsessing" today usually saves hours testing tomorrow." True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.

Where'd you ever get the idea that there is any trade-off between "quick" and "right"? Doing things according to effective established principles saves a little time today and a lot of time tomorrow. Quick and dirty usually ends up being neither.

If it were really true that "effective established principles" save time on both the front and the back end, then everyone would be doing them.

The fact is, there's almost always a trade-off between "quick" and "right". That's why so many people choose the former, to the detriment of the latter.

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

#43
post #41

"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…

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().

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

#44
post #37

Earlier quoted context omitted.

It is obsessing if it detracts from the end product. I'm not saying DRY isn't good practice or that chunks of code duplication are just fine and dandy. However, bits of code duplication are hardly a viable litmus test for judging quality of a programmer. When an actor screws up a line in a performance, he can't afford to stop and correct it. In fact, if he stops to correct a meaningless line he'll cause far more dama…

I'm trying to find some point of agreement with you. I think from your comment, we can agree that there are two scenarios to consider: when the programmer is in control of the product and when the schedule is in control of the product. "Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either." Here's the deal: when you stop your design process and kick the compiler up and sta…

n a perfect world avoiding code duplication would be a simple matter. Unfortunately people have to make decisions with what they've got and there isn't always a clear right answer.

A simple dilemma:

You have to perform an operation in C that accepts up to 5 parameters and will be executed when a given 50 input sets are found (out of thousands of possibilities).

You can write one function that accepts variable parameters and paste it into the code for each of those 50 conditions. (Assuming you know how to do that in C to begin with -- I don't, actually)

Or you can write 5 different functions for each possible number of parameters, with some duplication in each function. Or you can write one function with 5 parameters and just pass 'NULL' in the unused slots and test for it inside the function.

Or you can come up a few meaningful sub-categories and write 15 different functions that also handle some processing that would otherwise happen further down the road.

Or you can write 50 different functions that correspond to each input condition, that do mostly the same thing at this point, but in the future if you needed to change any particular input set side-effects will be limited.

How do you answer this question without being able to see the future? (And, is it even worth worrying about, when any of the answers will work?)

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

#45
post #4

"...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 n…

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.

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

#46
post #13
post #9

Earlier quoted context omitted.

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.

"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 ba…

Ah. Didn't read this when I replied earlier: http://news.ycombinator.com/item?id=83107

You make sense. However, I would just try to find more interesting work than cleaning up after others and then trying to get them to change in a certain way :)

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

#47
post #19
post #16

Earlier quoted context omitted.

"violates the afore mentioned copy paste rule" Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.

You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.

One very useful idiom:

while(readLine()) { process lines... }

where readLine() encapsulates the repetition and returns eof as well.

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

#48
post #13

Earlier quoted context omitted.

"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 ba…

Agreed. Cue the blame-the-programmer-for-not-being-smart-enough comments. Guys. The goal isn't to provide the "perfect" code that somehow those poor average schmucks just can't understand. The goal is to provide the dumbest, easiest-to-follow narrative of how the computer is going to solve the problem for the user so that the next guy is able to understand it.

The goal is to conceptualize the problem in such simple terms that even a machine could solve it. Then do so.

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

#49
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.

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

#50
post #4

"...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 n…

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.

Post reply on HN