Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs that you are a bad programmer

yacoset.com

Post reply on HN
Print view View original

91–100 of 177 posts

Re: Signs that you are a bad programmer

#91

Post by philwelch »

timwiseman wrote: post #77
philwelch wrote: post #55

Earlier quoted context omitted.

"Good" already has a meaning, you can't arbitrarily redefine it. You have to actually figure out what the most "good" tradeoff is between shipping and writing maintainable code.

Good has a meaning, but it is a meaning that is highly context sensitive. When talking about "Good cars" for instance, what makes a good car for a mother of 5 is likely different from what makes a good car for a single person who is very worried about the environment and both of those are different from a "Good car" for drag racing.

Yes, and likewise someone can be a very good web programmer while being a crappy embedded programmer. But there's common factors involved: likewise, a car that doesn't run probably isn't a good car regardless of your requirements. (OK, maybe you're a hobbyist that likes working on cars when they break down, or maybe you enjoy having broken down cars on your lawn for decoration. But by the same token, maybe you're a hobbyist who enjoys the IOCCC.)

Defining the word "good" is a philosophical rabbit hole for sure, but if someone comes out and says "a good programmer is someone who writes maintainable code", and someone else comes out and says "a good programmer is someone who writes fast code", and someone else comes along and says "a good programmer is someone who writes code that pleases the customer", you're still having a meaningful discussion about which "good" is better, so to speak.

Re: Signs that you are a bad programmer

#92

Post by sounds »

rickmb wrote: post #3

The opposite approach is much simpler. There's only one sign that you are a great programmer: Clients and fellow programmers are still happy with your work two years after you've delivered it. (Of course: "still" implies that they we're happy at delivery, which includes actually shipping working software in a timely fashion.)

This article stands out from many that point out common errors. This one also provides great* tips on how to improve -- even a "contrapositive" link: http://www.southsearepublic.org/article/2024/read/what_makes...

* Disclaimer: maybe I've seen so many "you're doing it wrong" posts that I see something in the opposite direction and get too excited.

But then, that's what makes something like PG's "Great Hackers" (http://www.paulgraham.com/gh.html) rare. It takes a lot of things: education, some innate ability, good habits, work environment -- including a good team...

Innate ability isn't a huge factor, but writing wonderful code definitely isn't for everyone. So then, what is to be done with all the mediocre code being produced? I don't see the world overrun by it, long term: code is too expensive. But to get there, something definitely needs to be done.

Re: Signs that you are a bad programmer

#93

Post by andrewflnr »

krobertson wrote: post #80
philwelch wrote: post #52

Earlier quoted context omitted.

"and fellow programmers" Did your client ever hire programmers to maintain and improve the first system you wrote? Were those programmers happy with your work? I guess if no one is ever going to maintain your code it doesn't matter as much. I wouldn't ever be so bold as to predict ahead of time whether that's going to be the case.

It also assumes those fellow programmers are also good programmers. Can a mediocre programmer tell the difference between mediocre code and good code? To the original point, the happiness of the client and other developers is a good indicator, but not the only.

  Can a mediocre programmer tell the difference between mediocre code and good code?
Maybe not directly, but they can probably tell how well they understand the code and how hard it is to change. Not as well as a good programmer, since they'll have more trouble with both regardless, but somewhat.

Re: Signs that you are a bad programmer

#94

Post by eru »

jrockway wrote: post #66
eru wrote: post #61

Earlier quoted context omitted.

I'm glad that as a purely functional programmer I don't have to worry about order of program execution so much.

Unless you are using a magical computer, you still have to worry; there are resources you must manage that depend on the underlying OS and von Neumann architecture. An example that bites Haskell programmers are space leaks due to too much partial evaluation and not enough full evaluation. Other problems include keeping a file open for too long and leaking the fd. An ideal computer has infinite space and no files. A r…

Yes. Notice my choice of words. "Not so much" vs "not at all."

Re: Signs that you are a bad programmer

#95

Post by philwelch »

krobertson wrote: post #80
philwelch wrote: post #52

Earlier quoted context omitted.

"and fellow programmers" Did your client ever hire programmers to maintain and improve the first system you wrote? Were those programmers happy with your work? I guess if no one is ever going to maintain your code it doesn't matter as much. I wouldn't ever be so bold as to predict ahead of time whether that's going to be the case.

It also assumes those fellow programmers are also good programmers. Can a mediocre programmer tell the difference between mediocre code and good code? To the original point, the happiness of the client and other developers is a good indicator, but not the only.

That's true. It's not so much about other programmers being a passive critic of your code so much as it is about the maintenance programmer down the line being able to understand what your code is doing and either fix bugs or add features to it.

The maintenance programmer should be competent, but shouldn't have to be brilliant to understand what's doing on (except in the rare case that your code actually is doing something brilliant). If the maintenance programmer doesn't understand a basic language feature, it's his fault if he doesn't understand your use of it (be it ternary operators, blocks, list comprehensions, regular expressions...). If the maintenance programmer does understand ternary operators but you do something like nest them four layers deep, it's probably your fault if he gets lost.

Re: Signs that you are a bad programmer

#96

Post by eru »

larsberg wrote: post #64

Interestingly, his enumerated set in the "Bad Programmer" list is almost exactly what I was grilling for when I asked people to implement stupid algorithms on a whiteboard and then step through them, debug them, etc. I somewhat disagree with: > 6. Cannot fathom the Church-Turing Thesis Truly understanding the Church-Turing thesis probably requires more computability theory than the two-week overview even top CS stude…

> Truly understanding the Church-Turing thesis probably requires more computability theory than the two-week overview even top CS students and otherwise great programmers get in their ABET-required Discrete Math course.

Mathematicians may have more luck in their training. But that depends on your chosen speciality.

Re: Signs that you are a bad programmer

#97

Post by eru »

pseudonym wrote: post #36
kenjackson wrote: post #12

Earlier quoted context omitted.

Not only that, the purpose of refactoring isn't simply for reuse, but also for readability. If you break out chuncks that aren't reusable, but enhance the readability of the code then you've likely improved the code. Given the choice between reusability and readability I'd say that readability should usually win (although it is a false choice).

I would contend that if you're having code readability issues, it'd be better to fix it by sprucing up your whitespace and comments, instead of saying "Well, let's chunk it into more functions" and have method(), which returns method1(), which returns method2(), which returns method3()... Chunking for the sake of itself doesn't seem like a viable strategy to me.

Chunking out in more functions is good in itself, because there's usually a well defined interface for what can get in and out of a function.

Whitespace and comments can suggest that some pieces of code don't interact that much, but chunking into functions lets the compiler prove it.

Re: Signs that you are a bad programmer

#99

Post by jroseattle »

VBprogrammer wrote: post #87

I think one of the biggest errors a bad programmer makes is seeing 'bad' code everywhere. Sure, some code stinks but just because some code doesn't do something the way you would have done it doesn't make it bad. If you do have to complain about some piece of code then do so in concrete terms: - Presense of bugs - Lack of error handling - Preformance issues (real ones, that cause real problems) - Security issues - Po…

Your username doesn't aid in your argument against criticism of bad code. Just sayin.

Re: Signs that you are a bad programmer

#100

Post by JonnieCache »

Sniffnoy wrote: post #83
edw519 wrote: post #41

I found the "Alternative careers" hilarious. My version: Your code sucks. Alternative careers: "Do you want fries with that?" OP's version: 1. Inability to determine the order of program execution Alternative careers: Electrician, Plumber, Architect, Civil engineer 2. Insufficient ability to think abstractly Alternative careers: Contract negotiator, Method actor 3. Collyer Brothers syndrome Alternative careers: Antiq…

I have to wonder if someone who can't determine order of execution should be an electrician or plumber either -- those aren't static systems!

I guess the point is that there's no "privileged" position in these systems which changes with time, like the point of execution in programming.

What is the proper name for the bit of code that's currently being executed? I've suddenly realised that its a concept you think about constantly when coding, but its so much a part of the scenery so to speak that you never consciously consider it.

Post reply on HN