I came to unit testing relatively late in life. When I’d written my first unit test, I was over ten years into my career. I’d been aware of unit testing for several of those years, but I just couldn’t see the point of them.

When I wrote that test, I accepted that I barely knew what I was doing. “Ok”, I thought, “I just need to test the code for any kind of input it could get.” Which isn’t a bad way to do it, but maybe not the way I’d think about it today. Eventually, I got that test to work, and a bunch more.

I already had a CTO title by that time, and I felt intimidated. I’d spent most of my career thinking that other people might need tests, but not us, not me. Getting to a scale in the business where we needed more confidence in our code, and seeing how much of an impact a bug could have, really changed how I felt about testing. But I couldn’t escape a feeling of embarrassment at having gone so far into my career without doing something as elementary as writing a unit test.

When you hit a certain point in engineering leadership, you do run into technology that you haven’t personally used. Maybe you have written All the Objective C, but Not So Much of the Swift. Maybe you have many memories of writing Chef or Puppet, but you’ve barely touched the Terraform and ECS or Kubernetes that your team leans on these days. If you are a leader, you might not have any good reason to be writing any of that code yourself.

But don’t despair. If it makes it easier, I give you permission to try all of that code out on your own time, to build little bits of architecture in AWS or GCP, to write a tiny calculator in Swift. I give you permission to write as many bad unit tests as you want, as long as you question them, and commit to writing better tests later. None of the things you do in this vein have to be, you know, part of your legacy; experimentation has its value, and it’s ok to be vulnerable, and try that thing that’s new to you, even if you are a Senior/Staff/Director of Things.

Of course, it’s not my place to give you permission. But sometimes, we build walls: “I don’t write code anymore, so I can’t try this technology out.” But writing code is fun, and that’s why you got started on this journey in the first place! “If I write a unit test, it’ll be bad.” Maybe, but failure’s the only mode that allows growth, isn’t it? And don’t you want to grow and learn new stuff?