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.

Sincerely,

Dan

Learn automated testing

Dear new developer,

If you want to build good software, learn automated testing. Depending on your platform of choice, you may have good defaults or you may need to investigate options. But I think of a test suite as a “fat suit” for your code. Sure, your code can still “fall down”. But it will hurt much less.

Automated test code is still code, and that means that it has a cost. You need to maintain it (both with infrastructure and developer time). I worked on a project once that had so many tests it felt like when you made a small change to the code, you spent most of the time updating tests. That is not optimal, and those tests could be refactored. You should count on spending some time working on your test suite, but I do feel that things that may be red flags in production code are OK with test code (just because that is supporting infrastructure).

On the project with the many tests, we knew when things broke because of all those tests. And we felt comfortable changing complicated logic knowing that edge cases were handled.

On another project I wrote a lot of tests and any time there was a bug that came in for a particularly complicated piece of code (it dealt with payments), I made sure to write a test for that bug. That’s the biggest win: tests can save you from regressions. It is not very much fun to fix a bug and have it pop back up six months down the line. Writing an automated test will keep that from happening.

Tests are also living documentation, as long as they are run regularly. (Please set up continuous integration!). They will help new developers get up to speed on a project, since the new dev can tweak something and get instant feedback (rather than having to try to find where in the user interface to go.)

It takes a while to understand the right way to test. There are books to read, and examples to follow. My experience is mostly from “on the ground”. I favor unit testing anything that is complicated to understand or may change. I favor integration testing important pieces of your application. I favor knowing what your platform provides and leveraging that. I favor using continuous integration on every branch. But I realize that every situation is different.

A special note about UX. Don’t test UX that isn’t important. And realize that UX is often a piece that breaks and is hard to test. I recommend starting with something easier, on the backend or in pure logic. Functions that do things like split up strings are a great place to start.

The most important thing is to start. If you have a project that doesn’t have any testing, make that investment and do the first test, even if it is trivial (“can I instantiate this object?”). And force yourself to write tests even when you’re slinging a lot of code. It will help future you, I promise.

Sincerely,

Dan