The nervous hobbyist who showed up in 2021 wouldn't recognise the engineer leaving in 2026, and I think that's the best thing I can say about my time here.
I’ve written three of these retrospective posts before: one for a month; another for a year; and one last year for four.
In my last post, I talked about how to get good at failing, and ended on a line about how it’s just as important to celebrate your successes. Naturally, I then spent the better part of a year forgetting to take my own advice. It’s easy advice to give and hard advice to follow; when you’re in the thick of it every day, it’s difficult to see how far you’ve come. Writing this post was a chance for me to actually stop and look, and I’m really happy with what I found.
Five years ago, I joined VI fresh out of university with hobby projects, a degree about writing software, and no idea how software actually gets made. I didn’t know what kind of engineer I wanted to be, and I’m not sure I even knew what the options were, really. It had always just been a hobby to me—the thing I do, if only to kill time and boredom—but when it came to turning it into a career, I was pretty much clueless. One thing I did know, or at least believed I did, was that I actively disliked web development. The ecosystem felt needlessly overcomplicated, the tooling was messy, you had to learn so much, just to write websites? I couldn’t understand why anyone would choose it willingly. Hopefully you can tell, but I also came out of uni with an ego. I seem to shout it out in every one of these posts, but Kane’s blog on the dunning kruger effect really is relevant to all new developers by the sounds of it.. That took a long while to shake; thinking I’ve fully shaken it might just be me at the peak of Mt. Stupid again: I’m sure I’ll think so in another 5 years. It took me a good two years of working in the web dev ecosystem every day before I stopped being frustrated at how things were and started understanding why they were that way—why things had to be as complicated as they were.
Back then, I also had no idea that this would end up being my last retrospective here.
What turned it around for me wasn’t the technology—not at first, at least—but the people on the other end of it. I wasn’t expecting clients to be so genuinely thankful for what we built, even for work that felt quick to do from our side. It caught me off guard; I’d never been thanked for my work before joining here: I was the only audience and userbase for my hobby projects. This platform that I’d written off as overcomplicated turned out to be one that’s available to practically everyone, built by people who mostly just want to help each other out. It was complicated, sure, but I was starting to see that it’s complicated because you can solve just about any problem that can be solved with a computer using it. At some point I stopped tolerating it and started caring about it, though I couldn’t tell you exactly when that happened. These days, I’m deep enough in the weeds that I’m teaching people about new CSS techniques, contributing what I can to internal spec discussions, memorising accessibility guidelines to keep the web open to everyone, keeping up with all the new tech coming along to make things even more complicated, and hoping to start giving back to open source now that I’m moving on.
All because, while working here, I finally figured out the why of development for me. It turns out it’s less about the engineering, the code, and the tech than I expected. It turns out that I just care about making things easier for people. That’s it, really. I remember what it felt like to be brand new and terrified of looking like the weak link, so I helped introduce an easier, more visible way to ask for help within the company—to show new developers that even the people who’ve been here for years still constantly need help. I introduced new methods for keeping clients in the loop—both because surprises aren’t fun for anyone, and because non-developers should have a say in how things work too. I want to keep learning and teaching because I’ve seen what a difference it makes when someone just takes the time.
My technical skills have grown a ton, too—now all the projects I used to be so proud of for how technical the code was in uni feel naive to me. They’re not solving real problems, so what’s the point? I’ve done my best to learn how to build the MVP—cut things down to what actually matters and get it in front of people early, so that collaboration happens earlier, where the project is still more malleable to feedback and revision—while also trying to learn when to push back and make sure something’s done properly. Those two instincts are always in tension with each other, and I still think I’m far from figuring out the balance, but I’m getting there. Maintaining such a complex web of intercommunicating financial systems has also taught me an invaluable amount about architecting code—structuring how it all comes together, communicates with each other, how it can be written in a way that the people maintaining it after me can make sense of—and I think Katy Ereira’s onion monolith talk from PHP UK last year verbalised a lot of what I’d learned far better than I could in such a short aside here.
None of this felt like a journey while it was happening: it just felt like work. It’s only now, looking back at it all—submitting my first features on day two, thoroughly breaking something by week two, building safeguards, training new developers, leading the effort to modernise the mobile app—that it’s all clicking together for me. The nervous hobbyist who showed up in 2021 wouldn’t recognise the engineer leaving in 2026, and I think that’s the best thing I can say about working here.
It’s a very different world from the one I joined the company in. A little cliché, since things always change with time, but for development especially. AI is promising to reshape how we work, and it already has in some ways, and it’s easy to feel uncertain about what comes next. But if I’ve learned anything over five years, it’s that the people are still what matters—the ones building, the ones asking for help, the ones on the other end using what you’ve made. I don’t think I see that changing 5 years from now.
Or, I could be at the peak of Mt. Stupid, and the robots will have taken over, but we’ll burn that bridge once we’ve led a horse to it.
Article written by:
Allie
As a software engineer at VI, her role at the company is to learn and create quality, well-tested software.
Nothing grows your skills – or, at least, highlights where you need to grow – like failing. Early on in my career, this was a scary thing to admit.
Read more about Four Years at VI (or: how I got good at failing) - AllieWow, one year already. I’ll echo what I said in my one month post and just say that time’s flown by so quickly that it wasn’t until it was time for my yearly review that I realised just how long it’d been. So, how about I get into what made it go by so quickly?
Read more about One Year at VI - AllieIt only really feels like a few months ago that I was writing my one month with VI blog, it feels like the time has really flown. However if I think back to what's been going on over the last year and what sort of work we've been doing, I find myself simulatenously feeling like I've been here ages and also not long at all.
Read more about One Year at VI - Sophie