Reflect on your mistakes

Dear new developer,

This post called “Leveling Up Skill #10: Reflecting on Mistakes “, part of a series on leveling up as a programmer, provides a good solid process for reflecting on, learning from, and moving past mistakes.

I liked two parts of this in particular. The calling out of the “it’s ok to make mistakes” trope:

Before we do, though, let’s address one more thing: senior developers from privileged groups talk about this a lot already. “It’s OK to make mistakes!” “You should make mistakes!”

I cannot recommend making mistakes like that.

Maybe some mistakes have more benefits than drawbacks for the senior guy who is already reputed to be technically competent.

For a junior person, or for an engineer from an underrepresented group whose authority and ability are constantly questioned and downplayed throughout their career, screwups are costlier because they feed other peoples’ confirmation bias. “Oh, yeah, she’s hit or miss. Really botched that database refresh last quarter.”

This is part of the reason I recommend overindexing when you start out. But she raises some really good points about the difficulties folks who are not senior white guys have with making mistakes.

The other part of this post that is really solid is the four steps to process the mistake and incorporate it. I won’t name the steps, go read the article! But suffice it to say that mistakes are part of life, just try to make new ones.



Get used to failure

Dear new developer,

I was chatting with someone I met at a meetup who was about to graduate from a bootcamp. I asked him what his advice to a new developer would be. He said that it would be “get used to failure, and get used to working through it.”

I thought that advice was great.

I often tell colleagues that “if it is easy, someone would have already automated it”. This means that when you are working on a software problem, the problem by definition hasn’t been solved within your organization (that you know of; I’ll come back to that). This means that you’ll most often be failing. Just like scientists who try to narrow down their scope of inquiry so they can have useful experiments, you’ll try to narrow down the problem and pattern match and research so that you can have a working solution. But just like the best planned experiments fail, so will you, often.

There are two additional complexities that software developers have that scientists do not.

The tools that software developers use are themselves software and are being developed. Imagine trying to build a house when the hammers and saws that you are using are themselves changing at a rapid pace. This means that the solution that may have worked in the past is suboptimal.

And the real world that scientists operate on and try to understand doesn’t often change daily. The business world that software developers operate on and try to understand can change on the whim of a person in authority. This is an essential complexity of software development.

This experience requires you to get used to failure, both at the micro and macro levels. And to keep going. You just need to be tenacious and realize that you’ll solve the problem. Also, recognize the frustration and realize that everyone is going through it. A coach once taught me that running is hard for everyone, whether you are running a 5 minute mile or a 10 minute mile. The same is true for development. Learning something new is difficult and frustrating, whether it’s your first programming language or the intricacies of a build and deployment process that is new to you.

Get used to failure and remember that everyone else encounters it.

I mentioned I’d return the caveat that problems you tackle haven’t been solved “that you know of”. Back in the dark ages before the internet was widespread, distribution of software knowledge was slow and driven by email, bulletin boards, journals and books. Now we have google and stack overflow. This helps with coming up to speed on external software that will help you solve problems. I’ve yet to see an internal system that works well for sharing knowledge, but it is incumbent on you and your teams to search out solutions within your organization.

Once you have a problem defined (even partially), resist the temptation to dive in and start building a solution. Rather, pop your head up and ask around and see if anyone has solved your problem. Or even one third of it. You may or may not re-use their solution, but it will inform your solution even if you don’t.



Making mistakes is OK

Dear new developer,

One time, not too many years ago, I was using git. I had used it for some personal projects, but hadn’t used it in the team setting before. We were using this git branching model. I was creating feature branches and working on them.

However, often I would be working on the same feature branch as a colleague. The first couple of times I was doing that, I used ‘git checkout -b <branchname>’ to checkout the branch. I’d then pull down the remote branch ‘git pull origin <branchname>’ and work on it.

Do not do this. Doing this will checkout a branch named <branchname> but it will be off whatever branch you were previously on. The pull will then merge the remote code. So you’ll get the code you want to work on, but there will be other code lurking. No good!

Instead, run ‘git fetch origin<branchname>’ and then ‘git checkout <branchname>’.

I point this out not because I’m trying to teach you version control (though you should learn it).

I point it out because this was a mistake. I don’t think any code escaped into production, but it definitely confused some team members and could have been very bad. It’s one of many many mistakes I’ve made in my career.

Mistakes happen to everyone. It’s important to learn how to handle them.

First, find out what the mistake was. You need to have an understanding of the mistake so you can avoid repeating it. This may be a conversation with another team member, research, or both.

Second, acknowledge that you made the mistake. If you work in an environment where you cannot acknowledge errors, make plans to leave as soon as possible. You don’t have to wail and beat yourself up, but just saying “oh, wow, I really screwed up that git branch stuff. Sorry!” is going to let people know that you made a mistake and that you are adult enough to know it.

Third, clean up your mistake. You may need some help doing so, but part of taking responsibility for your mistakes is fixing them as best as you can.

Fourth, avoid making the same mistake again. This may involve keeping a notebook, a writing a blog post, or just committing the correct solution to memory (this depends on the scale of the mistake). Bonus points if you do this in such a way that other folks, either internal (wiki page, slack message) or external (blog post, stack overflow question and answer) can benefit from your mistake.

Mistakes happen. It’s OK. Don’t pretend you don’t make mistakes, own up to them, and try to make new ones rather than repeating.



Don’t make the same mistake twice

Dear new developer,

“To err is human”. We all make mistakes.

A few years ago I was working on a contracting project with a new version control system. I didn’t take the time to understand all of the commands, but just dove in and started writing code. A few days in, my branch was weird and was missing some code present in a co-worker’s branch.

Turns out I’d been pulling down remote branches incorrectly and creating new branches instead. Whoops!

I made that mistake once, and never again. I corrected that mistake at two levels. First I learned the correct command. Second I learned that a version control system is worth spending some time getting to know. I invested some time learning about this system and how to perform common operations.

Ways you can avoid repeat mistakes:

  • when you make a mistake, make sure you understand what the mistake was
  • find out if there was a second or third level of the mistake, as I did above
  • write down your mistake, either publicly or privately, so that you and others can avoid it in the future

Mistakes happen, no one is perfect. But the goal is to always make new mistakes, not the same mistake again and again.