A tool like the paper encourages won't hurt, but in my experience the biggest problem with tech debt isn't on the identification side; it's on the resourcing side.
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.
I dunno, calling people unsophisticated drug dealers because their game designs don't value the same dimensions of fun as your game designs seems pretty judgemental.
> 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 worked at places where the managers hem and haw over firing someone even going so far as to use passive-aggression to make them leave on their own. In environments like that, the cost of hiring the wrong person is huge. It could take a couple of quarters to shake the dead weight and the entire team suffers.
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."
I totally agree. I think so much of the "it's really hard to get rid of bad people" story comes from weak management. Firing people is part of the job, you need to be comfortable doing it.
Interviewing people is extremely disruptive to an engineer's time and in a large company it could potentially happen a lot. I think that is the metric that should be optimized for, not minimizing firing work for the hiring manager.
I wonder about this - am I doing a candidate a disservice by hiring them without knowing that there is a non-trivial chance that they'll be fired within 1-2 months? If someone doesn't already have a job, that's fine, but someone might quit a situation where they are suited for one in which they aren't. Or, if someone is a junior developer, they've just spent 2 months before being let go, and has to explain the situation to the next place.
I care about the people I hire as humans and don't want to put them in a bad situation.
I wouldn't say there's a non-trivial chance that they'll be fired in 1-2 months. Being able to effectively screen people is another technical managerial skill. There is a very, very small percentage of candidates that make it through the interview and later turn out to be duds.
I think there are two issues at play:
1. Ineffective managers are terrified of firing people.
2. Ineffective managers rightly or wrongly think they can't screen people without code tests, white boarding...
Like I said in my original comment I look at their Github or any other work portfolio they provide and have a deep discussion about it with them.
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 wrote a firefox plugin that removes likes/follows/upvotes/hearts style vanity counters from a bunch of websites. It absolutely makes them better to use. This is a good change.
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.
I miss the old internet when we trusted each other enough to trade star wars cards by posting on forums and exchanging mailing addresses. If I tried to do that on today's internet I'd have a SWAT team show up to murder me. And not even because my star wars trades are bad, but because of my support of women's rights. When you have One Thing For Everything, all the wires get crossed. It sucks.
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
What do you think the original function of shaking hands was as compared to what it is today?
There was this funny study that found that people were more likely to hold their hand next to their nose right after shaking hands. From this they concluded that hand-shaking is a non-intrusive way of smelling a person you just met.
I like to think about communication in four tiers from best to worst
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
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.