Started professional development journal

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

@@ -0,0 +1,119 @@
+# 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.