4 ms·

Reads like one of those "what happened to GOOD code" articles, except this time the author plays the victim and pretends like there's a conspiracy among employe

Reads like one of those "what happened to GOOD code" articles, except this time the author plays the victim and pretends like there's a conspiracy among employers against good code. What strikes me with all these articles is that good code is never objectively defined. It's always some arbitrary measure, sprinkled with common wisdom (write tests! Keep functions small!). The author assumes that they write GOOD code and those evil managers and business people actively conspire against them for writing GOOD code. I suspect most people who write these articles aren't as good as they think. Most genuinely good engineers know the value of code, and how to balance their objectives with time. Being difficult to work with by insisting on arbitrary measures (e.g. all functions need to be pure and follow my naming convention!) does not make one a good engineer. There's a reason good communicators advance in their careers while grumpy tech-leads who constantly bring problems stay at their level.

tkiolp4 3y ago
There is only code that works and code that doesn’t. The best code is no code at all. Everything else is subjective.
- louthy 3y ago
  Then there’s the code you have to maintain …
tomcam 3y ago
> Most genuinely good engineers know the value of code, and how to balance their objectives with time. In my experience most genuinely good engineers almost never complain, either.
- mirekrusin 3y ago
  That's because they gave up on fixing others, not because they agree with them - they just ignore and carry on.
  - thelittleone 3y ago
    Metaphor for life in general.
mirekrusin 3y ago
...you mean grumpy like ie. Linus Torvalds?
- billllll 3y ago
  I think there's a massive difference between when you're Linus Torvalds and you' gatekeeping Linux from the interests of billion dollar companies, versus you're a tech lead at said billion dollar companies. I think being a grump has it's place and time, but cargo-culting Linus without bringing his skill and expertise is detrimental. The actions of Linus will have ripple effects on millions, and he doesn't have too many levers to pull. Being grumpy is just one of his levers to pull against engineers backed by billions. Compare this to a grumpy tech lead, who's actively throwing a wrench in things by insisting on a nebulous "quality" just to justify their own existence. One is just a pale imitation of the other. Obviously, Linus has promised to reign in his grumpiness, and I'm not smart enough to even sniff his wrath, so I probably don't have perspective.
klyrs 3y ago
> pretends like there's a conspiracy among employers against good code. It's funny, on this site I've been chided several times when I talk about iterating on quality. People are under incredible pressure to make deadlines, and they externalize that with a "if it works once, ship it and never look back until it breaks" attitude. Is it an employer conspiracy against quality? No, that would be ridiculous. Is a derisive attitude towards quality an immediate and obvious consequence of focusing on tangible and immediate delivery above all else? Yes, of course it is.
- billllll 3y ago
  > when I talk about iterating on quality What does iterating on quality even mean? I challenge you to define this term in a way that is clear and objective. I guess the whole point that I'm trying to make is that "quality" is never well-defined, and thus is basically an arbitrary goalpost used by mediocre engineers to throw a wrench in things and justify their existence.
  - klyrs 3y ago
    > I challenge you to define this term in a way that is clear and objective. Thanks, but no thanks. It's highly context dependent. Performance can be a goal. Simplicity (rather, lack of useless complexity) can be a goal. Maintainability can be a goal. Generality can be a goal. Understandability can be a goal. There's a sweet spot where brevity can be a benefit to those goals, beyond which it turns to tortuous code-golf. Taken to an extreme, any of the goals above can become pathological. With experience, you should know the difference between shoddy, slapdash or tortuous code and well-written code.
    - billllll 3y ago
      > Thanks, but no thanks > With experience, you should know the difference between shoddy, slapdash or tortuous code and well-written code You've just successfully proven my point. By refusing to clearly define what "quality" means, you can now arbitrarily draw the line for quality anywhere you want any time you want. Any time you feel like you're not feeling important enough, you can throw a wrench into the process, yell about "quality," then complain on your blog when your manager/higher-up inevitably overrides you. If you ultimately want to provide value with your work, this isn't how you do it.

tkiolp4 3y ago

There is only code that works and code that doesn’t. The best code is no code at all. Everything else is subjective.

louthy 3y ago
Then there’s the code you have to maintain …

tomcam 3y ago

> Most genuinely good engineers know the value of code, and how to balance their objectives with time. In my experience most genuinely good engineers almost never complain, either.

mirekrusin 3y ago
That's because they gave up on fixing others, not because they agree with them - they just ignore and carry on.
- thelittleone 3y ago
  Metaphor for life in general.

mirekrusin 3y ago

...you mean grumpy like ie. Linus Torvalds?

billllll 3y ago
I think there's a massive difference between when you're Linus Torvalds and you' gatekeeping Linux from the interests of billion dollar companies, versus you're a tech lead at said billion dollar companies. I think being a grump has it's place and time, but cargo-culting Linus without bringing his skill and expertise is detrimental. The actions of Linus will have ripple effects on millions, and he doesn't have too many levers to pull. Being grumpy is just one of his levers to pull against engineers backed by billions. Compare this to a grumpy tech lead, who's actively throwing a wrench in things by insisting on a nebulous "quality" just to justify their own existence. One is just a pale imitation of the other. Obviously, Linus has promised to reign in his grumpiness, and I'm not smart enough to even sniff his wrath, so I probably don't have perspective.

klyrs 3y ago

> pretends like there's a conspiracy among employers against good code. It's funny, on this site I've been chided several times when I talk about iterating on quality. People are under incredible pressure to make deadlines, and they externalize that with a "if it works once, ship it and never look back until it breaks" attitude. Is it an employer conspiracy against quality? No, that would be ridiculous. Is a derisive attitude towards quality an immediate and obvious consequence of focusing on tangible and immediate delivery above all else? Yes, of course it is.

billllll 3y ago
> when I talk about iterating on quality What does iterating on quality even mean? I challenge you to define this term in a way that is clear and objective. I guess the whole point that I'm trying to make is that "quality" is never well-defined, and thus is basically an arbitrary goalpost used by mediocre engineers to throw a wrench in things and justify their existence.
- klyrs 3y ago
  > I challenge you to define this term in a way that is clear and objective. Thanks, but no thanks. It's highly context dependent. Performance can be a goal. Simplicity (rather, lack of useless complexity) can be a goal. Maintainability can be a goal. Generality can be a goal. Understandability can be a goal. There's a sweet spot where brevity can be a benefit to those goals, beyond which it turns to tortuous code-golf. Taken to an extreme, any of the goals above can become pathological. With experience, you should know the difference between shoddy, slapdash or tortuous code and well-written code.
  - billllll 3y ago
    > Thanks, but no thanks > With experience, you should know the difference between shoddy, slapdash or tortuous code and well-written code You've just successfully proven my point. By refusing to clearly define what "quality" means, you can now arbitrarily draw the line for quality anywhere you want any time you want. Any time you feel like you're not feeling important enough, you can throw a wrench into the process, yell about "quality," then complain on your blog when your manager/higher-up inevitably overrides you. If you ultimately want to provide value with your work, this isn't how you do it.