> "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).
Signs that you are a bad programmer
141–150 of 177 posts
Re: Signs that you are a bad programmer
#142The 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.)
Re: Signs that you are a bad programmer
#143The problems described by the article are certainly real problems I've seen and seem like an indications of someone who indeed hasn't taken the time to deeply understand the programming process. But the term "bad programmer" and the general attitude of the article seems deeply mean-spirited, I would rather work with an actual "bad programmer" than with the kind of person who'd spend their time thinking up "alternativ…
Thinking that you are better than another person just because they haven't focused on your own domain of knowledge is arrogant and delusional, and in my experience many of the truly great are humble in the extreme (think Dunning–Kruger effect).
That said, a bad programmer can be a big problem if you are victim to their work. The same could be said for a bad taxi-driver or chef.
I think the article is more in the spirit of making fun of bad practices than character assassination, and that's something I can support :)
Re: Signs that you are a bad programmer
#144https://encrypted.google.com/search?q=%22deficiency+a+progra...
Re: Signs that you are a bad programmer
#145What 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…
Re: Signs that you are a bad programmer
#146If you are reading this article, you are not a bad programmer; you are a programmer learning to master your craft.
Re: Signs that you are a bad programmer
#147Is it odd that any tense of the word "ship" does not appear in this article?
Re: Signs that you are a bad programmer
#148Re: Signs that you are a bad programmer
#149- Your blog post only consisting of lists
- Using only -ing verb forms in your lists
- Not having an introduction in your article
- Not having a conclusion either
- Having only short 2-line paragraphs
- Lack of any style
Re: Signs that you are a bad programmer
#150Earlier 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.