Fear of Failure is Crippling Software Devs. Here is What to Do.
Once, way back when I was a naive software developer. I made a commit without testing the code properly.
I felt it. Those sweats you get after doing something that you shouldn’t have. I panicked as I couldn’t remember the changes that I’d made.
“I know, I know. A JUNIOR MISTAKE.
That isn’t what we are talking about here.
We are talking about the REACTION to the problem.”
My Situation
“I rushed to rewrite sections of code just to get back to where I was at the beginning of the day. I powered through the night to make it look like I could be the competent developer I so desperately wanted to be.
I felt that I needed to rewrite my code. Late night or two? I felt I needed to do this to hide my failure and keep my job.”
What I should have done
“In this particular case because I didn’t know better, but because I didn’t realize Git could help me out. There is even a website that tells you what to do in that situation — https://dangitgit.com.
When you come into the industry, you’re going to make mistakes, but the learning does not have to be this stressful.
If I didn’t know about the command or how to find it I should have asked someone else.
I needed to make the initial mistake, but what would be important would be learning from it.”
Let’s explore strategies to handle such mistakes, and how to get the most out of them and get the golden learnings as quickly as possible.
Stage 1: The Mistake
You’ll realize that you’ve messed up through a pulsating pain behind your eyes. Many will sweat profusely. Your heart will beat faster than you’d really like.
It doesn’t help.
“I’m hesitating to say it. You need to stop this type of behavior.
The file is still deleted / the compilation error is still there / the bug seems unrecoverable / the machine won’t start / it just won’t work.
You need to breathe deeply take a step back and think about the situation.
Acting rashly can make things worse or leave you spending hours trying to fix a problem that isn’t broken.
Even in the most toxic jobs, people are seldom fired over a single mistake. People have bad days. Your manager will be used to things not working, and developers breaking things.”
The strategy: take a step back and think about the best way to solve the issue you’ve encountered.
You might notice that this is the problem-solving strategy for your job as a developer anyway. You really need to take the emotion out of the situation and not jump to blame yourself for the situation so you can make progress on the problem.
Stage 2: Break Down the Problem
Breaking down a problem into its constituent parts is a fantastic problem-solving strategy.
“This isn’t just about debugging your awful code by the way. However, if you are debugging you should find the root cause of why it has gone wrong. We can take that learning into our lives as a whole too!
If the underlying cause is insufficiently tested code (Test Driven Development — often known as TDD) can help you crystallize what needs to be done in terms of testing. Add this to sufficient unit testing and you’ll have gone some way to breaking down problems to actually know where to look for bugs. So we can change the TECHNIQUE used for breaking down problems.
Always remember that debugging is only one tool in your arsenal. Lots of coding is about understanding your IDE and getting your configuration right.
The alternative? Ask lots of questions. Get a mentor. Co-opt ChatGPT to help you learn. Do everything you can to get the knowledge you need to move forward in your career.”
The strategy: break down problems to solve them. In programming use tools and TDD to get rid of pesky bugs.
Stage 3: Communication
“Sometimes the problem isn’t even your fault. I tried to push my code to the pipeline this week, and it didn’t work. Why? The slave was offline.
How would I ever know? I don’t have an interest in the CI beyond code. I don’t have log access.
You already know what I needed to do. Ask the right person the right questions.
When you’ve a doubt someone somewhere in your organization has probably seen the problem before. Look at the bigger picture and by that I mean accept that you are part of a team and knowledge is shared.
Share, share share. Tools, techniques tips and anything you can get your hands on.
If you’re the only dev in your org get involved in groups. Meetups. X stuff (feels weird calling it that). Get Github Copilot / ChatGPT involved. Use rubber duck debugging”
The strategy: Engaging people in both your opportunities and problems can provide guidance and stop you from repeating the same problem over and over. Building relationships with people isn’t wasted time but can help keep you focused and moving forward through not just the current problem but your whole career.
Stage 4: Clarity of Thought
“When you’re typing code, you may think that you don’t make mistakes.
As you grow in experience, you think that by using a linter you can be assisted to write clean and readable code. However, your code may not be logical and clean. To do so you need clarity of thought.
Clarity of thought and code is essential while writing code, and might well need a pen and paper which you use to plan out your code before putting your fingers on the keyboard. From planning out a strategy to solve a problem through choosing appropriate variable names to everything you do should lead you to your goal. That goal should be solving a problem in a maintainable way that can be changed in the future.”
The strategy: Plan your work carefully with the future in mind.
Stage 5: Knowing Oneself
“Your logical fallacies will keep coming up. You’ll need to do the following (wait for it)…
Improve.
After you’ve done that, you will also need to (wait for it).
Improve.
To do so you need to keep working. Don’t give up. Aim at the prize and keep going. If you want to get a FAANG job crush those Leetcode problems.”
The strategy: If you want to git gud, get good. Practice work and study. It’s the only way.
Conclusion
Failure is the first step to success. Learning from our failures gives us a real-life basis from which to grow and improve.
In the end, it is this pattern of learning and improving that we should focus on rather than individual programming skills themselves as it is transferable between jobs and even through different non-working contexts.