Observation 01
Reading beats typing
The first week should produce almost nothing.
Every expensive mistake I have made was made confidently and early, before I understood the system I was changing. The weeks that look unproductive from outside — reading code, reading data, asking what the business actually does — are the ones that decide whether the rest goes well.
Observation 02
The data model is the product
Everything else is negotiable.
Interfaces get redesigned, frameworks get replaced, teams change. The shape of the data outlives all of it, and a model that does not match what the business does will quietly tax every feature built on top of it for years.
Observation 03
Boring is a feature
Interesting infrastructure is paid for weekly.
Clever architectures can cost more in on-call hours than they ever save in compute. Unless there is a specific problem that demands it, the answer is the well-understood thing that the next developer will recognise on sight.
Observation 04
Write it down as you go
Documentation written afterwards is fiction.
Not a wiki nobody updates — the reasoning, in the repository, next to the thing it explains. Six months later I am as much a stranger to the code as anyone else, and the note I left is what stops the same question being answered twice.
Observation 05
Aim to be replaceable
Being needed is not the same as being good.
A developer nobody can replace is a risk their client is carrying, whether or not anyone has said so. I document, hand over, and would rather be kept because the work is useful than because leaving would be expensive.