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"?
Signs that you are a bad programmer
81–90 of 177 posts
Re: Signs that you are a bad programmer
#82I paused for a bit when I read, "A programmer can't acquire this kind of knowledge without slowing down." It seems that many businesses that rely on programmers are unwilling to give them the time to be better. I have seen coders with CS degrees from top-tier schools believe that they couldn't code anymore when placed in environments that do not mentor them, that treat them as horses to be run until their backs break…
I'm in this position now. I'm not a great developer, and I love learning new tricks, but because I'm billed hourly, am constantly interrupted, and get brought in to useless meetings, I'm left with zero time to learn.
Re: Signs that you are a bad programmer
#83I 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…
Re: Signs that you are a bad programmer
#84I 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…
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,…
Bad programmers are all alike; every good programmer is good in his or her own way.
Re: Signs that you are a bad programmer
#85Earlier quoted context omitted.
Yeah, we did that a long time ago. I'm just surprised it is still running! I don't think I even told the other reddit guys about infogami or where it runs or anything.
I guess I can't log-in and add a link to its new home, eh?
Re: Signs that you are a bad programmer
#86For example, I grokk pointers, but I use them so infrequently I make foolish errors and have to stop and block everything out.
Re: Signs that you are a bad programmer
#87If 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
- Poor robustness
- Redundancy
Re: Signs that you are a bad programmer
#88Earlier quoted context omitted.
"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
#89How 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.
Re: Signs that you are a bad programmer
#90The 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.)
This is the only metric that matters. Ability to achieve. Everything else is a tool.