Ritchie Dagonia — notes from experience
Ritchie Dagonia, 57, full-stack web developer in London.
Six short notes, written from decades of daily practice. Nothing here is a rule; each one is something I learned the slow way, usually by getting it wrong first, and still find myself explaining to younger developers in code reviews. They are short on purpose. The good ideas in this job tend to be simple; the hard part is holding on to them on a busy Tuesday.
Naming things
A good name is a small piece of documentation that never goes out of date, as long as you keep it honest. I spend more time naming than I used to, and I regret none of it. A variable called data tells the next reader nothing; unpaidInvoices tells them almost everything. I try to name from the reader's point of view, not the writer's: what would I want to see if I opened this file for the first time at the end of a long day? When a name is hard to find, it usually means the thing itself is doing too much. Rename first; if that doesn't work, split it.
Keeping pull requests small
The best pull request I can open is one that a colleague can review in ten minutes between two meetings. That means one intention per pull request, a title that says what changes and why, and a description short enough to actually be read. Big pull requests don't get reviewed; they get approved, which is not the same thing. If a feature is large, I cut it into steps that each leave the codebase working: a refactor first, then the new behaviour behind a flag, then the flag removed. It feels slower for a day and turns out faster for the month.
When not to use a framework
A framework is a good bet when you have an application with real state, many screens and a team that will maintain it for years. It's a bad bet for a page that shows some text and a form. I've seen too many small sites carry a build pipeline heavier than their content. Before reaching for a framework I ask three questions: will this still need to be built in two years, how many people will touch it, and how much of it is actually interactive? Plain HTML, a stylesheet and a few lines of JavaScript remain a complete stack for a great deal of the web.
Writing useful commit messages
A commit message is a letter to a future colleague who is debugging at midnight and wants to know why this line exists. The diff already shows what changed; the message should say why. I write a short imperative title, then a blank line, then one or two sentences about the reason, the alternative I rejected, and anything surprising. Fix bug helps nobody. Retry the upload once on timeout, because the storage layer drops idle connections will save someone an hour, and that someone is quite often me, a few months later.
Reviewing code kindly
Code review is where a team's culture is either built or quietly destroyed. I try to review the code, not the person, and to say clearly which comments are blocking and which are just a preference. Questions work better than orders: "What happens if this list is empty?" teaches more than "Handle the empty case". I look for something genuinely good in every pull request and say so, because people repeat what gets noticed. And when I'm tired or irritated, I close the tab and come back later. A harsh review costs far more than a late one.
Saying no to deadlines
Most impossible deadlines are not malicious; they are estimates made by someone who couldn't see the work. So I don't simply say no. I say what can be done by that date, what would have to be dropped, and what the risk is if we pretend otherwise. A calm, written answer with two options is hard to argue with and easy to forward. I've learned that the developers who always say yes are not the ones people trust; they're the ones people stop asking for estimates. Saying no well is a professional skill, and it protects the whole team, not just me.