notes/docs/professional/journals/professional-development-journal.md

# 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.

@goal Develop a system for writing functional specs that can be used by devs
and testers.

# 2025-09-11

Conversation with dev revealed that he had missed or forgotten a lot of the
team's plan (and reasons behind the plans).

Made me realise that the things that we discuss in meetings and chats are
ephemeral.

@goal Write down all decisions that affect the team, including context and
rationale where necessary.