Four Years at VI (or: how I got good at failing) - Allie

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.

I’ve written two of these retrospective posts before: one for a month; and another for a year.

If I could go back and teach one lesson to the me that wrote those two posts over 3 years ago at this point, it would be to embrace failure. Nothing ever made by a person is ever going to be perfect, and your work certainly won’t be the first exception. You’re going to fail, sometimes spectacularly, and it won’t be the first time someone has failed. After four years, I’ve definitely accumulated experience in failing—and I’d like to say that I’m getting quite good at it. However, I don’t think it was until sometime in the last year or so that I started embracing it.

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; especially coming from higher education, where failure primarily reflects on shortcomings in discipline. Re-contextualising what failure means in a professional environment vs an educational one was a difficult process. The most challenging step of said process being to decouple these failures from bruising my ego, which was holding me back from being able to more objectively analyse and reflect on failures to devise plans to improve in the future. My colleague Kane wrote about his similar experiences on the blog here a few years back. Read as: it was time to get over myself… but I didn’t know how.

All good things come in threes, so here are the three key lessons I learnt on my path to improving:

1. Fail early.

The further you are into a project, the more you put at risk of rework when finding critical mistakes. This issue becomes multiplicative once you’ve got a whole team working on something, where suddenly you’ve got a week’s worth of work by four people built on top of assumptions that turn out to be wrong. It’s critically important to make sure that if you fail, you fail as early as possible.

Build barebones prototypes to make sure what you’re doing is possible; bring in clients early to go over the rationale behind unclear points of specification; spend time upfront working through the architecture of a solution before you go off to start implementing it. I’ve had full weeks of work that have gone unused due to not asking enough questions, or thinking critically enough through a problem before digging into the code since that’s “the fun part”, but it’s much more rewarding to be able to confidently implement something knowing that if some issue comes up late, you’re failing on a solid foundation that won’t completely crumble beneath you, minimising any rework.

Even if something only might be an issue for you later, pulling that thread early might be what completely unravels your plan.

2. Fail loudly.

Most teams that embrace agile principles will understand the importance of cultivating a blameless culture of communal learning, but it’s on you to participate in that culture. Share your failures - even the embarrassing ones you make when you haven’t had a morning coffee yet - and make sure you participate in good faith when discussing the causes and learnings that can be made from it. Especially as a newer employee in a company, this kind of vulnerability is challenging: nobody wants to feel like the anchor weighing the team down.

Internally at VI, to try and eliminate the stigma around this, we try to keep as much communication in publicly accessible slack channels as possible. This means newer developers get to see that even people with years of experience over them are still constantly unsure and reaching out for help and second opinions.

3. Don’t fail again.

The above two points are about developing the skills to create the opportunity for learning, but how do you do the learning itself? When a problem is common, or tedious in some way, it’s very easy to resign it to just being a reality of the job. The easy solution, as in many cases, should be avoided here. Is it really a necessity of the job? Is there nothing that can be done or built to avoid it happening again in the future?

For example, we work a lot with forms—using a bespoke YAML structure that gets parsed into the form that’s displayed in the browser. While this lets us build and iterate on the structure of our forms a lot quicker than writing them in code, we ran into a lot of problems with YAML itself. As a language, it’s very sensitive to small changes in indentation, spacing, spelling, and punctuation that can entirely break files if you get something wrong. A few years ago, it felt like an unavoidable reality that a bad copy+paste, or a mistakenly pressed space added late in development could go live onto our servers without being caught, and that we just had to be extra vigilant and thorough with our manual testing of these forms. The project simply had quirks, we thought, it was the way it’d always be done. It wasn’t until we started making sure we produced explicitly actionable steps when doing task post-mortems that we started coming up with solutions for the problem.

Nowadays, there’s several safeguards against accidentally deploying a form with broken markdown that are all automated, and even warn the developer as they’re editing the file.

Reflection

…And there’s my guide for how to fail really well! One last point that I’d like to make is: as valuable as it is to learn from your team’s mistakes, it’s just as important to celebrate your successes.

Here at VI, we’re always getting better at finding problems sooner, building more resilient and thorough specifications, and reviewing our standards so that we’re never just settling for what’s been good enough so far - and I don’t think we’d have ever gotten here without us all improving so much at failing over my time here.