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.

Sincerely,

Dan