Happy new year everyone! I hope you had a fantastic festive break. I had a lovely relaxing one and spent two weeks reading lots of books - I might start doing tech-adjacent book reviews on the blog to combine my two hobbies, watch this space! I was definitely not ready to come back to work yet and would have quite happily had another two weeks off, but I must admit I am enjoying it now that the week is in full swing. Actively using my brain to solve problems is thankfully still something I like doing. So let’s talk about the kinds of problems I encountered this week.

Returning to work after a break is tough

I feel like this is an obvious one but it bears repeating: when you’ve had two weeks off work, it’s tricky enough remembering the password you use to log onto your laptop, let alone where you left off before the break. I was putting a lot of pressure on myself to “hit the ground running” and immediately be 100% productive when this is a pretty tall order. If you found yourself doing this too, try to go easy on yourself. It takes a few days for the brain to get back into the swing of things and that’s okay. I hate the fact that productivity is seen as this holy grail - we are not machines, we are human beings and sometimes we just need to take our time and ease ourselves back into working, drinking a cup of tea while we do so. I need to remember this for the next time I take a long break like this.

Tests are great for refactoring

My team is currently working on migrating our application to Next.js and there’s a lot of moving parts to it all. We’re moving to Next.js app router, which is new to most of us and I’m finding myself regularly getting confused about the server/client boundary and how to make sure we don’t get ourselves stuck in a client-only trap. I really want to spend a day delving deep into all of this and I’m hoping to do so next week - maybe some useful blog posts will come out of it too! At the same time as this Next.js migration, we are modernising a bunch of code in several different ways so there’s lots of moving parts. It’s hard to keep track of it all sometimes. It’s really become clear to me this week how important it is to have good test coverage while doing big refactors like this. Having end-to-end test coverage of all your major journeys for example means you’re able to run them as you go - if the tests pass, you can be relatively confident that the migrated code works the same way as the original. The same goes for smaller-scale changes: if you have unit tests for a bunch of code you’re converting from JavaScript to TypeScript for example, you can be fairly sure that the change was a success if the unit tests all pass. This is generally why I will check for tests before I do any refactoring and write some if they don’t already exist. First of all, it helps me understand the code, which helps a great deal if I didn’t write it and second of all, it means I have the confidence to make changes, knowing that the tests have me covered.

Launches can bring unexpected surprises

This week saw the soft launch of a feature I’ve been working on and as people started using it, we found that there were a few assumptions we’d made that needed addressing. It’s always difficult to know how your users will use a feature, especially once you’ve been staring at it for months and you’ve lost all sense of objectivity. This is why it’s super important to share your feature as you are coding it and get users to look at it early, which was entirely the point of this soft launch process. So far, I have added a bit of simple form validation to improve the user experience and reduce confusion. I’m intrigued and excited to see what else we uncover and how we can make this feature even better before we launch it to everyone. I guess that’s the key takeaway here - picking these things up isn’t a sign of failure, it’s an opportunity to learn and improve. It’s almost impossible to predict what your users will do with your feature once it’s “out in the wild” so the only thing we can do as developers is watch and learn. And that goes for soft launches as well as real ones - I will be keeping a close eye on our monitoring and analytics to see whether users are doing things we did not expect once this goes live.

Fun at work is important

At least, I think it is. This week, after everyone had come back from holiday, we had a huge list of pull requests ready to be merged and we were trying to think of a way to manage it all. Something we did on one of my previous teams came to mind - a merge train! I suggested it to my team and everyone was immediately on board. A merge train is just a fun wrapper around a rather boring task: making sure PRs get merged quickly and in a good order. Someone is the “conductor” and decides on an initial order, which folks can question if they feel like there’s a better way to do things, but the conductor has ultimate right to say “yay” or “nay”. We ended up doing feature PRs earlier and tech debt PRs later in the order, with a few big migration PRs towards the end with more breathing room for testing. The PRs were grouped by author so people could merge their PRs and forget about it. I went all out and played the part of the conductor with lots of “choo choo” noises and emojis (very much inspired by Simon from my old team who was an excellent conductor) and I hope it injected some fun and silliness into people’s days. Especially if you are working on a remote team, fun is a chance for connection that you don’t get as often when you’re not in the office. So start a merge train or a poll on people’s favourite chocolate bars or have a quiz and play some games. It doesn’t all have to be so serious!