Signs that you are a bad programmer • Hacker News Board

Re: Signs that you are a bad programmer

#161

Post by JoeAltmaier » Thu, Oct 20, 2011, 2:24 PM UTC

substack wrote: post #63

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

I'm actually astonished by the hero-worship surrounding the inventor of C. Its got so many embarassing flaws, or had at any rate; its been patched and bandaged for decades.

Sure, say that hindsite is 20-20, but I knew C was busted long before I learned anything about objects or monads etc. Syntax is goofy, backward as you say (I thought that the 1st time I ever saw a C program decades ago); its promise as an expression-based syntax was botched and mortgaged, resulting in generations of hacks; its fundamental expression evaluation syntax was broken to begin with, and as patched its cumbersome and baffling at times.

Re: Signs that you are a bad programmer

#162

Post by jpendry » Thu, Oct 20, 2011, 2:29 PM UTC

Zaak wrote: post #121

Androsynth wrote: post #108

Earlier quoted context omitted.

At the hardware level it's called the program counter, which is a register containing the address of the current operation the processor is running. After the operation is finished, it increments itself and moves to the next step in the program. Edit: just realized I didn't really answer the question, I believe what your actually talking about is a statement. I usually jump at the chance to talk about stuff from my o…

The program counter isn't the only element of that "what the program is doing now" state though. The context in which the current instruction is being executed makes a world of difference.

And the ability to save all of that into a variable so that you can pass it around to other parts of your program means that your programming language supports Continuations.

Re: Signs that you are a bad programmer

#163

Post by VBprogrammer » Thu, Oct 20, 2011, 2:37 PM UTC

jroseattle wrote: post #99

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.

Actually, that was a username I've used for 13 years. Currently I'm mainly developing in TCL professionally and Python personally.

Re: Signs that you are a bad programmer

#164

Post by jroseattle » Thu, Oct 20, 2011, 2:53 PM UTC

VBprogrammer wrote: post #163

jroseattle wrote: post #99

Earlier quoted context omitted.

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

Actually, that was a username I've used for 13 years. Currently I'm mainly developing in TCL professionally and Python personally.

It's in jest. There's something funny about the username "VBProgrammer" in a discussion about identifying bad developers, from the stereotypical POV.

Disclaimer: I started as a VB guy myself. Now I fall in the C# and Python camps.

Re: Signs that you are a bad programmer

#165

Post by [deleted] » Thu, Oct 20, 2011, 4:13 PM UTC

pookiesbutt wrote: post #17

"You seriously consider malice to be a reason why the compiler rejects your program" Of course it's malice.

[deleted]

Re: Signs that you are a bad programmer

#166

Post by BrandonM » Thu, Oct 20, 2011, 4:16 PM UTC

loup-vaillant wrote: post #153

BrandonM wrote: post #71

Earlier quoted context omitted.

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

Thanks for the informative reply and the excellent blog post!

Re: Signs that you are a bad programmer

#167

Post by Don_Wallace » Thu, Oct 20, 2011, 4:58 PM UTC

This article is mean spirited, too serious and not well written.

Bad programmers I have known generally:

- Are oblivious and clueless. They just lack cleverness.

- They lack problem solving abilities and willingness to solve problems.

- They are usually slow witted.

- They are very conventional-minded - external approval means a lot to them.

- They are willing and ready to work too hard at programming for a result.

- They lack abstract reasoning skills.

And most bad programmers don't like Star Trek or science fiction, but I can't figure out why other than simple correlation with the mindset of a programmer.

The first set of six "real" causes pretty much encapsulate 99% of the mediocrity I've witnessed in industry in this field. Bad programmers usually have two or more of these problems. Even one of them is a serious problem if you are looking for a great developer.

All other badness, such as "meal ticket" thinking, usually radiates outward from these things.

I say this because if you lack the quickness and the desire to seek simple and elegant solutions, the work becomes like drudgery and your work reflects the other deficiencies that the article described.

A specific example: if you care too much what non programmers think (including your managers) and if you are a bit of a toady, you will not take the time to learn what is going on in-depth, and you will look for quick solutions. So it's important to strategically ignore your bosses from time to time and if you are trying to be politically popular, software development isn't a good place for this.

Another example: if you "want" to work very, very hard, you will not seek ways to simplify the code. You will instead cope with growing complexity and spaghetti.

I question the article writer's programmer instincts because he did not figure out a much more efficient and concise way of expressing the same things. Above all else, a real programmer figures out how to say it just once - not repeatedly cast in different ways.

Re: Signs that you are a bad programmer

#168

Post by AppSec » Thu, Oct 20, 2011, 5:55 PM UTC

wnight wrote: post #140

nhangen wrote: post #124

Earlier 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.

Depends on what process you are talking about. If you are trying to improve a process which will hurt the time to deliver of a major project costing a company money, then is it really right to call the company a failure?

Every company/division/organization has priorities and while there maybe inefficiencies in their processes, they maybe a minor cost in relation to the other priorities. (I can't believe I actually just played devils advocate/defended this).

Re: Signs that you are a bad programmer

#169

Post by chris_dcosta » Thu, Oct 20, 2011, 8:39 PM UTC

sophacles wrote: post #101

sliverstorm wrote: post #86

How do I know that list is a little off? Using it as a metric, I am mediocre-to-good, when I know for a fact I haven't yet reached mediocre. For example, I grokk pointers, but I use them so infrequently I make foolish errors and have to stop and block everything out.

In my experience you have nothing to fear: such thinking and self understanding makes you a better programmer than many I have worked with. The worst usually think they are way better than they are, and the better ones usually know where they can improve. I have worked with people who do some or most of these, and let me tell you, the experience is not pleasant -- frequently turning into "Oh you changed that code, I…

" I'd rather work with a neophyte who wants to improve over a veteran who is static any day."

So true.

Re: Signs that you are a bad programmer

#170

Post by ebrenes » Thu, Oct 20, 2011, 9:08 PM UTC

jobu wrote: post #155

jwingy wrote: post #4

A 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.

I would say that's OCD causing them to program badly. That there's some underlying condition behind the erroneous pattern does not excuse it's presence in the code base.