You’re going to put some plates in toasters

Dear new developer,

I saw this insightful tweet:

The whole thread is worth reading, but you get the basic idea. Sometimes you don’t know what you don’t know.

When I think back over the years, I am amazed at how many things I can do without thinking now that would have been baffling to me at the beginning of my career, including technical and non technical knowledge). This list includes:

  • navigate files and directories work
  • examine an HTTP call
  • determine the performance characteristics of an application
  • refactor an application
  • architect a large application
  • run a meeting
  • plan a project
  • exit vi

The road is long. And I still put plates in toasters periodically.

Recently at work, I energetically revised a planning document, adding what I thought was a ton of insight and value. Later I found out that the value I added was actually negative and that I’d done more harm than good to the organization’s goals when adding my thoughts. Man, was that a humbling and learning experience. Actually, that was more like putting a fork in a electrical socket than putting a plate in a toaster.

Much of what I know is at a high level with the idea that I can dive in (using resources like Google or Stackoverflow or a mentor) if I determine a need. Just knowing that something exists means that I can leverage all the great learning resources available if I see a place where it might appy. I also do a lot of pattern matching, where I compare how one system or process worked and see if and how that knowledge applies to a new problem.

So when you find yourself floundering, take a deep breath, forgive yourself, and dig in to learn. Foundational competence is something that you will acquire with time and study. But until you do, you’ll be putting plates in toasters.



Mistakes Are Forgiven, Hiding Them Is Not

Dear new developer,

We all make mistakes. Yes, this is not news, but it’s worth repeating.

We all make mistakes.

I have made them, you have made them, your boss has made them, the person you are interviewing with for the job you really really want and need has made them.

The one thing about mistakes is: never never hide them.

Now, that doesn’t mean you should hang every mistake out on your blog or your LinkedIn profile. Just because we all should tell the truth doesn’t mean you should say every sentence you think.

But the people who need to know about your mistake should. Who needs to know depends on the scale and scope of your mistake. If in doubt about who needs to know in a professional setting, ask your mentor, your immediate supervisor or a trusted team mate.

Don’t take your time to do this. When you discover a mistake, you should immediately do the following:

  1. Confirm it is really a mistake. You don’t want to be the boy who cried wolf. So avoid making a mistake about a mistake. Take a look at the mistake from several different perspectives.
  2. Think of a plan for fixing the mistake. This may entail bringing in other team members, depending on the severity of the mistake. It may entail shutting some things down so a mistake doesn’t get worse. There may be an immediate plan to fix the emergency and a longer term plan to prevent the emergency from happening again (perhaps using an automated test).
  3. Think about who is affected and the scope of the impact.

Finally, tell who is affected about the issue and the plan to fix it. This may in itself require some planning.

It’s very uncomfortable. When I was at a startup and was writing billing software for clients, there were times when I made a mistake. I remember one time when I had to email or call each customer whose billing I had screwed up. It sucked. But they understood and appreciated the transparency and honesty.

What is the alternative? Hiding your mistakes and pretending they never happened? This means that you don’t get to learn from them. Your users or boss may discover the mistake on their own and bring it to your attention in a far more unpleasant manner.

Making mistakes is fine (though try to not to make the same mistake twice). Hiding them is not.



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 to 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.