I wonder who wrote this article originally? Google finds about 9 identical copies: https://encrypted.google.com/search?q=%22deficiency+a+progra...
Hacker News user clawrencewenham
Signs that you are a bad programmer
151–160 of 177 posts
Re: Signs that you are a bad programmer
#152What a condescending piece of junk. It serves absolutely no other purpose than to make programmers who do grok everything mentioned feel good about themselves. Worse yet, programmers who could actually benefit from an article like this (i.e. programmers who shouldn't be programmers) won't understand it. E.g. "(Functional) Creating multiple versions of the same algorithm to handle different types or operators, rather…
The actual quote about lisp is: "5. Lisp is opaque to you". I don't think the criterion isn't whether you used Lisp or not. He probably meant: "could you understand Lisp if you tried? If you can't, then that is a red flag".
Re: Signs that you are a bad programmer
#153I 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 loca…
> 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. This problem can be solved by thinking of * as always dereferencing a pointer. So: int *a; /* "*a" is an int, thus a is a pointer to one */ int *b, *c; /* *b and *c are both ints */ This also has the nice side effect of explaining why good C programmers write the * ne…
I second the remarks about poor teaching (though C type syntax does sucks hard). The main problem probably comes from the fact that ordinary variables are themselves an indirection of sorts, and programming courses do not make that clear (we tend to confuse the variable and the value it holds). Excerpt from my article on assignment[1]:
[The pervasive use of the assignment statement] influenced many programming languages and programming courses. This resulted in a confusion akin to the classic confusion of the map and the territory.
Compare these two programs:
(* Ocaml *) │ # most imperative languages
let x = ref 1 │ int x = 1
and y = ref 42 │ int y = 42
in x := !y; │ x := y
print_int !x │ print(x)
Imperative languages don't discourage the use of the assignment statement. For the sake of brevity, they don't explicitly distinguish values and variables. Disambiguation is made from context: at the left hand side of assignment statements, "x" refer to the variable itself. Elsewhere, it refers to its value. The indirection is implicit.
Having this indirection implicit leads to many language abuses. Here, we might say "x is equal to 1, then changed to be equal to y". Taking this sentence literally would be making three mistakes:
(1) x is a variable. It can't be equal to 1, which is a value (an integer, here). A variable is not the value it contains.
(2) x and y are not equal, and will never be. They are distinct variables. They can hold the same value, though.
(3) x itself doesn't change. Ever. The value it holds is just replaced by another.
The gap between language abuse and actual misconception is small. Experts can easily tell a variable from a value, but non-specialists often don't. That's probably why C pointers are so hard. They introduce an extra level of indirection. An int* in C is roughly equivalent to an int ref ref in Ocaml (plus pointer arithmetic). If variables themselves aren't understood, no wonder pointers look like pure magic.
Re: Signs that you are a bad programmer
#154The 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.)
I'm not sure being a great programmer (as in being great at the craft) is the same as ship on time & be sucessful. It's quite possible to write crappy code but still have a usable product that satisfies the customer much more than the previous pile of crap.
I think the very first judgement you should make about a piece of software is whether it works or not. After all the user will never care about anything else.
That being said, if you are in a team and you know you all will have to extend or maintain the code at some point, then discussion of coding style, program features, choice of data structures, etc, is healthy. These things are important for a growing application, getting them right will make the software more robust and make maintenance more efficient.
Re: Signs that you are a bad programmer
#155A lot of these make sense, but I would caution against being discouraged if you show any of these symptoms. Like another front page article that says IQ is not static, I think this also definitely applies to programming ability. I hope this isn't used by some to push the mantra that 'not everybody can code'.
Especially symptom #2 - "Executing idempotent functions multiple times (eg: calling the save() function multiple times "just to be sure")"
That could just be OCD rather than bad programming.
Re: Signs that you are a bad programmer
#156Earlier quoted context omitted.
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.
That's an interesting point. I know that when I'm in the flow coding, there is a sort of Tick: the-program-does-this, Tock: the-program-does-that stepwise execution of the code in my head. There are many answers as to what the hardware is actually doing with the instructions, but more generally what exactly is the name of an imaginary discrete state of a program that currently only exists in a coders head?
>but more generally what exactly is the name of an imaginary discrete state of a program that currently only exists in a coders head?
This is what I'm trying to get at. There isn't one is there? It's weird.
Re: Signs that you are a bad programmer
#157Earlier quoted context omitted.
No doubt. In fact, this is exactly what happened to me today. I'm supposed to have great ideas, but when trying to implement them, told that I need to focus on paying the bills. I don't know how people manage this long-term.
By jumping ship and landing at a less-dysfunctional workplace. If their business plan doesn't include time for improvements of the processes it's a failure. Leave now. Don't try to make up for their mistakes. They won't see it (positively), let alone reward you for it. Do good for your old co-workers by recruiting the good ones into the more-functional company.
This. Don't ask me to make process improvements when you are expecting me to be billable 115% of the time.
Fortunately, my group typically allows for 10%-20% of my time to be used for either training (learning new tech/languages) or process improvements (mostly internal tools). Other groups at the company don't have it so lucky, and those are the groups that desperately need improvements.
Re: Signs that you are a bad programmer
#158I suspect that #1 sign is that you go trolling for self-assurance in articles like this, or worse, by writing smug, random articles like this.
The best possible signs either way will be in your career so far.
Re: Signs that you are a bad programmer
#159Earlier quoted context omitted.
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."
In fairness, "so much" fits the "weasel words" category (https://en.wikipedia.org/wiki/Weasel_word). You and jrockway placed different values on the phrase because it is a "numerically vague expression". I admit to making similar expressions. :)
Re: Signs that you are a bad programmer
#160> "Yo-Yo code" that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)
The other day I was at a hack night and some guys were working on something written in Node. They were having all kinds of problems with an object, so they serialized it to JSON and loaded it back, and somehow it magically started working.