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

61–70 of 177 posts

Re: Signs that you are a bad programmer

#61

Post by eru »

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'm glad that as a purely functional programmer I don't have to worry about order of program execution so much.

Re: Signs that you are a bad programmer

#62

Post by amalcon »

njharman wrote: post #42

Why is "Performing atomic operations on the elements of a collection within a for or foreach loop" a symptom of mediocre programmer "inability to think in sets"? How should one do that if your "thinking is sets"?

That particular symptom is built under the assumption that your language supports map/filter/reduce or some equivalent functionality. These are generally preferred when available because there are fewer places to make mistakes.

Re: Signs that you are a bad programmer

#63

Post by substack »

I suspect that people who don't "get" pointers (#4 in the article) actually have a much harder time with the pointer declaration and manipulation syntax in C than actually understanding how pointers work and what they let you do.

For instance, in C the * character is used both to declare a pointer and to dereference one and they can be stacked to dereference nested structures. Then & references a variable memory location but is also used in method signatures to change the semantics of calling a function into pass-by-reference. To complicate & further, & is often seen alongside const declarations, which are a whole other thing that people have to keep in their heads.

On top of all of this, * and & have their own operator precedences and associativities that you have to memorize, which is a whole discussion about binary versus unary operators and precedence tables. And I didn't even mention [].

I really don't think that people fail to comprehend pointers because their mental models need updating nearly as often as they just haven't fully internalized all the hoops that C makes you jump through to mess with pointers.

Re: Signs that you are a bad programmer

#64

Post by larsberg »

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 students and otherwise great programmers get in their ABET-required Discrete Math course. It would be great for more people to have an understanding of what a computable function is and isn't, because it would make it easier to explain why we don't have more fancy-pants type systems around,\footnote{Inference is undecidable for most interesting ones.} but it certainly isn't a requirement for great or even good programmers.

Re: Signs that you are a bad programmer

#65

Post by FuzzyDunlop »

philwelch wrote: post #55
mcantor wrote: post #39

I wish articles like this would namespace their assertions by telling us what they mean by "good" or "bad", so we could avoid the perennial echo chamber debate that goes like this: A: GOOD MEANS SHIPPING AND PLEASING YOUR CUSTOMERS B: NO YOU FOOL! GOOD MEANS WRITING CLEAR CODE THAT OTHER HACKERS CAN READ C: NO YOU FOOLS! GOOD IS A HAPPY MEDIUM BETWEEN BOTH OF THOSE THINGS D: DEBATE IS HARD, LET'S GO SHOPPING! God for…

"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" is also arguably subjective and relative to the subject's perceptions of "bad"(and vice-versa).

So of course that "good" tradeoff to one programmer might be a "bad" one to another.

Re: Signs that you are a bad programmer

#66

Post by jrockway »

eru wrote: post #61
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'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 real one... nope :)

The advantage of functional programming languages is that you get to write part of your program as though you have an ideal lambda calculus evaluator. But at some point, you still have to realize that there's a grey box under your desk that doesn't know what a lambda or fixed point is. (But this is better than programming languages that say "hey, you've got a heap, a stack, and some registers! well, so long!")

Re: Signs that you are a bad programmer

#67

Post by jisaacstone »

mcantor wrote: post #39

I wish articles like this would namespace their assertions by telling us what they mean by "good" or "bad", so we could avoid the perennial echo chamber debate that goes like this: A: GOOD MEANS SHIPPING AND PLEASING YOUR CUSTOMERS B: NO YOU FOOL! GOOD MEANS WRITING CLEAR CODE THAT OTHER HACKERS CAN READ C: NO YOU FOOLS! GOOD IS A HAPPY MEDIUM BETWEEN BOTH OF THOSE THINGS D: DEBATE IS HARD, LET'S GO SHOPPING! God for…

Not sure this relates 100%, since the article is mostly talking about your understanding of concepts.

If programmer A understands recursion and programmer B does not programmer A will write better code regardless of deadlines.

Re: Signs that you are a bad programmer

#68

Post by saucetenuto »

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.

I agree that that strategy's pretty feeble, but IMO it's still better than e.g. a thousand-line function. If nothing else it forces you to break out the parameters explicitly, instead of just having a thousand lines of intermingled state transitions.

Re: Signs that you are a bad programmer

#69

Post by krobertson »

Hilarious, but some of the alternative careers I don't agree with. Particularly the first example of order of execution.

If you can't grasp that and decide to be an architect, I wouldn't want to drive on your bridge, work in your building, or live in your home. Same for the options!

Re: Signs that you are a bad programmer

#70

Post by philwelch »

gridspy wrote: post #49
VladRussian wrote: post #34

Earlier quoted context omitted.

the compiler in many simple cases could have tried to repair the program, like attempting to insert(remove) missing(extra) ';' or '}' for example. While it may be not a malice, it is definitely an absence of a good will. Note: i did work on a real product which had parser inside that had such style of repair implemented, and such approach is also quickly mentioned in the dragon book as well

It's possible that such automatic repair would create a bug. Much safer to have a human check and ensure that the ; goes in the right place. A better point is that the error messages from many compilers can be very obscure. This was particularly true 10-15 years ago.

Yeah, if a compiler only compiles the code you actually wrote, it's still your fault. If a compiler tries to infer what you meant and compiles that instead, then it might genuinely be the compiler's fault when something breaks. Plus, the original code should still be fixed instead of relying on the compiler to compile the same broken code the same "right" way each time. We spent the last 20 years trying to convince web developers of that idea.

Clang does something like this. If it notices a simple enough syntax error that it can correct, it still generates the error message but it makes the correction internally and continues the compilation far enough to generate useful error messages about the rest of the code. But it doesn't output anything or change the code.

Post reply on HN