Hacker News Reader

The problem with "we all do this sometimes" is that no team ever gets to 75% of their backlog. And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. I've found it to be much more practical that the team lean into each other's strengths than to fool themselves into thinking you'll ever see "infrastructure automation and fix flaky tests" as the mantra for a few sprints.

I guess a well oiled team could rotate positions around but then you tend to lose a coherent vision of what "right" is in any given domain because you don't have domain experts anymore since everyone has to be an omni-tool.

> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do.

Product people aren't reviewing your code and infrastructure. The manager is responsible for the speed and quality of their team's delivery, so if they have the team devote some time to polishing their tools, they're just using their professional technical expertise to keep things running smoothly for the product folks.

They do need to be good at it - not overseeing a bunch of feel-good but not-actually-that-useful rewriting and cleanup - but that's a question of competence more than responsibility.

It's a very similar thing with rotating people. A manager is going to get into trouble sooner or later if they only ever have the same people work on the same systems. It's the short-term optimization, but not the long-term one. And that doesn't mean nobody can be an expert in an area, but it's bad if only one person is able to work in that area.

A company that wouldn't let a technical manager make the call on that - who works on what, and how much to attention to pay to their tools - may as well have the devs report directly to the product manager. The manager has to stand up for that and not just be steamrolled.

> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do.

As-if the business side of things has any idea of how long something will take. Refactoring or doing some infrastructure work can just be tagged together with some other bits.

For the business side of things it's more important to know when things will be ready and knowing that timeline.

Further, a manager can explain that e.g. "the car needs maintenance". Business isn't against such things, but if the manager cannot switch from IT-speak to business language then it might seems that the business side won't get it.. but maybe it was the explanation that was lacking.

Especially in sprints I noticed that it's understandable to everyone that not everything is finished in one sprint. Though if it happens to often, maybe just promise less.

I know. I believe these things should be possible in theory. I rarely see them in practice. I attribute this to a unilateral lack of discipline.

I think if every team had a person like this, things would end up much cleaner. We all add tech debt and have unfinished business, all the time. We always want the time to come back later to clean things up, but priorities never give us the chance. Having someone to do that would be useful to me. Of course, the ideal for me is that we fix the root of the problem, and avoid agreeing to schedules that don't allow us to build things maintainably.

The other thing I worry about is other team members getting sloppy, because "don't worry, Fred will come clean that up later". For many developers this won't be a problem, but for some it will be, especially when there's time pressure (and there's always time pressure).

I like planning some of these things as parts of projects.

To do X feature, you need to clean up tech debt Y.

Tying it to projects means we can intentionally distribute these to different team members.

... It also means that if cleaning up the tech debt is hard, you're project gets delayed for something where you could have found a way around fixing the tech debt.

My own productivity has been horrible lately, so maybe that should be taken with a grain of salt:P

That approach assumes to know the relation of X and Y in advance, meaning you have a curated, up-to-date list of your tech debt or even better: a map of techdebt-to-feature.

However, working with legacy, you often find techdebt or inadequate architecture/infrastructure mid project...

> Also, how do you even know if you've improved dev productivity 25% if you haven't even improved your own functionality-delivering at any rate

It really depends on what kind of improvements you are talking about but if someone measurably decreases the time it takes me to land a PR by improving CI/CD systems then its really easy to say that such improvements massively effect developers in a positive way. Also opened ticket to landed code can be looked at more broadly and be measured and optimized, as can downtime.

I think there is a fitting English saying that kind of sounds like "eat your own pie" or something like that. I can't find it!

I agree with your general sentiment.

But there are situations and teams where programmers don't tend to have an optimal individual skill-distribution so to speak. Surely there is an opportunity to complement each other to a certain degree.

You mean Dogfooding?

https://en.wikipedia.org/wiki/Eating_your_own_dog_food

Yes exactly thank you!

I guess the analogy here is that Fred who likes to refactor (or write library level code) should also be a user of these APIs.