4 ms·

The one who is 10x at the expense of their colleagues [...] The one who is, at most, 1.5x or 2x but think they are (and sell themselves to the leaders

The one who is 10x at the expense of their colleagues [...] The one who is, at most, 1.5x or 2x but think they are (and sell themselves to the leadership as) 10x [...] Yes. The root issue, of course, is that management essentially never has the time or chops to discern the quality (maintainability, readability, performance, correctness, etc) of the engineering work being delivered. Management only understands timely delivery. Which is crucial, obviously! But considering only quality or timeliness at the expense of the other is of course a dark dark pattern. Even when management are software engineers themselves, they typically just don't have the time to be elbow-deep in the code their reports are delivering. This is particularly true in fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. And even if your manager does get it, their manager probably doesn't, their manager's manager doesn't, the stockholders don't, etc. I don't know the answer to this. It seems to me almost impossible to avoid this in a commercial setting unless you have a tiny team (less than 10 engineers?) and the CEO/CTO is a top-notch engineer. Talk me down off of this ledge. Tell me it's possible.

jcelerier 4y ago
> Management only understands timely delivery. as they should, because it's the only thing that matters to 99% of humans for any non-critical stuff (and honestly, even critical... even stuff that can kill humans, we are very good at saying "one chance of death in XXX is an acceptable risk" ; I'd wager that anything that is below the average death rate of car driving in a particular time / area is in general ok). I'd rather learn a software that has bugs today than a perfect software in a year - by that time I've already organized my workflow around the bugs and already spent 1/30th of the time of my projected remaining future career around this software. I'm not going to re-learn yours even if it works better.
- deleted 4y ago
  [deleted]
- JohnBooty 4y ago
  as they should, because [timely delivery] is the only thing that matters to 99% of humans for any non-critical stuff Right, but here's the thing. Tech debt is inseparable from timely delivery. The tech debt you accrue today in the name of "shipping fast" hurts your ability to execute timely delivery in the future. That's why management should care.
  - jcelerier 4y ago
    or is it ? some code is made to be long-lasting (and that's the one we "see" because of course it lasted long already) but the large majority is short-term projects which are only relevant for a few months / years and will never get reused afterwards.
    - JohnBooty 4y ago
      Hah, yeah, I think we haven't a terminology difference here. I wouldn't even term "bad" code in short-lived projects to be "tech debt" in the first place. I definitely agree you about the near irrelevance of tech debt in short lived projects. the large majority is short-term projects which Is this really true? Really depends on where you work, I guess. It hasn't generally been my experience. But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.
no_wizard 4y ago
> fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. Hate to break it to everyone but its really not like this, unless you're stuck in a loop of a bunch of resume driven engineers there's alot of stability in frontend development, especially since the advent of meta frameworks (Next.js, Nuxt, Modern Angular etc) and stability in tooling (rollup v2+, webpack 5+, and especially esbuild / vite) If you want to be even more stable here, you can forgo a lot of headache with web components, which will always have some backward compatibility built in thanks to it being build on standards. It isn't 2016 anymore. New frameworks aren't just popping up left right and center and expecting adoption. There's a lot of stability out there and there will be for the foreseeable future. Much like any engineering endeavor there are, yes, people pushing the frontier, but all communities have this.
- JohnBooty 4y ago
  unless you're stuck in a loop of a bunch of resume driven engineers This has been my experience and the experience of many peers that I've heard from. Admittedly, there's an inherent selection bias there... people dealing with frustrating situations are certainly more apt to speak up about them.

jcelerier 4y ago

> Management only understands timely delivery. as they should, because it's the only thing that matters to 99% of humans for any non-critical stuff (and honestly, even critical... even stuff that can kill humans, we are very good at saying "one chance of death in XXX is an acceptable risk" ; I'd wager that anything that is below the average death rate of car driving in a particular time / area is in general ok). I'd rather learn a software that has bugs today than a perfect software in a year - by that time I've already organized my workflow around the bugs and already spent 1/30th of the time of my projected remaining future career around this software. I'm not going to re-learn yours even if it works better.

deleted 4y ago
[deleted]
JohnBooty 4y ago
as they should, because [timely delivery] is the only thing that matters to 99% of humans for any non-critical stuff Right, but here's the thing. Tech debt is inseparable from timely delivery. The tech debt you accrue today in the name of "shipping fast" hurts your ability to execute timely delivery in the future. That's why management should care.
- jcelerier 4y ago
  or is it ? some code is made to be long-lasting (and that's the one we "see" because of course it lasted long already) but the large majority is short-term projects which are only relevant for a few months / years and will never get reused afterwards.
  - JohnBooty 4y ago
    Hah, yeah, I think we haven't a terminology difference here. I wouldn't even term "bad" code in short-lived projects to be "tech debt" in the first place. I definitely agree you about the near irrelevance of tech debt in short lived projects. the large majority is short-term projects which Is this really true? Really depends on where you work, I guess. It hasn't generally been my experience. But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.

no_wizard 4y ago

> fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. Hate to break it to everyone but its really not like this, unless you're stuck in a loop of a bunch of resume driven engineers there's alot of stability in frontend development, especially since the advent of meta frameworks (Next.js, Nuxt, Modern Angular etc) and stability in tooling (rollup v2+, webpack 5+, and especially esbuild / vite) If you want to be even more stable here, you can forgo a lot of headache with web components, which will always have some backward compatibility built in thanks to it being build on standards. It isn't 2016 anymore. New frameworks aren't just popping up left right and center and expecting adoption. There's a lot of stability out there and there will be for the foreseeable future. Much like any engineering endeavor there are, yes, people pushing the frontier, but all communities have this.

JohnBooty 4y ago
unless you're stuck in a loop of a bunch of resume driven engineers This has been my experience and the experience of many peers that I've heard from. Admittedly, there's an inherent selection bias there... people dealing with frustrating situations are certainly more apt to speak up about them.