developer

Talitha Kruger: You don’t need to be a natural problem solver to become a developer

During the early stages of learning to code and becoming a developer, I worried that I was not a “natural problem-solver”. In my eyes, developers were defined by this trait: they were people with a superhuman ability to solve incredibly hard problems quickly and under pressure, and I subconsciously disqualified myself from being “a good developer” because I didn’t see myself as having that characteristic.

But just because I’m not a natural problem solver, it doesn’t mean I haven’t been able to solve problems I would have once thought impossible. And so I wanted to share what helped me to improve my areas of weakness so that I could better assess and understand problems, and figure out working solutions to these challenges. Here are some key points that I learned along the way:

Problem-solving is not a Genetic Trait

Problem solving isn’t something that some developers have, and others don’t. It is a skill that is acquired with perseverance and practice. You will make mistakes, but you shouldn’t let that damage your self-esteem or discourage you from trying. Try to think of challenging problems as opportunities that can make you a better developer.

Never give up (as cliche as that sounds)

When learning to code, approaching problems in a particular programming language can be very frustrating. Getting stuck and breaking your code doesn’t mean that you are bad at that language or a bad developer; you just don’t know how to fix it yet.

One thing at a time

Take it slow, line by line, bit by bit. Rather write a few lines that work and build on them bit by bit, than churn out an entire function that doesn’t work. Breaking the problem up into pieces and tackling one at a time is cliche for a reason: it works.

Practice makes perfect

Embrace the fact that problems are a part of development, and that the problems themselves do not get easier to solve – the problem-solver just becomes better at solving them. The only way to strengthen a muscle is to use it, so I highly recommend sites like Leetcode and HackerRank to start practicing your problem solving and also prepare you for coding interviews.

Dear Dev Diary…

Journalling the issues and errors I was faced with, and how I solved them not only gave me something to refer to when similar errors came up further along the way, but it also gave me a huge sense of achievement. Keep a track of how you solved a problem; it’ll give a good point of reference down the line – and also remind you that you’ve come up with clever solutions to coding challenges before.

Always take your best shot at solving the problem before you ‘cheat’

Looking up your errors on Google can be a quick fix, but it can only benefit you if you first give yourself some time to try and troubleshoot the error on your own. Don’ be afraid to make a mistake, because it means you’re engaging directly with the problem. The code you write might not be the cleanest or most optimized, but you’ll learn to solve problems on your own. Besides, you can always ‘cheat’ later on when you refer to resources such as StackOverflow to see best practices.

Never underestimate the power of a break.

Taking a step away from the problem will let you come back to it with a fresh perspective. Next time you are stuck, take a quick walk, read a blog post, or watch a short Youtube video (as long as your break doesn’t turn into an elongated distraction).

For a long time, I couldn’t identify with developers who were excited to take on extremely difficult coding challenges; in fact, just the idea made me extremely anxious. But the reason for this was that I had little practice and a lot of self-doubt, not because I wasn’t a “good problem-solver”. I am still learning to embrace the errors and unwanted behaviour in my code, I have to consciously choose how I approach problems. Since I have done so (especially after listening to this enlightening podcast called “Fail Better” by Command Line Heroes), there has been a lot less frustration, and more freedom in my work. I encourage you to choose to embrace when your code fails: every error will become an experience, and every problem will become an opportunity.



Talitha Kruger is a graduate of the HyperionDev Full Stack Web Developer bootcamp. She completed a part-time bootcamp, and was featured in a HyperionDev student spotlight. She is also a past contributor to the blog, and has recently shared the highs and lows of her coding journey with students starting their path in tech.

If you want to learn how you can start the journey into your new career in tech, you should look into our specialised bootcamp programs that give you the industry skills in Data Science, Software Engineering, or Full Stack Web Development that you need to thrive in the tech space. These part-time or full-time programs can be completed on one of our campuses in Johannesburg or Cape Town, or from the comfort of wherever you are connected to the internet. You don’t need any experience with coding, and you don’t need to be like the media stereotypes of what a ‘proper developer’ is. Why not try a free trial and see where it takes you?

Leave a Reply

Your email address will not be published. Required fields are marked *