From b712335fa461156eea176c2ae1d2a13c97b6ace9 Mon Sep 17 00:00:00 2001 From: Brad Treloar Date: Wed, 10 Sep 2025 22:36:33 +0930 Subject: [PATCH] Started professional development journal --- .../professional-development-journal.md | 119 ++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 docs/professional/journals/professional-development-journal.md diff --git a/docs/professional/journals/professional-development-journal.md b/docs/professional/journals/professional-development-journal.md new file mode 100644 index 0000000..db7350c --- /dev/null +++ b/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.