Professional development journal

2025-09-08

Returned to work after two weeks' leave.

Got through a lot of code review.
Wrote up a detailed proposal for a new tagging pattern.

Make lazy devs defend their work.

Spent a signifcant portion of the day doing code review. Feels like it's taking up too much time: the other devs are putting up undercooked work and I'm doing a lot of work to explain the problems I find and how to fix them.

@goal Aim to write less in code review, without compromising on quality control. Instead of explaining what's wrong with code and how to fix it, ask questions first to discover why the developer wrote it the wrong way.

This should also help address a couple of other problems:

Devs are not being held accountable for sloppy work. By asking questions I can put the onus on devs to defend their work.
Devs are not suffering any pain for sloppy work. Devs want to get PRs merged in quickly, and I let them off the hook when I give them actionable suggestions to fix every mistake they make.

The trick is to be collegial, not socratic. Frame each question as if I trust the dev's judgment but need help understanding the code.

I also have to take care to ask for specific information, not open-ended questions inviting vague answers.

Talk is cheap in Teams

I've been using Teams channels and chats to talk to other devs about problems, but these discussions just end up being forgotten, with no action taken.

Devs have a few Teams habits that I find frustrating:

They call for action on problems without proposing solutions or even doing problem analysis.
They propose undercooked solutions to problems because there's no reputational cost for being lazy or wrong.
They complain about problems without committing to fixing it themselves.

@goal Use email and the kanban board to write up problem analysis and other admin work where it's recorded for posterity, and where devs are less likely to fluff.

It takes patience and persistence to get change

Developers want to push their work through, claim kudos themselves and socialise the liability for their poor work.
Management are impotent and averse to taking responsibility for problems.
Vendors want to do the bare minimum amount of work.

A lot of people problems have to be solved slowly over time. People need time to delay and deflect; they need things explained to them; they handball problems to vendors or supervisors. You can't often win by trying to force things to go faster, because that costs scarce political capital.

2025-09-09

Spent the day telling other devs what to do, instead of doing development myself.

Dev putting up undercooked code.
Dev who is bad at fixing problems and needs to be steered back on track.
Dev who doesn't want to make decisions.

For a while I've been the senior dev doing quality control, getting things done and stopping devs from breaking things or making a mess.

In a way this has been good: I've has to think a lot about improving engineering processes and understanding how they affect a team's productivity.

But in another way, I feel like I'm doing other people's work for them.

The devs should be doing better work, and should be more capable of working independently.
The tech lead is not doing any tech leading. He's just the team's BAU manager.

I've spend a fair bit of time writing up an analysis and requirements for a big piece of feature developement, and I also want to be involved in doing the implementation.

@goal Spend more time writing code. Put a limit on how much time I spend on fixing things for other devs.

Salient problem areas:

Code review. This takes a long time because there's so much crap, It's not enough to tell devs to fix their crap, because they just make more crap.
Broken processes and infrastructure. Devs and testers get stuck because their tools break or because no-one knows how to handle a slightly unusual version control scenario.
Planning. The tech lead does no planning, so the team's ability to ship is regularly blocked by lack of team/vendor capacity.

@goal Delegate problems to other people. Ask the tech lead to do tech leadership and ask devs to try to make a bigger effort to fix problems.

2025-09-10

Found out a dev was using a chatbot to do dev work and got himself blocked for two weeks because the chatbot lied to him.

Broadcasted a request for devs to stop blindly using chatbot bullshit.

Told the team lead I wanted the other devs to step up a bit, so I could step down a bit.

While writing up a functional spec for a new feature, I discovered that there were some weird edge cases that would not be easy to implement. If I had posted the ticket without the spec then the assigned dev would have had problems. So this planning work has potentially saved time, avoided some pretty nasty tech debt and bugs, and saved me the headache of trying to fix those problems after the initial feature rollout.

4.9 KiB Raw Blame History