yahnusername
I've worked at a few places with a big big backlog of, I guess, SATD. But saying a particular bit of code is "bad" is not enough to get funding/resources to fix the issue.
Usually other departments have a say in resourcing. Depends on your org who they are, but some collection of product, sales, CS, or marketing. Once the code ships and the feature is working well-enough to accomplish its business objectives, developers have lost all leverage to circle back and fix the tech debt. Those other depts don't care how "healthy" the code is; code is only a binary works/doesn't signal to them.
I encourage teams to not make these lists without first thinking about how the list gets consumed. Writing an apology comment or SATD ticket are definitely going to make you feel less guilty about what you're shipping. But it won't help you fix the debt. You have to address that upstream, by injecting engineering concerns into your company's resourcing decisions. Or slow down initial delivery to get it right the first time when engineers still have leverage.
> This isn't an editorial. I'm not judging anyone. I write computer RPGs for a living. My games are crude and low-budget, but they give you your modest dopamine dose for a far more reasonable price than the free-to-play drug lords over on Android. I even throw in a decent story to put a patina of sophistication on the whole thing.
I've also worked with managers who have no problem being the hatchet man and it's great. They sniff out the losers, put them on a plan, and they're either out the door soon after or stick around to get fired.
I would rather managers teach each other to wield the hatchet than try to get seven steps ahead of a dud hire during the interview process. "Release early, release often."
Maybe it doesn't change often, but the developer pool is full of people early in their career who would rather find the next big thing and get in on the ground level than be 3-5 years behind the curve on the existing stuff. And then they tweet all day about it.
Maybe it does change often, because there's such a focus on build tools and developer ergonomics; and doing that in 201X lets you follow the treasure map made by the ppl who already figured it all out for systems programming decades ago. The kids are calling it transpilation and tree-shaking these days. They're writing APIs for GPU access, and assembly code for the bits that need to be really performant.
I had a middle-of-the-road idea in this area too, which is to replace the number with the magnitude. So you still get the feedback from the vanity metric, but it happens with logarithmic decay.
A more detailed write-up (and repo for the plugin) for those interested: https://github.com/a13o/disengaged/wiki#replace-vanity-count...
The place where the people AREN'T and the kylie jenners AREN'T is a perk of mastodon to some, not a flaw. It's like the tech nerd version of kids not using facebook because it's their parents' social network.
I just want to share cool pictures of my modular origami and not constantly be two degrees of separation from Trump's latest outrage
In-person: all context clues available
Video: screen acts as barrier; latency inhibits rapport
Voice: all visual information missing
Text: all visual and tonal information missing
The article's advice rings more and more true the further down this list you go