7 ms·

Ironically, this looks like a bullshit article to me. I have no idea what is the experience level of the author, but as a senior developer, several times I have

Ironically, this looks like a bullshit article to me. I have no idea what is the experience level of the author, but as a senior developer, several times I have "created a framework" (and a quite useful one at that) which not only made the problem solving manageable for myself, also resulted in clean readable code which is maintainable for others in the team as well. Also, don't underestimate the real need of refactoring at times. There's no red/yellow flag here. Sure, we can keep postponing that and create bigger mess - which is a decision we do have to take at times to avoid last minute bugs, but that still doesn't mean the developer is bullshitting when he says he needs to refactor some old ugly code.

eddigo 9y ago
If you're a competent programmer who uses these terms and phrases, then indignation is not an unreasonable reaction. However, I think it's a completely valid article if you've ever experienced the interactions between an unproductive programmer and their non-technical manager. I've witnessed this dance every week for the past 3 years. The programmer in this case has used every one of those phrases except "platform independent".
- piyush_soni 9y ago
  The thing is, you just can't detect a programmer is bullshitting by just hearing those terms - thus making it a misleading article. There are all sorts of programmers out there - those who use these terms and work a lot (on those things), those who don't use them but still work on them, those who use these terms but don't actually work satisfactorily, and those who neither use these terms nor work. Correlation is not causation here is what I want to say.
  - eddigo 9y ago
    I took the article context as a non-technical manager wondering why a project wasn't complete after using a good deal of resources. Usually "bullshitting" refers to the tactics engineers, or employees in general, use to explain why they aren't done when they should be. If engineers are using these phrases and projects are being completed, then you can assume they're not bullshitting.
- draw_down 9y ago
  Sure, I totally believe it. But it doesn't sound like the problem there is that the manager is asking the wrong questions.
Hydraulix989 9y ago
Yes, tech debt is a real thing, and sometimes it makes sense to pay it down.
eight_ender 9y ago
Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the bar on quality. Sometimes it's about challenging assumptions by the developer that were completely valid when they wrote the original code that aren't now through hindsight, technology changes, etc. It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.
- megablast 9y ago
  And a non-tech person will have great difficulty understanding that, or why? Why didn't you just write it correctly in the first place?
  - Nadya 9y ago
    > Why didn't you just write it correctly in the first place? For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support) That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
  - samdg 9y ago
    Because you needed a "generic" version of it, but your manager read this article and told you not to do it...
- omginternets 9y ago
  >Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".
angersock 9y ago
> I have no idea what is the experience level of the author Acton is the engine lead over at Insomniac Games, and has been shipping that sort of work (routinely refactored/updated) for years. He's an exceptionally pragmatic tech lead.
- xfer 9y ago
  Yet, he seems to be giving black-and-white picture of what constitutes bullshit to non-technical people.
  - meheleventyone 9y ago
    Have you read the article? He's nuanced on refactoring in a manner that the originator of this thread doesn't describe. When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept. However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.
    - Bartweiss 9y ago
      The refactoring section is one of the better parts, though. The article is very black-and-white on "generic version", "framework", "platform independent", and so on. I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't. Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.
markatkinson 9y ago
I am working on a code base where refactoring the code as the product grew was not even considered as most of the technical decisions somehow fell into the hands of non-technical business people (for the last ten years). Just over a year ago the code base was handed over to a technical team (there used to just be one coder (never the same coder as they all seemed to hate the product and move on, now we know why)) to review, and fix to make it more scalable. Well to put it lightly it is a complete cluster fuck that has seen a couple people resign and it is not worth trying to fix. Now the burden has become trying to convince the business people that drastic steps need to be taken (ie full re-write). They don't seem to want to even entertain the idea, so not sure what is actually going to happen.
- OpenDrapery 9y ago
  Drive it until the wheels come off can be a valid decision. Just be aware that when the wheels come off, you will be without a car for some period of time.

eddigo 9y ago

If you're a competent programmer who uses these terms and phrases, then indignation is not an unreasonable reaction. However, I think it's a completely valid article if you've ever experienced the interactions between an unproductive programmer and their non-technical manager. I've witnessed this dance every week for the past 3 years. The programmer in this case has used every one of those phrases except "platform independent".

piyush_soni 9y ago
The thing is, you just can't detect a programmer is bullshitting by just hearing those terms - thus making it a misleading article. There are all sorts of programmers out there - those who use these terms and work a lot (on those things), those who don't use them but still work on them, those who use these terms but don't actually work satisfactorily, and those who neither use these terms nor work. Correlation is not causation here is what I want to say.
- eddigo 9y ago
  I took the article context as a non-technical manager wondering why a project wasn't complete after using a good deal of resources. Usually "bullshitting" refers to the tactics engineers, or employees in general, use to explain why they aren't done when they should be. If engineers are using these phrases and projects are being completed, then you can assume they're not bullshitting.
draw_down 9y ago
Sure, I totally believe it. But it doesn't sound like the problem there is that the manager is asking the wrong questions.

Hydraulix989 9y ago

Yes, tech debt is a real thing, and sometimes it makes sense to pay it down.

eight_ender 9y ago

Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the bar on quality. Sometimes it's about challenging assumptions by the developer that were completely valid when they wrote the original code that aren't now through hindsight, technology changes, etc. It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.

megablast 9y ago
And a non-tech person will have great difficulty understanding that, or why? Why didn't you just write it correctly in the first place?
- Nadya 9y ago
  > Why didn't you just write it correctly in the first place? For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support) That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
- samdg 9y ago
  Because you needed a "generic" version of it, but your manager read this article and told you not to do it...
omginternets 9y ago
>Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".

angersock 9y ago

> I have no idea what is the experience level of the author Acton is the engine lead over at Insomniac Games, and has been shipping that sort of work (routinely refactored/updated) for years. He's an exceptionally pragmatic tech lead.

xfer 9y ago
Yet, he seems to be giving black-and-white picture of what constitutes bullshit to non-technical people.
- meheleventyone 9y ago
  Have you read the article? He's nuanced on refactoring in a manner that the originator of this thread doesn't describe. When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept. However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.
  - Bartweiss 9y ago
    The refactoring section is one of the better parts, though. The article is very black-and-white on "generic version", "framework", "platform independent", and so on. I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't. Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.

markatkinson 9y ago

I am working on a code base where refactoring the code as the product grew was not even considered as most of the technical decisions somehow fell into the hands of non-technical business people (for the last ten years). Just over a year ago the code base was handed over to a technical team (there used to just be one coder (never the same coder as they all seemed to hate the product and move on, now we know why)) to review, and fix to make it more scalable. Well to put it lightly it is a complete cluster fuck that has seen a couple people resign and it is not worth trying to fix. Now the burden has become trying to convince the business people that drastic steps need to be taken (ie full re-write). They don't seem to want to even entertain the idea, so not sure what is actually going to happen.

OpenDrapery 9y ago
Drive it until the wheels come off can be a valid decision. Just be aware that when the wheels come off, you will be without a car for some period of time.