Live data from Hacker News

Signs that you're a bad programmer

sites.google.com

71–80 of 131 posts

Re: Signs that you're a bad programmer

#71
I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true.

On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem.

Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it.

If someone feels compelled to write up an essay about bad programmers, he probably spends a lot of time dealing with bad programmers.

That experience should lead to humility, not arrogance. If you deal with a lot of bad programmers, you might not be as good as you think you are. After all, you work at the same place on the same project as a bunch of bad programmers. They where hired under the same standards as you.

To me, the document just seemed like arrogant posturing. An attempt at crafting a "negative identity" (define a group by vilifying the outsider). The best way to "be", and to be recognized as, a good programmer is to write good code. All the other stuff is just horse shit.

Re: Signs that you're a bad programmer

#72

Oh man, I wish I had this at my last job half the team had over 50% of these symptoms, one guy had 90%. They believed, and had somehow convinced management, that they were great programmers! Some awesome practical examples from those guys below: Overheard statement "You know when I was in college I learned C. I just can't get the hang of these objects, so I try to avoid them". The guy who said this is now 34, and has…

ouch... I love the 'stop making this so complicated bit'. While some people really don't get it I'm pretty sure that most people could learn how to program with some competence. The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight…

>>I'm pretty sure that most people could learn how to program with some competence.

That is what logic tells you, but I've seen smarter people than me, which couldn't get it even after years of trying. (I helped a few with labs while studying.)

You shouldn't have too much grit.

You characterization about handling program size fits well with my own development. Interesting point.

Re: Signs that you're a bad programmer

#73
post #70
post #15

Earlier quoted context omitted.

I don't think Lisp being opaque has anything to do with your ability to learn a particular PL such as Common Lisp, Scheme, Arc or Clojure. Rather, opacity is usually a term levied at a syntax , when it makes it hard to understand what the underlying semantics of the program are. Lisp has the least "syntax" of any programming language I know of, so if it's opaque to you (e.g., you can't take a guess at what "(+ 2 3)"…

I don't understand the following point you made: "so if it's opaque to you...,you probably shouldn't be programming" So your saying that someone should not program if they haven't learned basic lisp ( 5 )? Or are you suggesting that there should be some time limit... like if you program for X months but don't understand it you are forced to quit. But.. further... What is the purpose of forcing these people to quit? A…

I'm not talking about learning programming. The reference in the article was to people that already were programmers.

To put it another way: if you call yourself a programmer, and sell your skills as a programmer, but can't mentally decompose "(+ 2 3)" into an AST (basically the first, and easiest, step to understanding), even after Lisp's general syntax is explained to you, then you aren't actually a programmer.

Re: Signs that you're a bad programmer

#74
post #12
post #4

This is spot on: 5. Lisp is opaque to you

I can't learn LISP. I can get reasonable work done in imperative functional/OO languages like Perl, C, Java, etc. and took the time to learn Erlang to get a look at functional programming and I can drop the SQL bomb like nothing else (so I can do declarative too) but every time I've sat down to learn LISP because people say it will make me a better programmer, I've gotten distracted and haven't finished. I don't thin…

I used to think the same; couldn't really grasp LISP and had even more serious problems with pure functional languages such as Haskell. But the thing is, you can make up all sorts of excuses for not knowing something, but in the end, it's really just not knowing, no matter how good your excuses are.

Then I've spent some time learning LISP, practising it, trying to implement more and more complex algorithms in it and while I'm still not a pro, I'm starting to grasp the basics. And it made me a better programmer, even though at my daytime job I work as a C#/.NET programmer, the little LISP knowledge I have heavily influenced the quality of my code and I think for the better.

Re: Signs that you're a bad programmer

#75
How to avoid (if you're a C programmer) writing utterly terrible code - always include these WARNINGS in your build step:

WARNINGS := -Wall -W -Wunused-parameter -Wmissing-declarations

WARNINGS += -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare

WARNINGS += -Wconversion -Wshadow -Wcast-align -Wparentheses

WARNINGS += -Wsequence-point -Wdeclaration-after-statement -Wundef

WARNINGS += -Wpointer-arith -Wnested-externs -Wredundant-decls

WARNINGS += -Werror -Wdisabled-optimization -pedantic

CFLAGS += $(WARNINGS)

Note: -pedantic is pretty good if you really wanna learn how to write code that will work properly.

Also: Treating Warnings as Errors is a good thing. You'll learn a lot, and the most important thing will be: handle all warnings. Do not release code until it builds clean.

Re: Signs that you're a bad programmer

#76
post #70
post #15

Earlier quoted context omitted.

I don't think Lisp being opaque has anything to do with your ability to learn a particular PL such as Common Lisp, Scheme, Arc or Clojure. Rather, opacity is usually a term levied at a syntax , when it makes it hard to understand what the underlying semantics of the program are. Lisp has the least "syntax" of any programming language I know of, so if it's opaque to you (e.g., you can't take a guess at what "(+ 2 3)"…

I don't understand the following point you made: "so if it's opaque to you...,you probably shouldn't be programming" So your saying that someone should not program if they haven't learned basic lisp ( 5 )? Or are you suggesting that there should be some time limit... like if you program for X months but don't understand it you are forced to quit. But.. further... What is the purpose of forcing these people to quit? A…

Nevermind this.. Posted under the wrong thread.

Re: Signs that you're a bad programmer

#77
post #73
post #70

Earlier quoted context omitted.

I don't understand the following point you made: "so if it's opaque to you...,you probably shouldn't be programming" So your saying that someone should not program if they haven't learned basic lisp ( 5 )? Or are you suggesting that there should be some time limit... like if you program for X months but don't understand it you are forced to quit. But.. further... What is the purpose of forcing these people to quit? A…

I'm not talking about learning programming. The reference in the article was to people that already were programmers. To put it another way: if you call yourself a programmer, and sell your skills as a programmer, but can't mentally decompose "(+ 2 3)" into an AST (basically the first, and easiest, step to understanding), even after Lisp's general syntax is explained to you , then you aren't actually a programmer.

Above, you said whether they could guess it, not whether they could understand it after explained.

"you can't take a guess at what "(+ 2 3)" means"

I can see your meaning if it was explained to someone and they still didn't grok it. But I would still kinda feel like encouraging them.

Re: Signs that you're a bad programmer

#79
post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

I'm not fond of scrolling (or ctrl+clicking) up and down to see what every little subroutine does to understand the code I have to fix. Only if it's my own code, I can be somewhat sure the tiny function does indeed SetOrderDate, but maybe it also modifies order's XML or changes some global variables... I can never be sure and I have to look, so reading bulldozed code is almost like reading huge routine but with way more scrolling.

Re: Signs that you're a bad programmer

#80
post #75

How to avoid (if you're a C programmer) writing utterly terrible code - always include these WARNINGS in your build step: WARNINGS := -Wall -W -Wunused-parameter -Wmissing-declarations WARNINGS += -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare WARNINGS += -Wconversion -Wshadow -Wcast-align -Wparentheses WARNINGS += -Wsequence-point -Wdeclaration-after-statement -Wundef WARNINGS += -Wpointer-arith -Wnested-ex…

Good advice, but compilers often issue warnings like "x may be used uninitialized" even when it cannot happen.
Post reply on HN