Signs that you are a bad programmer • Hacker News Board

Re: Signs that you are a bad programmer

#101

Post by sophacles » Thu, Oct 20, 2011, 12:27 AM UTC

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 can't maintain it anymore, object are too tricky" (when refactoring bulldozer functions and dicts of lists of dicts of tuples (some of which contained dicts) into a few classes in python) or "My code was working, why would you change that? I can't be responsible for looking at it anymore!" (When the spec changed and we needed to check for extra error conditions.)

Basically what I'm suggesting here, is bad programmer is less a function of skill at any particular moment, but of attitude and approach. Skills that don't change, continued lack of understanding, and laziness, are all symptoms of a bad programmer, who won't improve. I'd rather work with a neophyte who wants to improve over a veteran who is static any day.

Re: Signs that you are a bad programmer

#102

Post by sophacles » Thu, Oct 20, 2011, 12:32 AM UTC

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…

I'd add:

- bad factoring

- overly complex or overly simplistic object model

- not extensible (although this itself is not strictly bad, as spec changes are pretty hard to predict, but sometimes it is requires more effort to make something not extensible than it is to make it extensible these cases are a problem unless there is a good reason for it).

- abstractions that introduce more effort (factory factories...)

Re: Signs that you are a bad programmer

#103

Post by kd0amg » Thu, Oct 20, 2011, 12:32 AM UTC

zbuc wrote: post #50

saraid216 wrote: post #45

Earlier quoted context omitted.

Believe it or not, sometimes we code for purposes other than selling stuff.

But you still have something to ship, even if it's just to your buddies on github.

What you give to someone else may not be code -- it might just be the code's output.

Re: Signs that you are a bad programmer

#104

Post by kennywinker » Thu, Oct 20, 2011, 12:33 AM UTC

JonnieCache wrote: post #100

Sniffnoy wrote: post #83

Earlier quoted context omitted.

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.

Top of the stack?

Re: Signs that you are a bad programmer

#105

Post by kennywinker » Thu, Oct 20, 2011, 12:35 AM UTC

Okvivi wrote: post #19

A sign that I found missing from the list: you are totally devoted to a particular programming language and believe it's a silver bullet. All good programmers that I know understand that languages are just tools and all have tradeoffs of some sort.

Good point. Being overly attached to a language means you end up choosing the wrong tool for the job at some point.

Re: Signs that you are a bad programmer

#106

Post by Sniffnoy » Thu, Oct 20, 2011, 12:42 AM UTC

JonnieCache wrote: post #100

Sniffnoy wrote: post #83

Earlier quoted context omitted.

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.

Program counter?

Re: Signs that you are a bad programmer

#107

Post by sophacles » Thu, Oct 20, 2011, 12:44 AM UTC

ducktype wrote: post #6

> "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 feel like this might give people the wrong idea. Surely some amount of cohesion is desirable. Also, I'm not quite sure how one "gives the appearance of refactoring" without actually refactoring. Whether it's useful or not may enter into it, but…

I once dealt with code that looked like this pattern (sorry for the giant vertical size of this post):

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    B;
    C;
    D;
    G;
    H;
    I;
    J;
    A;
    B;
    C;
    H;
    I;
    // a bunch more
  }

So I suggested, "hey perhaps you should break this into functions" and got back:

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    state.a = a;
    state.b = b;
    // ... for other state
    return DO_F2(state)
  }
  DO_F2(state);
    B;
    C;
    D;
    G;
    H;
    I;
    state.a = a;
    //...
    return DO_F3(state);
  }
  DO_F3();
    J;
    A;
    B;
    C;
    G;
    H;
    I;
    // a bunch more
  }

When I suggested blocks such as B; C; D; or G; H; I; could be functions, and perhaps a loop could be useful too, the guy looked at me like I was trying to do voodoo and got really defensive about how that couldn't possibly work.

I think that is what the OP meant by bulldozer code...

Re: Signs that you are a bad programmer

#108

Post by Androsynth » Thu, Oct 20, 2011, 12:55 AM UTC

JonnieCache wrote: post #100

Sniffnoy wrote: post #83

Earlier quoted context omitted.

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.

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 old EE days :)

Re: Signs that you are a bad programmer

#109

Post by sounds » Thu, Oct 20, 2011, 1:16 AM UTC

xianshou wrote: post #84

ChuckMcM wrote: post #57

Earlier quoted context omitted.

Except this is sort of a cop out isn't it? In the sense that for any type of artist there are good artists and bad artists but while the good artists may be highly differentiated bad artists share a common set of deficiencies. The article is almost in the 'you might be a if ' style (most common instantiation I am familar with is 'you might be a redneck if ' And in the spirit of that humor I liked it. That being said,…

Anna Karenina would have you believe that there are more ways to fail than to succeed, but I would argue the opposite in most cases involving creative endeavors: Bad programmers are all alike; every good programmer is good in his or her own way.

Props just for the Anna Karenina reference :-)

Re: Signs that you are a bad programmer

#110

Post by sounds » Thu, Oct 20, 2011, 1:18 AM UTC

JonnieCache wrote: post #100

Sniffnoy wrote: post #83

Earlier quoted context omitted.

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.

Current instruction or active instruction (at the processor level)

Currrent statement or active statement at the code level