Fearless Development

Most developers feel some level of fear in our day-to-day jobs. Fear of breaking stuff. Fear of not knowing things. Fear of our work being judged by our peers.

Sometimes fear is a good thing; it stops us from being reckless and causing problems for our customers or regulators. We're handling people's money after all, and getting that right must always be our top priority.

Other times fear is a bad thing because it can paralyze; it can cause teams to hide behind process as a subconscious excuse to not ship in the face of uncertainty.

But uncertainty is an inherent part of software development. After all, if a task were certain, someone else would have already written the software to do it and there would be nothing left for us to develop.

This means the fears won't go away anytime soon. I've been a developer for close to 20 years and I still contend with all these fears on a regular basis. I don't have a one-size-fits-all solution, but I thought I would share some techniques that have helped me face, manage, and overcome these fears.

Reversible and Irreversible Decisions

The life of a developer is full of choices. These choices must, due to time and resource constraints, be taken with incomplete information. This by itself is exhausting and paralyzing. The fear of making a “wrong” decision is very real.

One framework I use to help with this involves the idea of reversible and irreversible decisions.

A reversible decision is one where it’s cheap to change your mind afterwards. Should I wear a blue or green shirt? Oops spilled coffee on the blue shirt. I’ll wear the green one instead. Should I call this variable ‘foo’ or ‘bar’? Foo. No, bar.

Cost: 1 brain cell, no big deal.

An irreversible decision is one where it’s either impossible or prohibitively expensive to reverse it.

It follows then that these are the decisions you do need to take a lot of care around deciding because once you start, you’re committed.

Here’s the good news: most day-to-day decisions are easily reversible. The irreversible ones come up pretty seldom. The key here is to get good at recognizing the difference, and then just not spend brain cells on the reversible ones. But how do you tell the difference, in practice? With another technique:

Think About Rollback Ahead of Time

A rollback plan is how you will reverse a decision if it goes sideways. I’m not talking about a document or anything; just have an idea in your head about what you’ll do if a choice doesn’t work out.

If a rollback plan is easy to imagine and would be uncomplicated to execute, congratulations. You have a reversible decision on your hands. If the rollback plan is either hard to identify or would take a lot of effort to actually do, then you’re facing an irreversible decision and you need to take more care.

They also give you the confidence that you know what to do if things go sideways unexpectedly. This confidence will limit your fear.

Timeboxing

You know that feeling where you’re, like, 75% sure you know a better way to do something? But you don’t want to commit a lot of effort until you’ve ironed out the other 25% of your uncertainty? Embarking on a big refactor is a common example of this. Refactors have a way of spiralling out of control only to maybe not achieve what you thought. We’ve all been there.

One way to mitigate this uncertainty is called time boxing. You clear your schedule for an afternoon, or a day, and you say “I’m going to give it my best shot in this amount of time.” If you get it working, fantastic. If you don’t, you delete it and work on something else tomorrow. This puts a predictable upper bound on the cost of something uncertain. Even if you’re wrong, or the refactor goes sideways, you have wasted, at most, the length of your chosen time box.

Understanding the worst case scenario like this brings confidence, the opposite of fear.

Move Fast and Fix Things…

This is an evolution of Facebook’s notorious “move fast and break things.” But in a nutshell, make small changes, and watch them go out the door. This limits uncertainty, and it limits the splash damage if you make a mistake. No matter how careful we are, sometimes things get through. As long as you notice and fix it quickly, you’re gonna be OK.

I use this philosophy a lot when I deploy changes. At Wealthsimple, we embrace a Continuous Deployment philosophy for most of our systems. This is based on the premise that shortening the amount of time between when a developer makes and when a bug is found makes the bugs cheaper and easier to fix.

…but watch changes go out the door

But by itself, this isn’t enough. It’s also important to monitor your changes as they land in production. When I make changes to production systems, I typically:

If I broke something, I see it immediately and hit the rollback button.

To summarize, you can ease the fear of breaking prod by:

Practice

Sometimes things do go wrong. Sometimes PagerDuty goes off and you get pulled into an incident channel. This is a high stress situation and a big fear for a lot of people — getting paged for an incident. Even now, every time I'm paged, I have a feeling of adrenaline/mild panic. The only real cure for this one is practice.

Wealthsimple strives to provide a supportive, non-judgemental environment, but then people need to just do it. I’ve been responding to pages for years now and it does get easier with practice.

Focus on What You Can Control

It’s good to think about these things and surface this feedback—this is one of the ways we improve as a company. But at the same time, not everyone has to fix everything. As developers our mandate is clear: build stuff, operate stuff, and fix bugs. This is the lever that we can move that no-one else can move. It’s OK to focus on it. If the other problems become existential, one of the other 1200 people will pick it up. In many cases that someone will be more qualified in that specific area anyway.

Cut Yourself Some Slack

At the end of the day, it’s ok to be worried, it’s a sign that you care about what you’re doing. But it’s also OK to cut yourself some slack. While it may feel like everyone else knows more than you, the reality is we don’t. We all have gaps in our knowledge.

Sometimes people will comment on your PRs and it will feel personal. Code does get reviewed, and judged. But it’s about the code, not the person. And often a reviewer’s point of view is just as subjective as the choices made by the author.

At the end of the day we’re all the sum of the things we’ve learned by building stuff, watching stuff, and fixing bugs.

...

Written by Seth Davenport, Principal Software Developer

Interested in working at Wealthsimple? Check out the open roles on our team today.