Tips for big migrations

This Design System upgrade will touch a lot of files in our codebase and before we got started on this work, I had a Big Think about how best to approach this. First of all I thought about whether I could split this huge migration into several smaller steps. I looked at it from all sorts of angles, because if this was possible, it would make this work much less risky and easier to test. Sadly, this turned out not to be feasible and we were going to have to do this in one giant PR, so I had to change tack. My idea was to put two engineers on this work, pairing at all times to avoid the work stalling - with big PRs like this, staleness is your enemy because eventually the merge conflicts will become impossible (or at least very tricky!) to resolve. Having two engineers working on it at once means the context for the work isn't just in one person's head and it means if one of us needs to take a day off, work can continue. The other thing we're hoping to do is have a soft code freeze for a few days while the whole team swarm tests the app and finds any UI bugs and issues. That's for next week - wish me luck!

How to pair effectively

Pairing can be quite draining if you're not careful about it. Being on a multi-hour call, working purely on one thing while someone is watching you type is most people's idea of a nightmare. So how can you make it less painful? A strategy I've used multiple times now that seems to work pretty well is Pomodoro timers. If you're not familiar, the Pomodoro technique is a pretty well known technique for deep focus work - you set a 25 minute timer and only work on one thing for that entire time, then have a five minute break to refresh yourself. My teammate and I applied this to pairing by setting a 25 minute timer, checking in with each other to see whether we were still okay to keep going - if not, we'd have a five minute break and if we were, we'd do another 25 minutes and have a ten minute break afterwards. It meant we were focused for long periods without getting tired and if we were in the middle of a task and in a bit of a flow state, we could continue. I should add that if at any time either of us needed a break, we were able to say so and stop the timer early - this is important, we don't want anyone working beyond their capacity and everyone's capacity for focus is different. So yeah, next time you're pairing, maybe give this a try! It has certainly worked well for me.

Are we forgetting how to CSS?

I was musing on this a fair bit this week due to the work I was doing. A lot of developers these days tend to use their company's design system to implement all of their pages and components. This is mostly a good thing - having a design system implement all the accessibility standards and the latest fancy CSS so you don't have to means a developer can focus on just implementing the feature that's in front of them. However, I have heard lots of folks saying that their CSS just isn't what it used to be, because they're no longer practising those skills actively every day. A lot of developers I speak to are not up to date on grid, let alone newer features like container queries. I must admit, I know about the new CSS features but because I haven't used them in anger, I couldn't tell you how they work either. It's a real shame and I feel like it's a skillset that is slowly being lost, especially when you throw CSS frameworks like Tailwind or even AI into the mix as well. It feels like a bit of a shame to me, but I think I'm an outlier here - I know a lot of people consider CSS esoteric and hard to use, so I'd imagine a lot of folks are relieved they can just outsource that to a design system instead of having to write it themselves. Personally though I think there is something really nice about deeply understanding a specification like grid so that you can make it do what you want to do, rather than fighting with it. So... Go learn grid? Maybe I should do a post about it one day. And on the new CSS features too, given I'm behind on those myself!

If you’re not familiar with this series of books, they are works of fiction about software engineering and are sort of written like parables - the books are fun and easy to read but afterwards you feel like you’ve learned something. The Phoenix Project is about the broader view of an engineering organisation and how different departments should work together, whereas the Unicorn Project is about the zoomed in view and how engineering teams should operate to maximise not only productivity but also joy in their daily work, which is important when it comes to avoiding burnout.

About the author

Gene Kim hails from Portland in the US and has written several books about software engineering, most notably The Phoenix Project, but he's also written some other highly esteemed books like The DevOps Handbook (which I've also read and would recommend) and Accelerate (this one is still on my TBR - book review coming soon, I'm sure). This guy is clearly interested in helping large enterprises run smoothly because that's the subject most of his books address. He's got plenty of real world experience to back up his ideas, because he founded Tripwire in 1999, a company specialising in enterprise security software, and was their CTO for 13 years before he got into writing books.

The TL;DR

NOTE: This section contains spoilers, so don’t read it if that bothers you!

In the Unicorn Project, we meet a highly skilled Senior Engineer called Maxine who has unjustly been blamed for a payroll disaster at Parts Unlimited, the company she works for and the same company featured in Gene Kim’s previous book, the Phoenix Project. In fact, we learn that Maxine has been used as a scapegoat and has been re-assigned to the eponymous Phoenix Project, with promises of being allowed back if she behaves (i.e. keeps her head down). Maxine reluctantly agrees and chaos immediately ensues: she can’t get access to a Phoenix Dev environment due to all the red tape, developers are off working on their own features and hoping to put them all together in a big bang release and the project is scheduled to go live before it’s even complete due to an overly keen SVP who wants everyone to just “make it work” (we all know someone who’s dealt with someone like Sarah).

Maxine runs into a very helpful colleague called Kurt who magically makes her problems go away; he gets her all the documentation, build keys and environments that she needs, which means she can finally get somewhere. Kurt proceeds to invite her to an evening at a nearby bar and it’s here we meet “the Rebellion” - an elite group of engineers who are hoping to overthrow “the Empire” and get the Phoenix Project all fixed up and out the door. While at one of the rebellion meetings, Maxine meets the enigmatic Dr. Erik Reid, who should sound familiar if you've read the Phoenix Project - he's the one who tells Bill Palmer all about "the three ways". It just so happens that he is working as a bartender at Dockside, the bar where the rebellion meets.

Erik introduces Maxine and the rebellion to the five ideals:

1. Locality and simplicity - the idea that all teams should be able to contribute to a project independently i.e. engineers on one team shouldn't have to get other teams involved in their work to get things done. The key here is to make sure software systems are not "complected" together - in the book this likened to getting three strands of yarn and plaiting them together. Now, in order to make changes to one strand, you have to make changes to the others, which is in contrast to just having those three strands hang loose. Decoupling systems is definitely something we strive to do in engineering because it makes changing things so much simpler.

2. Focus, flow and joy - implementing the first ideal allows engineers to work in small batches while getting fast and continuous feedback on their work. This makes them feel productive and therefore joyous because they're not having to sit around waiting for things to happen. There is nothing worse than making some code changes, only to pass things "over the wall" to QA who then need to test things and pass it back for fixes. Big bang releases are more risky and result in firefighting and burnout, so engineers should be able to release small incremental changes almost constantly. This allow them to focus on what they're good at: solving problems with code.

3. Improvement of daily work - this one is all about paying down tech debt and improving working practices as you go rather than blindly following processes because "we've always done it this way". Making small incremental improvements on a daily basis as part of your standard workflow will stand you in good stead for the future and questioning how things are done makes good sense too - just because things feel familiar, doesn't mean it's the right thing to do. It's easy to dismiss making improvements to developer workflows because it's not feature work, but doing so will make feature work much faster and more efficient, which will pay off in the end.

4. Psychological safety - in order to question the status quo, psychological safety is absolutely tantamount. How can you see what's going wrong if no-one feels able to speak up? The example the book keeps bringing up is Toyota and their "andon cord", an actual physical cord that allows anyone on the assembly line to stop production immediately to point out an issue. This person is thanked for their insight, because they have stopped the issue in its tracks and therefore stopped it from becoming something more urgent.

5. Customer focus - ensuring that everything you do is for the customer means they will be delighted with you and will be happy to spend their hard earned cash on your products. The book goes into why you should spent money on "core" work (i.e. building the things your company is good at) and outsource "context" (the stuff that is holding up your company but your customers have no interest in like build pipelines for instance) and the fact that experimentation is key to keeping your customers happy. Trying out new initiatives and seeing how they go, stopping them if they're not helpful and supporting them if they are will allow you to create new revenue streams all while increasing the happiness of your customers. And increased customer happiness means more money - you basically can't lose.

Maxine is at the forefront of implementing these five ideals so we get to watch exactly how Parts Unlimited develops as a company thanks to the five ideals. I'll leave it there because I don't want to completely spoil the book.

My thoughts

I started off not enjoying this book as much as its predecessor and I found it tough going initially. I think that's because it's essentially the same book as the Phoenix Project but from a different perspective so it felt a bit predictable. However, once I got to the back third, I was enjoying it more and got through it a lot more quickly. I found myself nodding along to all the ideas in it.

Saying that, I didn't find the character of Maxine all that relatable. In my opinion, she could have just as easily been Maximilian because it felt like she was a man in a woman's skin. It's a bit of a shame because I was super excited about the fact that the main character is a woman - women still only make up about a quarter of the tech workforce so more representation is always wonderful.

The references to really ancient tech and all the geeky things pulled me out of the story a bit too. There are so many Star Wars, Star Trek, LOTR and Game of Thrones references it felt like the book was trying a touch too hard. Yes, okay, we're all nerds here, I get it! I don't really understand why the book refers to chat rooms, pagers and Tomcat (as a modern tech!) like it's 2002 - it was written in 2019 and I just found myself going "was anyone still using these back then?! because I sure wasn't".

Having gotten all my gripes out of my system, I have to say that this book does do a pretty good job of showing us what a healthy engineering culture should look like. I wholeheartedly agree with the five ideals - I know from experience that working somewhere where these five principles are actively upheld is wonderful and the difference is abundantly clear when they are not. I would highly recommend you check it out if you haven't already and if you haven't read the Phoenix Project yet, read that one too!

Overall, I give this book 6 stars out of 10. It wasn't as enjoyable as the Phoenix Project, but it still taught me some new things. In my opinion, everyone in an engineering leadership role should be given this and the Phoenix Project as required reading.

★★★★★★☆☆☆☆

Where to buy this book

You can buy The Unicorn Project from bookshop.org or your local bookseller. It is also available digitally on Kobo . I don’t use Amazon so will not post links to it here, though I’m sure they sell it too.

NPM aliases are pretty cool

I learned about NPM aliases this week as I was looking to install two different versions of the same package in one repo, which is exactly what they allow you to do. Here's how you add an NPM alias:

npm install <alias>@npm:<real-package-name>

Unfortunately, my plan didn't work out due to the fact that the dependencies I was trying to alias were all interconnected. So when I aliased one package to a specific version, that aliased version was still trying to access the non-aliased version under the hood.

Such a pain, but it was fascinating to learn more about this new tool. I also learned that there's a gotcha in Yarn Classic (another thing we have to migrate away from), where it won't find a scoped dependency's registry if it's aliased without the scope. i.e. if you have a package called @something/cool-package your alias needs to be @something/cool-alias-legacy for it to work. That took a while to figure out!

I might do a longer post showing exactly how to use NPM aliases at some point.

Panda CSS is also neat

Another topic I want to do a longer post about at some point is Panda CSS. It sounds cute, but it's actually just a CSS-in-JS library that works with React Server Components. Traditional CSS-in-JS libraries like styled components and Emotion only work client-side as they generate CSS at runtime and inject the styles into the <head> tag. With the move to the server, these libraries have lost all momentum and aren't really being supported any more. A lot of developers choose to use Tailwind because the styles are generated at build time, but Tailwind uses utility classes, which can lead to long strings defining your styles that aren't always easy to read. Panda CSS combines the build-time generation of styles with the nicer developer experience (depending on who you talk to) of having native CSS available to use. Setting it up is pretty simple and I found it quite nice to use, especially because I'm already used to using styled components and class variance authority. Keep your eyes peeled for a longer post on this one.

Big bang migrations are not

I hate big bang migrations. They keep me up at night, they're so anxiety inducing. I'm sure there are developers out there who thrive in the chaos of touching hundreds of files in one PR and keeping all of that ticking over while the rest of the team is merging at many PRs a day, but that developer is not me. It is looking likely that I will have to do one of these soon, and I am trying my best to figure out ways to reduce the impact, both on our codebase and on my mental health. I have tried to slice and dice this migration many different kinds of ways, but I so far, I haven't found anything that works. So my plan is to do this the hard way while putting guardrails in place to make sure the PR doesn't go stale and gets merged quickly. If my plan is successful, I might just write about it one day. Wish me luck!

Everyone's career is unique and different and that is a Good Thing. I often meet bootcampers who feel an enormous amount of impostor syndrome when comparing themselves against Computer Science graduates who have taken the more "traditional" route. Those feelings are, of course, completely valid (all feelings are!), but personally I would say "nonsense" to that. Bootcampers are some of the best teammates I've had the pleasure of working with and just because someone had their start later in life or didn't do a degree in computing, doesn't mean they aren't just as competent.

This post gets slightly self indulgent from here because I wanted to show that just because someone has a degree in Computer Science (like me), it doesn't mean their journey was a smooth one - I think of my career as a very winding path. I'm fairly happy with the way things are now, but I have definitely experienced impostor syndrome and some shame around the amount of time it has taken me to get here. Ageism is rife in our industry and I do often worry about that, but this post is a middle finger to that, because again, everyone brings their unique experiences to the job and having decades of on the job experience should be celebrated rather than punished.

Anyway, let's begin... Here's the winding path I took to get where I am today.

I did Computer Science at University by sheer accident. I’d built a website as a teenager and I enjoyed it, I’d even dabbled in a bit of BASIC after finding a book about it in the local library and I figured “why not?” because I had no idea what else to do - turns out eighteen years old is way too young to decide what to do with the rest of your life. I had no idea Software Engineering was supposed to be a good career choice (though something should have tipped me off because my dad was super keen), I just thought it was fun.

After I graduated, I really struggled to find my first proper programming job and ended up doing a lot of temping - photocopying, making cups of tea, filing, data entry, that sort of stuff. I graduated at a time when there were very few software engineering jobs around and, much like now, an entry level job required you have three years on the job experience. I had rent to pay, so I wasn’t going to hang around waiting for that perfect job to come around. In the end, it took me two years to find that elusive first role.

And as it turns out, it was rubbish. I was extremely grateful to have a programming job, don’t get me wrong, but I encountered some of the worst sexism and misogyny there and I didn’t even end up writing any code! I was heartbroken, but in the end, I had to cut and run after a few months because the toll on my mental health was just too much. Back to temping I went. I got extremely lucky and a temping job for a web developer opened up on the campus of my old university - I was still living in the area so it was absolutely perfect.

I loved that first job (I actually count this as my first proper programming job - that other one was just a trial run) - it was an extremely small public sector organisation so there were only five or six of us and I was the only developer. It meant I had all the freedom in the world and I revelled in it. I got to build a website in Python, which was a language I hadn’t used before and I built some pretty cool tools for the team too - an annual leave calendar, an events management system - you name it, I built it. I couldn’t believe that I could get paid to do something that I enjoyed so much!

The temp job eventually turned into a permanent role and I only moved on because I moved further away and the commute became too much. I took another public sector job - this time in a college - and learned some PHP this time. I went for the interview after thinking to myself “how hard can it be?” I hadn’t written any PHP at that point - the benefit of beginner’s mind, I’m not sure I’d be so brazen now! I impressed the interviewing panel by writing my code in Notepad (this is absolutely hilarious now!) and I somehow got the job.

Yet again, I was a team of one - while this was wonderful in some ways, I can really see how it hampered my career in others now that I’m older and have worked at larger companies. There was no support network - no one else knew how to do what I did, so there was no peer review and there were no quality checks. My work could have been utter garbage and nobody would have known, least of all me.

I only stayed in this job for about a year, because I had a genius (or slightly harebrained) idea - I was going to do consultancy work. I’d done some part-time work to earn some extra money and saw an opportunity to take this further. I ended up working for the last two companies I’d worked for because I had a good relationship with them and got a bit more work on the side. It was all going swimmingly… Until we had a financial crisis and all my work started drying up.

One of the companies I was consulting for offered me a permanent position and I took it. It was a stable job with decent pay and we got yearly bonuses too, what’s not to like? I always say to folks “everyone should join a startup at some point, ideally when you’re young” and that is what I had done. It’s hard, gruelling but kind of satisfying work and you will learn so many skills - not just programming either. I ran the company’s email and file server for the best part of five years for example. Oh and I fixed people’s laptops because we didn’t have anyone else to do that stuff. I hasten to add that I had no idea how to do any of that stuff - I did a lot of frantic Googling during my time there.

In terms of code, we went from ActionScript (the programming language that used to come with Flash of all things), Mochikit, jQuery, we tried to build our own framework for a bit, then we found Angular and immediately switched to that out of sheer relief, then found React. On top of that I did some more Python and PHP too and built the company’s Knowledge Base using Drupal. It was an interesting mix of stuff, but it was a lot.

In hindsight, I should have moved on sooner than I did, because I ended up staying in one place for ten years. I got stuck in a bit of a rut and I was afraid that with my mixed bag of skills - I was very much a jack of all trades, master of none - I would never find a good programming job. Of course, I was wrong. I decided to focus on the front end because that’s what the majority of my role had amounted to in the end and finally took the big scary plunge into the unknown of a job writing React code. It was technically a step down, but that’s just what I needed at the time, because my confidence was at an all time low and I didn’t know what to expect from a non-startup world.

This was my first “proper” programming job. We had PR reviews! We had standups and refinements and all of that Agile stuff. We even had some test coverage in our repo - before this I’d only ever written tests if the code was so complex that I couldn't really avoid it. Whereas my previous role gave me breadth, this one gave me depth. I found that I loved working in a proper software engineering team and even though the PR reviews were tough at first (ouch, my ego!), I learned so so much from my colleagues.

I quickly found that I wanted to progress up the ladder and the opportunities just weren’t available for me, so I got a new job as a Senior Software Engineer - the first time I’d had the word “engineer” in my title and I’ve got to be honest, I thought it was the best thing ever! No more “web developer” for me. I loved being a Senior Engineer at this place - it was even more of the software engineering team stuff that I loved, but we also had mentoring and Community of Practices and random workshops on networking in AWS.

I had a voracious appetite for learning in this role - I just wanted to learn, learn, learn and learn some more. So I did. I did my AWS certifications, I learned all about infrastructure as code and Next.js and performance and who knows what else. I also got really involved in the community side of the job - I ran the front end Community of Practice with my teammate (hey Matt!), I helped run the mentorship scheme, I set up lean coffee chats so people could get to know each other, given we worked remotely and it went on and on.

All that work eventually landed me a promotion to Staff Engineer and I was super proud of that. It took me twenty years though, so it definitely wasn't a quick and easy journey. But I’d put in a lot of effort and it had finally paid off! Getting a job as a Staff Engineer is tough - there are very few open roles and getting promoted internally is generally even harder. The silly thing is, I didn’t adjust my own expectations. I was still doing all the community stuff and all the learning and all the everything, on top of the changing workload of my day-to-day, which was shifting, quite understandably.

I've already written a whole post about what happened next - I ended up taking a step down because it was all far too much for me. While there were aspects of being a Staff Engineer that I loved, Senior Engineer feels like the sweet spot to me for now - I get to tackle challenging problems without having to spin ten different plates and feeling like I'm never quite going to manage it.

So yes, all this to say that if your career has been a smooth upwards trajectory from Junior to Staff, fair play, but most people's careers don't actually look like that, even when they do come from more traditional backgrounds, and there is absolutely no shame in that. Your experiences make you uniquely capable of doing your job - I often feel like the tough start in my career has given me a resilience that I perhaps wouldn't have had otherwise and working at a startup has uniquely prepared me to deal with chaos and enabled me to set good boundaries (I am never working at the weekend or overnight ever again).

I am a firm believer in celebrating people's differences and I'd much prefer having a diverse team from different backgrounds than just a bunch of Computer Science grads - the world is so very boring if we're all the same!

Visual testing with Playwright

First off, I wanted to mention something cool I discovered while I was thinking about this design system migration - if you already have Playwright in your repo, you can set up a pretty quick and dirty visual regression testing suite with its screenshots ability. When an update touches a lot of code and requires detailed UI comparisons, a visual regression test suite can be a life saver. I wanted to have a go at making one to prepare for this big migration and it was honestly so easy to set up - I did ask Claude to help me because this is a case where I'm not going to keep the code after the migration is done, which sped things up even more. Essentially, all you do is set up your tests as usual and call the screenshot function like so:

await page.screenshot({ path: 'screenshot.png', fullPage: true });

The fullPage means it'll capture everything below the fold as well. I (well, Claude) had to add a few extra bits and pieces to make sure the screenshots were stable, because Playwright will take multiple screenshots to make sure the page has stabilised and if those screenshots aren't the same, it will have a little cry about it. I still haven't quite figured out what the best way to handle this is - if I do I'll share it in next week's roundup. If you have any tips, let me know!

I'm still not sure whether this will actually do more harm than good - I know visual regression tests can be a bit flaky and tricky to get up and running correctly. I guess I'll let you know that next time too.

Communicating while stressed

As I said in the intro, I've had a busy week and it's been like that for a little while if I'm honest. It has made me reflect on those inevitable shifting priorities and requirements that we get hit with all the time in our jobs and how best to manage when we are stressed by them. I don't think I've ever worked at a company where this wasn't a thing by the way, so being more resilient is a skill I would like to cultivate. Saying that, I don't mean that I would expect to be completely unaffected either - it is okay to be upset when you have invested considerable time and effort into something only to be told it is all going to need to change. What I am more concerned about is communicating with colleagues when we are experiencing strong feelings - it can be easy to lash out, when often we are all in the same boat and these pressures are coming from other areas of the business. I don't think there is anything wrong with voicing your frustrations, in fact, if you are in a psychologically safe environment I would encourage it so that your frustration doesn't become resentment. However, it's also important to make sure you do this considerately and tactfully. Something I'd like to try next time is just stepping away from the laptop when I'm feeling that pressure building and taking five minutes to make a cup of tea or even go outside, just to think. And then come back and think about what I'm going to say - I have the tendency to shoot from the hip when this kind of thing happens and sometimes I end up regretting the wording I chose in the moment (thankfully editing messages on Slack exists!). What are your favourite tactics for handling communication while stressed? Let me know in the comments, I am looking for opportunities to learn.

Spring is coming

And finally, I am so freaking excited that the days are getting lighter and the weather is getting warmer. One thing I don't much like about being a software engineer is the fact that our jobs are very sedentary and we generally have to be near a power outlet to function so we're kind of stuck inside. I have started going for walks before work to make the most of the light and get some fresh air and honestly, it helps so much! I often come up with ideas when I'm out on walks, related to work or otherwise. And who doesn't love seeing all the beautiful flowers and hearing the birds chirping away. Highly recommend you get yourself out for a dose of vitamin D this week if you haven't already.

Saving time with CircleCI

I managed to fit a tech debt ticket in-between everything else going on this week and it's something I've been wanting to add to our codebase for a while - the ability to only re-run failed tests in CircleCI, rather than having to rerun the whole job from failed. CircleCI has a pretty comprehensive guide on how to do this and with the help of Claude, I had this up and running in not much time at all. I did this work in two phases - firstly I added the store_test_results step to all our test jobs, which meant we got some useful test insights in the UI - you can see things like which of your tests are being flaky and how long your tests are taking (on average) to run. Once that was in and well established, I did the second part, which was to update the test command itself to use circleci tests run. This command allows CircleCI to run your tests in parallel, but also means it knows exactly which of your tests failed and therefore, which ones to re-run. This should be a lovely timesaver for the team as instead of Re-run from failed, folks will be able to hit Re-run failed tests - I tried this with a single failed test and it reduced the time taken by about half. If you have CircleCI and haven't done this with your tests yet, it's worth checking out.

Making assumptions

The big feature I've been working on for the last month or so is almost ready to be deployed. We had one last meeting with stakeholders this week to make sure everyone was happy and, predictably, there were some things we'd missed that needed to be addressed. This is fine, it's part of being a fast-moving organisation, but I had sort of assumed I'd be moving on to something else by the end of this week and that didn't end up happening. I'm not annoyed about it, I think it's just a reminder to myself (and maybe to you) that until something is actually live and being used by customers, you can't assume it's finished. And even then sometimes we have to jump back onto something and hotfix or otherwise update stuff. I had hoped to get some time to spend on personal development, but that will have to wait until next week. Hopefully I'll be able to write about what I learn!

In person time is important

I had another reminder how important it is for me to go into the office this week. It helps that our London office is a lovely space with all the free coffee, tea and snacks that you could ever want, but really it's seeing people in person and having some social time that really helps my mental health. Being able to wander over to someone's desk and have a quick chat hits different than sending them a DM on Slack and I always find I learn so much more about what people are working on than through updates in an online meeting. We went for a team lunch, which was delicious and so much fun - my team really are a lovely bunch of people. So yes, I will continue to go in twice a month, by choice - I know that's controversial for a lot of people. I guess I would like to clarify that just because in person time is important for me, it doesn't mean that I think everyone should go in - if people work better remotely and prefer not to see their colleagues at all, that's totally up to them. I just find that my mental health is hugely improved when I see folks in person.

About the author

Tim Berners-Lee should need no introduction, but just in case you've been living under a rock for the last fifty years, he was the man who invented the World Wide Web (not the internet, that already existed) while he was working at CERN in Switzerland. In the prologue, he describes how it was this wild idea of his to combine the internet with hypertext and that he would take every opportunity to bring this up, even when it wasn't really appropriate. I mean, CERN works on particle acceleration, not Computer Science stuff, so I'm not sure it was ever appropriate! In this book, Berners-Lee talks us through how he got there and beyond. With two mathematicians who became electrical engineers as parents, he was introduced to electronics very early in life and developed a passion for computers along the way, building his very own computer from bits of rubbish he gathered. Once the web was established, he didn't stop there - he founded the W3C (World Wide Web Consortium) to set much needed standards and the Web Foundation to advocate for a free and open web. His latest venture is a startup called Inrupt, which aims to put data in users' own hands (rather than having it siloed behind corporate paywalls) by creating a digital data wallet - a concept he calls "Solid", abbreviated from Social Linked Data.

The TL;DR

NOTE: This section contains spoilers, so don’t read it if that bothers you!

So it turns out that Berners-Lee's idea for the world wide web came from the coffee station at CERN - folks would gather around not just to have coffee, but also to share information. CERN is very much a multi-lingual organisation and scientists would communicate in their own languages and have separate silos of information, so it wasn't always easy to find out what you needed. The coffee station centralised access and allowed you to find a person who knew about a thing, or at least a person who knew a person who knew about a thing. You can see how conceptually, this can be arranged as an interconnected "web" of information - very clever.

The whole thing took a while to get off the ground - Berners-Lee himself confesses that he isn't the best at communicating ideas and it sounds like his colleagues liked him well enough but were extremely confused every time they spoke to him about this "hypertext thing" he was trying to get going. I must admit that find this image of someone who is so excited and passionate about their own idea that they're getting in their own way kind of endearing. I am very nostalgic for the days of the early web, as I'm sure a lot of millenials are, so it was lovely to read about how it all came together through people's sheer will to make it happen and a sense that this was important.

It's interesting to hear about both the exponential growth of the world wide web and the struggles it's had to overcome in the early days. There's lots of little anecdotes shared by Berners-Lee that show how the web could have turned out very differently - he himself was envisioning it as an editable source of information, like Wikipedia, but that never took off. Selfishly, I'm sort of glad it didn't, because who knows what my career would have been like if folks could have just edited their own content from the beginning! I started off writing HTML for fun as a teenager and without that first step, I'm not sure I would have become a programmer. There's also the story of how the language of the web could have easily been Python rather than JavaScript if Guido van Rossum had gotten his way, which would have been interesting!

Berners-Lee's ethos (the eponymous "this is for everyone") comes through loud and clear in this book - I particularly love this quote: "the connectivity of the web accomplished something else I really hoped for - it allowed people to make connections across barriers of class, ethnicity and culture". He has advocated tirelessly to try and make sure this message does not get lost and has even devised a contract for the web that countries, companies and individuals can look to for guidance on how to treat this precious resource.

The book goes right up to the modern day (it was published in 2025) and charts Berners-Lee's career and private life in some detail - I have listed some highlights here but I encourage you to read the book yourself.

My thoughts

Although it took me a minute to get going on this one, once I got 20% or so in, I sailed through the rest of it on my train journey to and from work. The book is written in a conversational style and is aimed at the average reader rather than folks who are overly technical. Stories about the web and its development are interspersed with personal anecdotes - anything from Berners-Lee's running style being like that of a dog to the day he met the Queen for the first time - which makes for an engaging read.

It was also lovely to read a book about the modern web that was not just full of despair but also offered solutions (looking at you Enshittification - though I did very much enjoy that book too!). Somewhere along the way, the original open ethos of the web has gotten warped purely for the purpose of furthering capitalism and that has to change. I like the sound of the Solid concept - the idea is simple: all your data should belong to you. Any time you use an app or a website, if any data is created, it should be saved to your personal "pod" - kind of like a wallet that only you have access to and you can grant others access to it as you see fit. Having all that data together in one place would create interesting opportunities not just for planning life but also learning more about yourself and your habits.

Berners-Lee is an AI optimist and thinks it's not too late for us to stop AI from going rogue. I am not entirely sure I share his relentless optimism on this front, but I'd like to. Humanity is going down a dark path, but perhaps it is possible for us to bring ourselves back from the brink with the right laws and regulations.

Overall, I highly recommend you give this book a read.

My rating

★★★★★★★★☆☆

Reserve This is for Everyone from your local library like me, or you can buy it from bookshop.org or your local bookseller. It is also available digitally on Kobo and you can even listen to it read out by Stephen Fry and Tim Berners-Lee on libro.fm. I don’t use Amazon so will not post links to it here, though I’m sure they sell it too.

Taking care of yourself is vital

This week has been a tough one. Work has been really busy and stressful and I've been feeling it in my body - my levels of anxiety and exhaustion have definitely been up. As a result, I've been eating whatever is on hand, not sleeping all that great and generally skipping out on the self care stuff. So I am trying to do better where I can - I cooked and baked from scratch this week even though all I wanted to do was sit and watch TV, I went for walks and I started meditating again. I feel so much better when I eat well, move and meditate. We get free Headspace with work so it's a no brainer to sit every day for ten minutes and yet it's the hardest habit to maintain for me. I notice the difference immediately when I do it though, so I'm going to try (again) to do this every day. Self care looks very different for all of us and I'd love to hear how you manage stressful times at work. Drop a comment if you feel comfortable!

Saying "no" is hard

I'm working on an urgent project at the moment, so I'm having to say no to a lot of other stuff, because I just don't have the capacity for it. If I context switch, I'll lose time that I can't afford to. I'm trying to be good at saying no, but it's not in my nature - I am very much a recovering people pleaser and while I have gotten to the point where saying "no" is no longer impossible, I still feel like I'm letting people down when I do. I'm very aware that just because I have my head in one particular area, it doesn't mean PR reviews and other things that could do with my input go away. However, it just occurred to me that I am part of a team and therefore, I should trust that these things will happen without me. When other people are overloaded and I have more time, I devote more time to PR reviews and help folks out, so why can't I expect the same? Just because I can't help unblock the team right now doesn't mean I'm failing. So yes, saying "no" is hard, but I'm doing it even thought it's making me feel somewhat uncomfortable.

My AI experiment is working

I mentioned in last Sunday's blog post that I want to take back control from Claude a bit. I have been trying to do this and though I've found myself slipping a few times, I have mostly stuck to this idea and I'm finding it less draining and more useful. I had let Claude have free reign over my unit tests last week (yes, I should have done TDD but I've been rushing) and it shows. I'd checked the unit tests themselves pretty thoroughly to make sure all edge cases were covered and the test names made sense, but the mocks were in a right state. So much so that it caused a lot of chaos when I added in a call to another endpoint to the page I was building. I had to sit there and manually comb through all the mocks and figure out what they were doing and sort them out. Now I immediately understand the whole thing better and can make better edits next time. There is something here, because getting AI to write mocks is, in my opinion, a good use of the agent's time - it knows the structure of the mocks from the types and it is much faster at creating the code required than I am. And yet, it is doing some weird stuff that makes the mocks harder to use. Eventually, I want to move the codebase on to using fixture builders because I think that'll make things much easier, but while we're in this hard-coded mocks land, AI is actually pretty useful. I just wish it would think about the readability and extensibility of its code more.

How it started

I've shared on this blog before that I started off a staunch AI skeptic, and that's true. I tried Copilot a few years ago, didn't see what the fuss was about and pretty much immediately discounted AI as a serious tool. I'd studied neural nets and LLMs at university and thought to myself "it's all just maths and weights and averages, how on earth can this help me code?" I didn't realise it at the time, but I had really only scratched the surface of what AI could do - I was using Copilot as a fancy autocomplete, which is probably where most of us start.

On top of that, I figured that the moral downsides far outweighed the upsides of using AI in my work - you know, the fact that companies are basically stealing our data to feed to their LLMs, use of AI is disrupting a lot of people's livelihoods and last but not least, destroying the only planet we have. This honestly really bugged me and we had serious conversations on my team at the time where we were being highly encouraged to use AI but a lot of us were simply not comfortable doing so for those reasons.

So what changed?

My journey with AI

In the intervening period, AI has become far more commonplace in tech and has become a standard part of a developer's toolkit. It didn't start off that way for me and it was a pretty long journey from deciding AI "wasn't for me" to coming around to it and seeing the usefulness of it.

My new role has had a lot to do with it if I'm honest. Starting a new job is an opportunity to try new things and figure stuff out and my new team has been playing and experimenting quite a bit of with AI. I discovered agent mode for the first time (I'd been using ask mode like some kind of luddite before that) and finally saw what AI agents could do with the help of agent files, skills and better prompting. I started off with Copilot, had a brief flirtation with Cursor and decided I didn't like it, tried Claude in the terminal and finally settled on using VS Code's Claude Code extension. I think this is where I'm going to stay, but who knows - new tools are coming out all the time!

A few months back, my team did a whole migration from Enzyme to React Testing Library with the help of AI and although it made a bunch of mistakes and managed to somehow always do some things in unconventional ways (despite us literally telling it our conventions!), it still saved us a bunch of time and effort in the long run and made an arduous migration (I have done an Enzyme to React Testing Library manually before so I know) a lot quicker.

So yeah, I'm no longer a staunch skeptic, can you believe it?

How it's going

Instead, I'm fully in the "this is brilliant, why didn't I use this before, how can I use this for everything?!" phase of adopting AI and I'm noticing some down sides that I wanted to chat about.

I'm finding myself using AI as a productivity lever - I can "be more productive" by sending AI off to do certain things while I work on something else and that is kind of addictive, but also not good for my brain. It's very cool that an AI agent can go away and build a UI component and write a bunch of tests for it with minimal input from me. However, this means I'm not doing that stuff - you know, the fun stuff? Instead I'm babysitting this overenthusiastic, sycophantic robot developer who despite having the whole internet at its disposal is somehow producing code at a level that is more junior than me and can't even do things the same way twice. All this while I'm also trying to write documentation, add tickets to our boards and anything else the AI can't do (yet).

In other words, I am spreading myself very thin and I'm not enjoying it. What started off as "isn't it cool that AI can do this?!" has become "guess I'll use AI to move as quickly as possible" (please note that nobody has told me to do this, this is a thing I've done to myself) and I'm not sure that's healthy. It's a level of productivity that will surely lead to burnout - I'm already feeling much more tired than I was a few months ago when I was using AI significantly less.

I'm also worried I'm going to stop learning and start forgetting. With Claude doing a lot of the heavy lifting, I'm no longer really thinking about the code. I'm just telling it what to do and reviewing what it's done to make sure it hasn't done anything ridiculous. I worry that as a result, code quality and architecture is going to suffer. Just because Claude is doing something in a certain way and it works, doesn't necessarily mean it's the best way to do something. I'm finding that I'm using those mental muscles less and less and offloading more of the thinking to Claude and I don't like that at all. As someone who has spent a long time honing those coding and architecture skills, I don't want to lose them.

And then there's obviously the moral shadiness of it all. AI's moral down sides haven't gone away and it's expensive to boot - someone shared our monthly bill on Slack recently and I was fully like "how much?!" So I'm not sure how comfortable I feel continuing to use it as much as I have lately. In a world that is very much encouraging us to lean on AI though, it's hard to say no sometimes. Luckily I'm fortunate enough to be working in a culture where it is acceptable not to use it if you don't want to, but not everyone gets that option these days.

Having become aware of all of these things, I want to try and make a bit of a plan going forwards, so I can still use AI (because I don't think the genie is going back in that bottle) while still retaining my sanity, my skills and my moral compass.

Full vibe coding kind of scares me...

Just as a quick aside, I had an experience just the other day that also informed this whole conversation: I fully vibe coded a Next.js app router version of this blog. As you may have noticed, Hashnode have been changing things around here. The layout of my blog is different and I didn't ask for that! The UI to manage the blog has also changed (not for the better) and it made me wonder "how hard would it be to use the exported markdown files from Hashnode and create a simple statically generated version of this blog in Next.js to host on Vercel?"

Turns out, very easy, especially if you use AI! I only have Copilot on my personal machine so I used that instead of Claude, but within an hour, it had a respectable looking Next.js app up and running (I've even put it up on Vercel). The thing that gave me pause is that I realised "I have no idea how any of this works" and that scared the heck out of me. In this case, the site is statically generated so there is very little that could go wrong in terms of security, but what if I were building something interactive?

So yeah, fully vibe coding something is not for me. I have since checked the code and it does seem fine (I understand it at least) and maybe I'll switch to this new version at some point? But I'd like to make it more my own first. The whole experience really made me think about how much less I'd enjoy my job if it was just managing agents and not doing any coding of my own - even at my most heavy periods of AI use, I'm still writing at least some code myself.

My plan for the future

Anyway, given all of that, how do we as developers leverage AI and still get to enjoy our jobs? It must be possible, surely?

Personally, I am going to try and shift my approach from Claude being the main developer and me being its reviewer and sidekick to the other way around. Like switching drivers in a pairing session, I guess? I will go back to writing code (and yes, tests) and only when I get stuck or need a second pair of eyes will I involve the AI. Even then, maybe I'll have a go at trying to research options for myself, though doing that without AI is tricky in itself these days, given the state of Google search.

What will this look like, you ask? It means making a conscious effort to slow down. To pause before launching straight into development and think "what do I need to do?" Something I used to do frequently before AI got involved - now I just craft a prompt and send it on its way. Once I've got a plan, I can start working on writing the code needed to execute that plan and at that point, maybe Claude can give me a hand. It also means not going "I'm too tired" or "it's just easier to let Claude do this" - it can be so tempting to just let the AI do the work and that needs to stop.

I'd like to use it less for writing entire UI components or test suites and more for things like "are there any accessibility concerns you can see with this component?" or "can you spot any edge cases I've missed?" I am also going to set pomodoro timers and focus on one thing - it's the best way I've found to make sure I don't try and do five things at once and honestly, part of the problem here is me. I'm allowing myself to be spread too thin, AI is just making it easier to do so. I honestly don't know whether this approach will work yet, because I haven't tried it, I've literally come up with this now. Maybe I can do a follow-up in six months and let you know!

I would love to know if you have any tips for how to walk this new rather futuristic line.

I’ve found myself being pretty tired the last few weeks. Ever since I started my new job, I’ve actually felt energised and have been enjoying feeling more vital and being able to do stuff after work rather than just collapsing onto the sofa. Coding more has been an absolute joy and I really missed that when I was a Staff Engineer in my previous role. My ex-colleague posted a really interesting article about AI fatigue on LinkedIn and it really resonated with me. It posits that using AI means you are reviewing code all the time instead of writing it - writing code is creative and energising, whereas reviewing code is exhausting, especially when it’s been written by an AI agent and you need to carefully double-check everything for hallucinations and errors. Add to that the fact that I’ve been up against a deadline so I’ve been sending Claude off to work on the feature work while I do various admin tasks or reviewing colleagues’ PRs and I am starting to feel like I’m spreading myself too thin. I started setting pomodoro timers again this week and making sure I focus on just one thing during those 25 minute periods and it has really helped. Having the five minute break afterwards is also a good excuse to walk around and have a stretch which meant my body wasn’t as fatigued either. If you’re using AI a lot and you’re feeling knackered, this might be an issue for you too.

🎉 I passed my probation

I got some fantastic news this week - I passed my probation, so now I am a fully-fledged member of the team! This has made me inordinately happy. I don’t know about anyone else, but my brain never feels very settled during a probation period. By all accounts, things here have been going really well - I’ve been doing lots of feature work, weighing in on big decisions, sharing knowledge through talks and pairing and getting lots of shout outs from my colleagues - and yet, I’ve felt like I could get fired any moment. Anxiety can be a right pain - you can tell yourself everything is fine all you want, but when it comes down to it, you never really believe it. Fingers crossed having my probation in the bag means I will be able to put down those insecurities. If you're in your probation period too, hang on in there and I hope you get good news soon too.

😅 It’s okay to be wrong

I suggested something this week that I was quite excited about. I had seen an opportunity to make our workflows easier and improve testing. It was something we did in my previous role that I thought I could bring across. I shared it with the team and was met with an (understandably) lukewarm reception. Initially, I was confused - surely this is a good idea? Why is everyone being so negative? But then I actually thought about it for a minute and realised I was the one in the wrong. Just because something works in one workplace doesn’t mean it will in another. I’m glad my colleagues felt able to stand up to me in this way (they were very nice about it!) and help me figure out why what I was suggesting was a bad idea. I ended up agreeing completely and this is the thing I took away from it: it’s okay to have ideas and it’s okay for those ideas to be bad. Not every idea is going to be the amazing thing that changes people’s lives and that is totally fine. It's important to be graceful when this kind of thing happens and not let it get you down. I’m definitely not going to let this stop me from making more suggestions - maybe next time will be the one!

I made a very conscious decision to take a step down when I was looking for a new role last year. I’d been a Staff Engineer for two years and I kept feeling like I was on the verge of burning out. I’d be sick every three months like clockwork and after work I would just collapse onto the sofa to watch TV or sometimes simply fall asleep, only to drag myself to bed when I inevitably woke up, only to then find myself unable to get back to sleep. It was a frustrating cycle. I had a lot of work-related insomnia too, where I’d find myself thinking about everything that had happened that day and I just wouldn’t be able to let it go.

I did apply for Staff roles when I was looking, but ultimately I felt it best to take a step down to Senior and I’m so glad that I did. When I was a Staff Engineer, I’d spend most of my time either on big technical decisions that took a lot of braining to figure out, or I’d work on the stuff my team didn’t have time for like setting up dashboards, paying down tech debt and applying security fixes. I’d also be in a lot of meetings as the technical expert. Things couldn’t be more different now - I get to code most of the time and I have so few meetings that I still pinch myself every day. I am so much happier and I actually have energy after work which means I get to see my friends more often and have a much more enjoyable life in general.

So why do I still feel like I’ve lost something? Sure, there were aspects of being a Staff Engineer that I enjoyed. The role is rare and coveted and it felt so good to know that I’d made it. However, that also came with a huge amount of impostor syndrome - I don’t think of myself as very technical (though I’m fairly certain this is a perception issue on my part) and I’d compare myself to other Staff Engineers and think “I can’t code in twenty different languages, I’m terrible at this”. I also kind of enjoyed the big brain technical stuff - I love a good spike and I love a nice orderly spike outcome document. Delving deep into an ambiguous problem and coming out of the other end with a neat summary of what the next actions should be gives me life.

I feel like missing the title of Staff Engineer is pretty problematic to be honest. It has made me think about what we as engineers, and maybe even in society, value. We are encouraged to strive, to reach the next rung on the ladder and to get there as quickly as we possibly can. Taking a step down and choosing not to strive has a fair bit of stigma associated with it and is seen as failure somehow. And yet, if it makes you happier, surely it’s a success? Sadly we collectively seem to praise climbing the career ladder and if you can do it quickly, even better.

There are speed running guides out there that will supposedly help you get from Junior to Staff in three years. This is way too fast in my opinion. We need time to learn our craft, to settle into ourselves and to learn from our mistakes. You can only really become a Staff Engineer in three years with a lot of help from a mentor or someone else who’s much more experienced. I know for certain that three years into my career, I would have made a terrible Staff Engineer. I was too inexperienced and made a lot of mistakes and I definitely didn’t see the bigger picture when looking at problems.

This article is turning into another ramble. How do I sum up what I’m trying to say? Charity Majors says it a lot better than I do: the hierarchy is bullshit. Just because there is another level to reach, doesn’t mean you have to reach for it. I’ve taken two steps down in my career and both were the best decision for me at the time and made me so much happier. Not having that coveted fancy title doesn’t make you a worse software engineer and it might just make you feel more whole as a human being. So if you are re-thinking your career and wondering whether taking a step down is for you, don’t let shame stop you.

🚩 How did I forget about feature flags?

I am currently working on a feature that needs to go live pretty urgently. We’ve been scoping it out as we go, as is often the case when things are under time pressure. I sprung into action pretty quickly with it, scoping things out, asking questions, starting coding. What I didn’t do was create a feature flag and start building behind it. It had become second nature to me to do this in my last job and yet in all the hustle and bustle, I didn’t think to do it. I hadn’t seen many folks do this in my current role so it sort of… slipped my mind. So I was building up this massive branch on my laptop, adding more features as we were thinking of them. I feel like the thought process there was that because the feature wasn’t fully scoped out, I’d just work away at it on my laptop and push it up once it was “ready”. The reality being that it could take a while and landing a huge PR on my colleagues at the end of that process would be a bit of a dick move. So this morning I thought to myself “why haven’t I created a feature flag and started pushing PRs up?” and that is exactly what I did. Feature flags are an incredibly useful tool in a developer’s toolbox - they allow you to push code up to Production that can’t be seen by users until the flag is enabled. So in my case, it meant being able to push up some code for this new feature I’d been building in secret and getting invaluable feedback from my colleagues, who immediately spotted things I could do better and asked really important questions. Next time, I’ll be starting the development of all features I’m building this way. No more forgetting about feature flags!

✍️ Why I love technical writing

It probably comes as no surprise to you, given you’re reading my blog, but I really enjoy writing. I used to love nothing better as a Staff Engineer than being given a vague brief with lots of unknowns, going away and investigating all those unknowns and writing up my findings. I hadn’t had the chance to do that in the six months since I moved jobs, that is, until the last few weeks. I got a brief and I had no idea what I was doing. I wrote up a skeleton of a document and started filling it out with everything I knew about the topic (it was to do with CSS which is a topic I also happen to enjoy!). Once I reached the boundaries of what I knew, I dove into the codebase and started figuring stuff out. I noticed how much having an AI agent available to do the legwork for me helped with this. Rather than manually trying to find things, I was able to prompt it to help me and as I was looking at Panda CSS (a framework I hadn’t used before), it was able to help me understand the syntax and how we should be migrating to it too. It took me a while because I had a few other things on my plate but I delivered a document I was proud of and I’m hoping it’ll come in handy when we plan the work that comes out of it. It has made me think though: why do I love technical writing so much? I think it’s the fact that I get given such a fuzzy ball of unknowns and I get to detangle it and put it in order, but I also just like the process of writing itself. I don’t think I could ever let AI do that for me. I like to structure a document just so, so that my colleagues have all the context and get taken on a journey from start to finish. It’s a craft, just like anything else, I suppose, and it’s one (for better or worse) I really enjoy.

🤔 I’m starting to trust AI too much

I feel like I’m starting to trust Claude too much. I asked it to set up some personal rules files just for me, which it did - they’re meant to help it write code that’s more aligned with your personal style. My colleague told me about this feature in Cursor so I asked Claude whether it could do something similar. It said “yeah, sure!” and created some rules in a file called .claude-personal.md. I’ve been happily using it the last few days, but I’ve come to write about it now and I can’t find any record of any such thing! There are some articles suggesting you can create rules in a .claude/rules directory, but these are global rules for the whole repo when I wanted some things that were a bit more personal to me that I could put in a global .gitignore so that I can add them to any repo and they won’t get committed. A good lesson to double check whatever agents tell you, because they still hallucinate quite a lot! I’ve come to expect this with code and always carefully check whatever generated code I commit, but I guess I figured the agent must know its own capabilities. Turns out I was wrong…

EDIT: I ended up asking Claude whether it had hallucinated when it suggested this filename and it told me that actually, it had not, this was just its suggestion for creating a personal rules file because Claude Code doesn’t natively support this feature. This method works, you just have to make sure you add it to the context using @.claude-personal.md every time you tell it to do something. I was hoping for something that wouldn’t require an explicit mention, but I suppose this will have to do for now!

🚦Releasing new features can be easy

The feature I started working on when I started my new job nearly six months ago has finally been released! We flipped a feature flag on Thursday this week and watched all the traffic come in on our hypercare dashboard in anticipation. It was exciting, but also, quite honestly a little underwhelming, which is what you want releasing a new feature to feel like, ideally. If things have been planned correctly and you have all the right monitoring and observability in place, releasing a new feature should be no big deal at all. We also made sure to run a soft launch to a small percentage of internal users before releasing to all customers, which definitely helped make sure the feature was stable and ready to go. The surprising thing is that even the soft launch went perfectly - this is not me bragging (though I admit it sounds like it!), but I was expecting at least something to go awry. So yes, releasing new features doesn’t always have to be harrowing and can be a complete non-event. We’ll keep monitoring things for a few days, but things look to be going well so far at least!

🧠 Context switching is still hard

As mentioned in the intro, I was assigned a new feature this week (the one I researched using AI last week), which has been an interesting challenge, but it has involved a fair bit of context switching whilst I am still finishing off other bits and pieces. The launch of the aforementioned old feature happened in the middle of trying to get my head into writing code and I am still trying to finish off a report too. And then there are the kick off meetings to decide on the exact requirements of this new feature, which, while related, still mean I have to stop coding and do something else with my brain. Annoyingly, I missed the start of a meeting about auth I was very interested in attending because I had finally gotten my head into the code and was on a roll. Unfortunately, I believe context switching is very much an integral part of a software engineer’s role as a knowledge worker and yet, even after a long time in the industry, I feel like I am still not good at it. I know I am not the only one and studies have shown that it can take twenty minutes to regain focus after interruptions, but it is something that I always feel I could be doing better. Something I end up beating myself up about, you could say. I suspect I will simply need to accept that context switching will slow me down and that it is impossible to prevent. Feels unsatisfying though, doesn’t it.

🔐 Auth-related impostor syndrome

Maybe it’s just me, but I find authentication, at least in practice, quite difficult to wrap my head around. In theory, OAuth 2.0, which most folks use these days, is quite straightforward, but it is never actually that simple in my experience. I get that you use a token and that allows a user access to a website, that’s not a problem at all, but it’s the details of the implementation where it often gets fuzzy for me. How does the app actually use that token to grant people access? What are the edge cases? Why does it take so much code to enable this very simple concept? And so on and so forth. I got close to understanding how auth worked in my last place thanks to some very talented colleagues who explained it to me over and over again with extreme patience, but I never quite understood it as much as I would have liked. And now, I am experiencing this same feeling in my new role. It makes me wonder whether authentication and I are just never going to be friends. I’m trying not to take it too seriously as I only started six months ago and I’m still processing a lot of new information, but I do feel a sense of imposter syndrome around this stuff. “If I can’t even understand how auth works, do I deserve to call myself a Senior Software Engineer?” - that kind of nonsense is going through my head. I am sure most other software engineers can relate, if not about this particular topic, about something else. I guess it’s important to remember that if I met anyone else who was struggling with this I’d say “authentication is complicated and there are so many other areas you do understand well, why worry about this so much?” and, quite honestly, I wonder whether me worrying about not understanding it is also sort of preventing me from getting there. Letting go of those high expectations might be a necessary first step!

🛑 Knowing when to quit is a good thing

No, I didn’t quit my job, don’t worry! I was just working on a pretty annoying bug this week and last. It was one of those bugs that seemed like a quick fix, but ballooned into something bigger. We’ve been adding logging into our codebase (see last week’s post for the importance of monitoring) and uncovered an issue. I merged a fix that improved our error messaging and made the journey more consistent for our customers, hooray! The error rate went down, but not to zero. Confusing. I spent a frustrating week adding more and more logs to our code to see whether I could figure out where the issue was happening. I could not. In the end I had to admit defeat for a while because other priorities came up and the journey was vastly improved so at least users knew what to do when this error occurred. I still made a ticket for me or someone else to look into this again later though. On a related note, I found out that Datadog notebooks are fantastic for this kind of debugging work - you can copy and paste your widgets right into them, which allows you to build up a picture for anyone who’s interested in the context (and the detail) of your debugging. I might write a separate post about this at some point showing how I would write a document like this. Anyway, not figuring out the bug sucked and it’s going to be bugging me for ages, but perhaps letting it percolate in the background while I do other things and get to know the code better will help me figure it out later down the line.

🙌 AI is a godsend (but always check its work!)

I got asked to put together a report at pretty short notice this week, for something we needed estimates for the next day. I must admit I panicked - I’m still new enough in this role (though coming up to my six month probation!) that I don’t know the codebase all that well and I understood about 70% of the conversation the team and I had in the kick off meeting. I did what I always do in these situations: start writing. I wrote down what the ask was, what outstanding questions I had and what unknowns there were. Then I started filling out the document and I found AI extremely helpful for this. Our documentation is all in Notion, so I asked Notion AI to help me find further documentation to help explain the project we were working on - it found a really helpful document but it was super long so I asked it to summarise for me. Within minutes, I understood the context and was able to write a succinct problem statement. We had a proposed API response to work from, so I fed it into Claude and asked it to figure out how our code would be able to deal with this change - it told me our code was built very resiliently so there was very little we had to do from our side. I went through and checked what it was telling me with my own human eyeballs (because you should always do this - it is frequently wrong in my experience!) and yes, it looked like it was correct. Instead of spending a couple of painful hours agonising over this task and not getting very far, I had a report written for my manager by the end of the day. I admit I was a staunch AI skeptic when the AI craze first started, but I am really coming around.

😫 Isolation can be tough

I have come to realise something about myself in the last year or so, which is that much as I like my own space and love living alone, I actually find working from home all the time quite difficult. I need to fill up my social meter every now and again, a bit like a Sim, and if I don’t, I get quite cranky. I knew going into a fully remote job that this could be a problem and I must admit it has been difficult for me. However, I’m starting to find ways to cope with it. I go into the office twice a month and that seems to be the sweet spot for me - I get to see my colleagues in person regularly without it being a big strain on my energy levels or finances. I also co-work with a few friends who have remote tech jobs once a week - we go around each others’ houses and work in the same space. It means we’re able to fill up our social meters without needing to go into an office and it’s great for me because I get to hang out with an adorable cat (as well as some of my favourite humans)! If you’re struggling with the isolation of working from home, I think it’s super important to build community outside of work as well as in. Go and see your friends regularly, even if it’s just for a quick coffee and a chat. If you don’t have the ability to go into the office, maybe suggest something fun for your team to do that hasn’t got anything to do with work - like a game of skribbl.io, GeoGuessr or if you’re lucky enough to have a willing quizmaster, a weekly quiz (this was something we did at the Economist and I really miss it!). Above all, don’t keep quiet about it - talk to your manager at the very least because this kind of thing can be brutal for your mental health.

📈 Monitoring is so important

I just happened to be working on adding logs and end to end tests for one of our journeys when we had a report that customers were seeing some weird errors on that particular page. I speed-merged the logging changes (followed swiftly by the end to end tests) and we immediately started seeing some interesting stuff in our monitoring platform. It turned out that the journey was not showing any error messages, meaning that users were rage clicking the submit button, further elevating our error rate. After some discussion, we decided to change the front end so that our customers got a nice friendly error message and the submit button disappeared when there was an error. You know what I’m going to say, but because I had end to end tests, that refactor was super easy to do and once it was merged, we immediately saw our error rate fall. Fingers crossed our users will feel less frustrated going forwards too. Adding monitoring to your applications is incredibly important and I would not skimp on it - adding it in as you go is a lot less effort than trying to retrofit it and you will benefit hugely from being able to see where your application’s problem areas are. It doesn’t even have to be pricy, you can use open source technologies like OTel, Elastic and Grafana, so there is literally no excuse.

🤖 Will AI put us under more pressure?

I found myself multitasking with the help of AI quite a bit this week. I would ask Claude to write an end to end test (for example), while I was off on another screen researching Next.js app router. I found myself wondering whether this is a good or a bad thing. Yes, having an agent in your pocket means they can do one task while you do another, but will that kind of multitasking mean we won’t do either thing well? You still have to guide an AI agent (for now at least) while they’re doing their work so it’s not possible to fully focus on the other task you’re doing. I ended up feeling rushed and overwhelmed and like I needed to be able to do it all. Not that this feeling is unusual to me, even when I’m not using AI. I guess I’m just wondering whether the temptation to let our agents be our ultimate multitasking buddies will be too great to ignore. I certainly found myself falling into this trap more than once this week.

🙋Knowing when to ask for help is a skill

I was working on a POC with a colleague this week and we got to a certain point and realised we were just kind of… stuck. So rather than bashing our heads against the wall, we went back to our team and arranged a couple of meetings with other people who had expertise in this area. It helped a lot and we are now unstuck again! It can feel like defeat, to say “okay, I can’t figure this out myself so let’s ask someone else for help” but actually, it’s a superpower. It’s an honour and a privilege to work alongside lots of clever people and it’s actually a really good thing to make the most of it and learn as much as you can from them. And in the meantime, you’re not wasting a load of time trying to figure something out by yourself.

😞 Feelings are great teachers

Because this week was stressful, I had some feelings - a bit of overwhelm and a bit of frustration. And that’s okay. It’s totally okay to feel those things at work, even when you have a job that you largely enjoy - this was a thought I had as I was kind of shaming myself for having feelings. It’s super important to acknowledge our emotions, because if they’re uncomfortable, they’re usually a sign that something isn’t right. Whether that’s something within ourselves or with our surroundings doesn’t matter - awareness is the first step and will allow us to course correct. In this case I was just trying to do too much and spreading myself too thin. I had also made some assumptions without checking in with folks whether my approach was correct, which is a recipe for frustration and a lesson I still forget sometimes. Lesson learned (again), let’s hope I don’t forget it again so soon!

About the author

Yanis Varoufakis is a Greek economist and politician who used to be Greece’s Minister of Finance - according to the book, this was due to a “historical accident”. Born to a father who was a Chemical Engineer and Marxist and a mother who was a chemist and a feminist, he was brought up with what some would consider some fairly radical ideas about how the world should work. He calls himself a “libertarian Marxist”, much to the confusion of, according to him, “several libertarians and most Marxists”. Varoufakis has taught economics at universities in the UK, Australia and Greece, so you’d think he knows a thing or two about the economy. He has written quite a few books about the subject and Techno Feudalism is one of them.

The TL;DR

NOTE: This section contains spoilers, so don’t read it if that bothers you!

This book is written as a conversation between Varoufakis and his father, who sadly passed away a few weeks before he started writing the book. It is essentially the author’s attempt to answer his father’s question: “Now that computers speak to each other, will this network make capitalism impossible to overthrow? Or might it finally reveal its Achilles heel?” For context, Varoufakis’ father was a staunch marxist and felt strongly that capitalism was not the way forward for humanity.

The book proposes that the internet allowed capitalism to morph into something different entirely: a system of technical serfdom whereby we are all slaves to the machine, or more accurately, a bunch of billionaires who run tech companies. Varoufakis’ argument is that in return for the convenience of using the internet and devices like Alexa, we effectively sell ourselves to Big Tech. They harvest our data, track our activity and curate our content, alongside which algorithms sell things to us and sell our attention to others. This basically turns us into their unpaid servants who train their algorithms for them, making them ever more effective. It’s a vicious cycle that is difficult to get out of in our perpetually online world.

Varoufakis terms the result of the free work we all do on the internet “cloud capital” - rather than using steam engines, machine tools, spinning jennies or telegraph poles to make money, Big Tech trades in this “cloud capital” and in the process, commands people and nations. He has other terms for folks involved in techno feudalism - “cloud proles” for the workers hired by Big Tech to advance its agenda and “cloud serfs” for the end users of technology who create content for free and “cloudalists” for those folks who run “cloud fiefs” representing giant websites like Amazon and Facebook. It’s a pretty blunt metaphor, but it works.

The author argues that Big Tech has become this powerful due to the way the 2008 financial crisis was handled by the central banks. The bailout of the banks, which was done by printing lots of extra money and putting it into circulation, caused money to essentially became worthless. At the same time, austerity measures meant it wasn’t being invested in new production lines, because nobody had any money to spend, so instead companies used the money to buy out their own shares. This instantly made the CEOs of these companies extremely wealthy and powerful. Then, once inflation rose to really high levels in 2022, these same companies had to shrink to continue to make money and this, I presume is why the era of mass layoffs began.

My thoughts

While the premise of the book is interesting, I went in expecting something a bit more tech-focused when really, this is an economics book and it reads like one. I am not an economist, so I found it hard going at times. Your mileage may vary!

The whole book is treated as a thought experiment and a conversation with the author’s deceased parent. It is very theoretical and doesn’t really deal with the practical, everyday experiences of those of us who work in tech. It was interesting to see the very zoomed out view and extrapolate as to why certain things (like mass layoffs) might have happened, but the content was rather dry at points.

If you like the sound of this book, but you’re also not an economist, you might want to check out The Invisible Doctrine: The Secret History of Neoliberalism. It covers similar ground but I personally found it a bit more accessible and, bonus, it’s fairly short at 224 pages.

My rating

★★★★★★☆☆☆☆

I’m sure this book is fascinating if you’re an economist, but I found it a tough read - I often had to read certain paragraphs a couple of times to figure out what was being said. I don’t think that’s the fault of the book per se, perhaps I am just not its intended audience. Check it out if it sounds interesting to you, but this is definitely not as tech-centric as it sounds. I give it a 6 out of 10 because I feel like I did learn something and Varoufakis’ metaphor is an interesting one.

Reserve Techno Feudalism from your local library like me, or you can buy it from bookshop.org or your local bookseller. It is also available digitally on Kobo and you can even listen to it read out by the author on libro.fm. I don’t use Amazon so will not post links to it here, though I’m sure they sell it too.

This week’s roundup has quite a bit of stuff about Next.js app router because that’s where my mind is at right now. I will for sure do some more detailed “tutorial” style posts about this soon because I’m learning a ridiculous amount. Getting to grips with a new framework is fun, but also a lot of work and it’d be nice to share some of the mistakes I made and things I learned so others are one step ahead of where I was when I started.

Anyway, without further ado, here’s some things I learned this week.

🎩 App router has gotten fancy

I’ve been delving into the Next.js app router this week and boy has it changed since the last time I looked at it. Back when Next.js v13 first came out, app router was extremely controversial and I remember having many conversations with my team at the time around whether we should switch and we very firmly decided “no, not yet” because everything was still quite experimental and new (and a bit broken). I’m not sure I’d say the same these days. You can tell some stuff is still actively being worked out, like the caching side of things, but I kind of like that Vercel have backtracked on that to be honest. When the app router first came out, everything was cached by default and even though cacheComponents (previously dynamicIO) is still experimental, it shows Vercel are listening and trying to do right by their users. Or maybe they’re just scared that everyone is going to leave them and build their applications with other frameworks, who knows. In any case, I’ve been doing Scott Moss’ Next.js Fundamentals course on Frontend Masters and have been quite impressed. It’s all making a lot more sense than it did back in the day and I don’t know whether that’s because Next.js has gotten easier or whether I have just had enough time to let all the concepts soak in so I have more of a holistic understanding of it all. In any case, Scott does a good job explaining some very tricky concepts so I recommend his course wholeheartedly if app router is still stressing you out.

🤫 Big changes can go in quietly

I opened four tech debt PRs on Friday last week and left it till Monday to merge them because I was a bit scared they were going to blow up in my face. One was for a Node update, another for a FOUR major version upgrade of a dependency, the other for using store_test_results in CircleCI (to get ready for re-running failed tests only) and another one for removing an unused dependency. I was pretty sure that last one would be okay, but the first two had a pretty big blast radius and I must admit, I was a little anxious about them. Luckily, they went in fine and I put that down to having pretty good unit and e2e test coverage - I know I keep going on about coverage, but it’s important! It meant I could be fairly confident that my changes would go in just fine. I also did some manual testing locally, I must admit, because I don’t think you can avoid it with changes this big. Once I merged the PRs, I made sure to keep an eye on our monitoring to make sure nothing looked broken. I created revert PRs, just in case, but they weren’t even needed, everything went in totally fine. It’s nice to acknowledge when quiet successes happen, because it’s so easy for them to go wrong and nobody notices when they go right. I also just don’t give myself enough credit for them, as I’m sure lots of us don’t!

🥫 It’s okay to kick the can down the road (sometimes)

I’m working on a big migration project at the moment and it’s super easy to get stuck down rabbit holes of the “oh, we could modernise this while we’re at it” variety. One example this week was updating the styling as our repo uses some pretty old conventions and a CSS extension language that I wouldn’t choose now if I were working on a greenfield project. Given how far plain CSS has come in the last few years, the thought of “we could totally update this CSS” occurred to me and while we could theoretically do that, I was working on a POC to show how to create a Next.js app router page, not even the migration itself! After a good sleep and a chat with Claude, I came to the realisation that I was taking this too far. I ended up importing the old CSS and leaving it, because “if it ain’t broke, don’t fix it” can be good enough sometimes.

About the author

Sarah Wynn-Williams is originally from Christchurch, New Zealand, and tells us in the book (in rather horrifying detail) about how she was attacked by a shark when she was just 13 years old. Her parents don’t believe how bad her injuries are and as a result, she almost dies, but she assures us that instead of this being a bad thing, this has given her immense drive, a desire to make a difference and the ability to pick herself back up after any difficult experiences. She certainly seems to know how to keep going in extremely adverse circumstances in which most of us would have waved a white flag and given up - I know I would have.

She studied Law at University and worked at the UN afterwards, but got frustrated at the fact that the UN was mostly talk and very little action, so she wanted to find somewhere more impactful. Wynn-Williams started working at Facebook in 2011 after convincing them that they needed her (they just didn’t know it yet) and was fired in 2017 for "poor performance and toxic behavior", though it would seem that she was actually fired for not keeping quiet about the abuse she had experienced while working there. She now works on AI policy and talks in the book specifically about AI-powered weapons (a terrifying thought), so it seems like her experience at Facebook hasn’t put her off trying to do good in the world.

The TL;DR

NOTE: This section contains spoilers, so don’t read it if that bothers you!

Wynn-Williams’ firsthand account of her journey at Facebook is wild. Even the way she was hired was out of the ordinary - she just decided she really wanted to work there as a “diplomat” because “Facebook is this global political force that is going to change the internet and the world, and these things matter” and just kept pitching them a role that didn’t exist yet until they gave in and hired her. Her initial enthusiasm and optimism really shines through on the page - you don’t just keep trying to get a non-existent job for over a year unless you’re really fired up about the idea and initially, it seems like she might actually be able to make a difference.

Unfortunately, all is not as it seems at Facebook and Wynn-Williams quickly discovers that she is surrounded not by benevolent do-gooders, but business folks who just want to make money. The company’s main priority is growth, not changing the world for the better, and this results in some pretty shady dealings. Facebook actively courts China, breaking its own well-established rules to try and get the government to allow the Chinese people to access the app, which understandably makes Wynn-Williams uncomfortable but her bosses imply she’s strange for not wanting this. Facebook choose to overlook a lot of fake news and hate speech that incites violence and sways elections in various countries - when it comes to content, they simply choose to look the other way as long as they get to make plenty of money. As the book goes on, Facebook becomes more and more politically powerful, which is exactly what Wynn-Williams foresaw, except I’m betting she didn’t think they’d land on the side they did.

There are some accounts of awful behaviour and gaffs from Mark Zuckerberg that are very cringy to read. He comes across as a spoilt nerdy child who just does what he wants and expects to get away with it. He holds up presidents from countries like Brazil and Colombia for ridiculous reasons like refusing to meet with anyone before 12pm. Understandably, these people do not react positively to being messed around and Facebook often doesn’t get its way just because Zuckerberg refuses to give an inch. Maybe that’s a good thing, who knows - perhaps they would have even more power now if he’d had a spare pair of trousers.

Sheryl Sandberg doesn’t come across well either - she is prone to critical outbursts and abuses of power. In her book Lean In, Sandberg says it’s very tough to be a woman in business and yet goes on to use her own female staff members at Facebook to promote her book for free. And then there’s the shocking story of a heavily pregnant Wynn-Williams being told to “come to bed” by Sandberg on a long haul flight, as if it’s the most natural thing in the world. Wynn-Williams is obviously uncomfortable and refuses, so Sandberg ices her out as punishment.

Initially, Wynn-Williams is keen and willing to get stuck in and embrace the American work culture - i.e. work every hour available - but as the book goes on she starts to question things a bit more, especially as her husband gets wind of some of the ridiculous things she is being asked to do. Facebook has her fly out to remote and dangerous countries to go talk to government officials, just because they are afraid of being blocked and losing users. She has a difficult second pregnancy and nobody at Facebook cares - they’re getting her to work during maternity leave while she is haemorrhaging and they tell her she wasn’t available enough upon her return, which is unsurprising given she was in a coma for part of it!

By far the worst account is of her manager, Joel Kaplan, who starts off with some uncomfortable questions that could be dismissed as oddness, but there is a consistent pattern and it makes Wynn-Williams uncomfortable, so she threatens to report him. She gets told that if she keeps quiet, the behaviour will stop. Clearly, this doesn’t work because at a company party, his behaviour escalates and culminates in lewd comments and non-consensual grinding on the dance floor. Realising that things will never stop and only get worse from here, Wynn-Williams reports this to HR and promptly gets fired. She is told that there is no proof of anything she is reporting and that Kaplan has done nothing wrong. Sadly, this is not uncommon for women who report sexual abuse in the workplace.

So yes, you can see why Facebook might want to cover this up. I for one am glad that the publisher decided to go ahead and release the book anyway.

My thoughts

This book is shocking. Some of it I knew - like Facebook’s main aim being exponential growth - but I didn’t quite appreciate at what cost. A long chapter near the end of the book goes into how Facebook was instrumental in the unrest in Myanmar and how little leadership did to help, which was quite honestly shocking to me. How any company can ignore the fact that their product is actively causing violence is beyond me, but that appears to be where we’re at. The internet has gone from being a place for slightly nerdy outsiders to hang out to a dark place that shifts power dynamics and causes chaos all in the name of the mighty dollar.

Facebook isn’t the only company doing this - Big Tech in general has gone worryingly dark and appears to be experiencing a bit of a backlash as a result. This book along with Enshittification by Cory Doctorow are both worth a read. They will quickly disabuse you of any remaining notions that these companies are benevolent and have our best interests at heart. Big Tech is fuelled by capitalism taken to the absolute limit and takes the phrase “move fast and break things” to the extreme. There is rampant toxicity, egoism and enablement of bad behaviour going on behind closed doors and it’s so important for stories like this to get out. Something needs to change and awareness is the first step.

My rating

★★★★★★★☆☆☆

I would give this book a 7 out of 10 - it’s a well written, compelling story that will leave you shocked and appalled. If you want to anger up your blood and despair at humanity, this is a good book for that. In spite of its dark content, I would highly recommend you give it a read. Though I do need to go read a cosy fantasy novel now…

Reserve Careless People from your local library like me, or you can buy it from bookshop.org or your local bookseller. It is also available digitally on Kobo and you can even listen to it read out by the author on libro.fm. I don’t use Amazon so will not post links to it here, though I’m sure they sell it too.

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!

This will be my last weekly roundup this year, so I hope you have had a fabulous 2025 and are excited about what next year will bring. Have an amazing festive break and see you soon!

Covid can do one

I’ve been unwell with Covid for the last week and a half and let me tell you, it has been rough. The new variants (stratus and nimbus apparently) both feature “razorblade throat” as a symptom and I can confirm that it is horrendous. It’s amazing how much I take for granted that I can swallow without pain and how quickly this thing took that notion away from me! I spent just over a week not being able to do much more than nap and watch TV and even now, though I feel about 95% better, I still feel exhausted and am prone to coughing fits when I exert myself too much.

The most ridiculous thing about all of this is that I had the Covid (and flu!) jab back in October and it still didn’t stop me from getting infected. I guess it just shows that you can do everything right and still end up being struck down by some pesky little virus. It’s so very easy to forget that Covid exists now that the lockdowns are behind us and things are sort of “normal”, but it is definitely still out there.

I did spend the week before I got ill doing a lot of stuff - I went to a tech meetup, two gigs and was out and about a lot besides that - but I don’t think stopping all of that is the solution either. It is extremely frustrating that I’ve had to take over a week out of work and have been unable to do much to keep my spirits up, but I’m not about to go back to being scared of everything and wearing masks whenever I go out.

What I will do is make sure that I always have lateral flow tests in the house and if I notice that I’m getting cold/flu type symptoms, I will test myself. I will also be sure to keep standard cold and flu medicines around so if I do get sick, I’m prepared. Something that really helped me this time was having lots of nutritious frozen meals around - a side effect of cooking more meals from scratch and not being able to finish them all, but it felt so good to just heat up some soup made from the organic tomatoes my friends and I grew over the summer.

I don’t know where I’m going with this, except that Covid sucks, I’m not going to let it scare me off and I looked after myself pretty well if I say so myself. The only thing that I have found tricky is knowing when to come back to work - I started work again yesterday and even though I felt ready in the morning, I found myself floundering by the afternoon. It’s a judgment call we all have to make I suppose, and it’s not always easy to get right, but I was so darn bored of lying on the couch watching TV and I’m excited about my new job, so I can’t be blamed for going back a little earlier than I perhaps should have.

I suppose that leads me quite nicely on to some musings about this year…

Thoughts about 2025

This year has been full of change for me on a professional level. I started this year at the Economist, where I’d been since 2020, but on a completely new team to the one I’d been a part of for the preceding 4 years. It’s easy to underestimate how big a change switching teams can be - my new teammates were (are!) extremely lovely, which did really help, but ultimately I found it quite stressful moving from a spot in the company where I knew the codebase and domain inside out and I was the “go to” person to effectively being a newbie again.

I put myself under a lot of pressure to know everything immediately, which didn’t help - musing on this now, I wonder how much the title Staff Engineer contributed to that. I felt like people were looking at me going “they must know everything” and that I had to embody that. The thing is, I was actively trying to dismantle that image by asking the “stupid” and “silly” questions and by telling people I didn’t know everything, but it never really stuck somehow. I am still figuring out how I can stop this from happening in future and it’s got me stumped. I’d love to hear from other engineers who have felt like this and what you did to combat it. Maybe this is just too much a part of my personality and this is something I’m going to find difficult to change, who knows.

Related to that, I also put myself under lots of pressure to keep the engineering initiatives I’d started as a Senior going, even though I had far less spare time - I would run bi-weekly lean coffee chats for engineers to have a catch up and somewhere to go to ask questions, I was running the Front End Community of Practice with my colleague (still so proud of us Matt, if you’re reading this!) and I was mentoring several colleagues and running various other catch up sessions during the week on top of all of that. I find all of these things extremely valuable and I was struggling to see how I could possibly drop any of them.

In hindsight, I can see how much of the pressure I felt was self-induced, but I honestly felt like if I didn’t carry on with those initiatives, nobody else would take them on and that it would be a great loss for the other engineers. It felt like I’d be a bad leader if I didn’t continue, I suppose. The eye opener for me has been that I have left now and as far as I know, the department hasn’t collapsed, so there was absolutely no need for me to keep all of these plates spinning single-handedly.

That was the other big change for me - after nearly five years at The Economist, I felt like it was time to move on and I spent a fair bit of time this year job hunting. I eventually decided that I wanted to take a step back down to Senior Engineer because it was the last time I remembered really enjoying my job and I was hoping it would result in a reduction in the relentless pressure I was feeling. I started at Octopus Energy in August as a Senior Front End Engineer and it has been absolutely wonderful.

I am loving being closer to the code again and have had some fairly big realisations about myself - how I’m just a JavaScript developer trying to write TypeScript (getting better all the time!), how I wasn’t as good at Playwright as I thought (again, fast catching up here), that AI is actually kind of useful and experimentation and “playing” with it is better than trying to use it under pressure and that I might be more of an extrovert than I first thought because I miss going into the office. I am very fortunate to have gone from one very lovely team to another very lovely team, but I do feel like it’s so much easier to get to know people and feel connected in real life than over Slack. In the new year I’m going to try going into the office twice a month. Hopefully that will help.

Anyway, I am a complete newbie once again, getting to know the ins and outs of a new domain and a new set of codebases, but somehow it feels more acceptable now. Is that because I’m a new starter? Or because of the title change? Who knows! I do know that I am extremely excited to get stuck in and get to know everything about the projects I’m working on and the domain we’re working in and to become that “go to” person I was again. There’s something extremely satisfying about being able to answer pretty much any question thrown at you. Though that one might just be me!

Plans for 2026

I am very hopeful for 2026 and have lots of professional as well as personal plans. I will definitely be updating my blog more often as I have been doing lately - I enjoy writing and it’s something I don’t get to do as much in my new job as I did previously, so it’s nice to have an outlet for it.

I haven’t passed my probation in my new job yet so that will be the first hurdle to overcome, though I am hopeful that won’t be an issue. It certainly feels like things are going well. I’m also planning to do some more talks at work and to start helping my team with some big ongoing migration efforts. I haven’t been able to help as much as I’d like so far, just because I’m still getting settled, I’ve been working on other things and I don’t have as much context as some of my teammates. I love a good migration though, so can’t wait to get stuck in.

I’d really like to do a talk at a meetup at some point this year, though I find this extremely scary, so I don’t know how successful I will be at it. Somehow, doing a very targeted talk at work to an audience I know are going to be receptive is a lot less terrifying than submitting a talk to a meetup, where the audience is broader and might not be so interested in what I have to say. Anyway, I shall think about it and see if I can’t find a way to make this happen this year. Ultimately, I’d like to speak at conferences, but baby steps…

Personally, I am planning to grow many crops at the allotment, make lots of new garments for me to wear and read a tonne of books. So the usual for me then! I can’t wait :)