Ritchie Dagonia

A working day, front to back

Full-stack is a big word for a simple reality: I move between the browser and the server several times a day. In the morning I'm often inside a component, fixing a layout that breaks at 400 pixels or wiring up a form so that it behaves properly with a keyboard. By lunch I may be in a Node.js API, adding an endpoint, writing the query that feeds it, and checking that the database index actually gets used. In the afternoon there is the pull request queue, a test that has turned flaky, and a younger colleague who wants a second pair of eyes on a tricky piece of TypeScript.

I've been doing this long enough to know that the interesting part is rarely the code itself. It's the conversation before the code: what problem are we actually solving, who uses this screen, what happens when the request fails. The stack I use most is HTML, CSS, JavaScript and TypeScript on the front, a modern component framework, Node.js on the back, and a relational SQL database that I treat with a great deal of respect. Tests, deployment and code review are not extras; they are the job.

Boring tools, steady habits

My tools are deliberately boring. An editor I know by heart, a terminal, Git, and the browser's developer tools, which remain the most underrated debugging tool in web development. I keep a text file open all day with the three things I'm supposed to finish; if it has more than three lines, something went wrong in the planning.

I commit small and often. I write the commit message before the code when I can, because it forces me to say what I'm about to do in one sentence. I review other people's pull requests before opening my own, because a queue that nobody empties is a team that slowly stops talking. And I try to ship something to production every day, even something tiny, so that deployment stays a habit rather than an event.

Mentoring is a real part of my week now. After decades of doing this, the most useful thing I can give a younger developer is not a clever pattern but a calm way of reading an error message, and the permission to say I don't understand this yet. I learned most of what I know from people who took the time to explain; passing that on is the least I can do.

What I still love about the craft at 57

At 57 I'm long past the phase where every new library feels urgent. I've watched enough frameworks arrive, dominate and quietly fade to take the current excitement with a smile and a notebook. What I love now is quieter. A component that renders exactly the same in three browsers. A query that goes from two seconds to twenty milliseconds after one well-placed index. A page that a screen reader can actually walk through. The moment when a younger colleague fixes something I couldn't see.

I also love that the web is still open. You can view the source. You can build something in an evening with a text editor and put it online. Fifty-seven is a good age for this job: enough years to have opinions, still enough curiosity to change them, and the calm to know that most trends are worth watching for a year before adopting.

What I'm learning now

This year I'm going deeper into web accessibility, not as a checklist but as a way of designing. Testing with a keyboard only and with a screen reader has changed how I write markup. I'm also spending time on the performance side: understanding what the browser actually does between the first byte and the first paint, and measuring before optimising.

On the back end, I'm reading a lot about SQL again. Window functions, proper transaction boundaries, how to write a migration that can be rolled back at three in the morning. And I'm slowly learning to write less code: fewer abstractions, more plain functions, more comments that explain why rather than what. It took me a long time to accept that deleting code is one of the most valuable things a developer does.

A French developer in London

I moved to London because I wanted to work in English on products used by people far from my own culture, and because the city has a density of web work that is hard to find elsewhere. The first months were humbling. I could write TypeScript fine; explaining a technical trade-off in a meeting, in a second language, with three people talking at once, was another matter entirely.

Working in English has become natural, but it has changed how I write code too. I name things more carefully, I document more, I ask more questions in writing. British work culture is politer and more indirect than what I knew in France: "I'm not sure that's quite right" often means "no". Learning to hear that took time, and I'm still occasionally caught out.

What I miss is easy to list: proper bread, long lunches, the light in late summer. What I would never give up: the Tube ride with a book, the parks on a Sunday morning, the pub after a difficult deployment, and the feeling of being a little bit foreign every day, which keeps me paying attention.

If you want to move to the UK as a developer

• Language. You don't need perfect English; you need to be comfortable being imperfect out loud. Practise explaining your code to someone, in English, before you arrive. Reading documentation is not the same as defending a design in a room.
• Work culture. Expect feedback to be soft on the surface and precise underneath. Ask for clarification; nobody minds, and people rather like being asked.
• Cost of living. London is expensive, and rent will take a larger share of your budget than you're used to. Plan for it, and remember that salaries partly reflect it.
• Rain and pace. The city moves fast and it rains. A good coat and a good routine matter more than you think.
• Fundamentals. Bring them with you. Frameworks change every few years; HTTP, HTML and SQL travel well across borders and across decades.