oh my! I love when you recommend specific career base on specific issues. You made my day! I can't stop laughing. "Bag Lady" seriously looool
Signs that you are a bad programmer
31–40 of 177 posts
Re: Signs that you are a bad programmer
#32The 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.)
"Clients and fellow programmers are still happy with your work two years after you've delivered it."
Disagree. The first system I wrote kept the client happy for years. It was a mess, but it was literally millions of dollars better than not having any system.
If what you mean is something like "focus on doing work of long-term value, and consider programming skill as such an input", then I'd agree with that.
Re: Signs that you are a bad programmer
#33The 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 would definitely stipulate that the clients applied to this metric need to be "clueful". You might give them exactly what you asked for, only to have them discover that what they asked for wasn't really what they wanted; "clients from hell" might ask you to re-write it for free, or at least be cross with you for not reading their minds. In any case, they won't be happy. Ignore those.
[deleted]
Re: Signs that you are a bad programmer
#34"You seriously consider malice to be a reason why the compiler rejects your program" Of course it's malice.
the compiler in many simple cases could have tried to repair the program, like attempting to insert(remove) missing(extra) ';' or '}' for example. While it may be not a malice, it is definitely an absence of a good will.
Note: i did work on a real product which had parser inside that had such style of repair implemented, and such approach is also quickly mentioned in the dragon book as well
Re: Signs that you are a bad programmer
#35The 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 wonder if the test is closer to one writers face: you're probably a decent writer if people value your work enough to read it. Likewise, whatever else one can say of programmers, you might be a reasonably decent one if someone else values your work enough to use it. "Reading" and "using" in this case might be similar.
Re: Signs that you are a bad programmer
#36> "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…
Not only that, the purpose of refactoring isn't simply for reuse, but also for readability. If you break out chuncks that aren't reusable, but enhance the readability of the code then you've likely improved the code. Given the choice between reusability and readability I'd say that readability should usually win (although it is a false choice).
I would contend that if you're having code readability issues, it'd be better to fix it by sprucing up your whitespace and comments, instead of saying "Well, let's chunk it into more functions" and have method(), which returns method1(), which returns method2(), which returns method3()...
Chunking for the sake of itself doesn't seem like a viable strategy to me.
Re: Signs that you are a bad programmer
#37Is it odd that any tense of the word "ship" does not appear in this article?
Re: Signs that you are a bad programmer
#38The 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.
Re: Signs that you are a bad programmer
#39I 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!
Re: Signs that you are a bad programmer
#40Sounds quite arrogant to me. And didn't get the biggest problem: Not finishing stuff.
I must admit I'm bad at this. However, in my defense it comes down to: bad management. I'm forever being told to work on the next MOST IMPORTANT THING EVER only to be told after a few days that I need to work ON THE NEXT MOST IMPORTANT THING and that the MOST IMPORTANT THING EVER that I was working on is no longer important at all. le sigh
"Hey, FuzzyDulop, we're a day before deadline but I've been thinking, we could do SUPER BRILLIANT IDEA THAT CHANGES EVERYTHING and it'd be amazing! What do you think?"
...
"You can forget about your deadline if you want that in, boss."
* skip forward a week *
"Hey, FuzzyDunlop, we're a day before deadline but..."