From Non-Engineer to Junior Developer: How to Get Unstuck

If you have ever been to school, as I imagine you have, you have certainly learned a few things: some have proven useful, others have been forgotten, but a good portion has yet to be unlearned.

On a typical day, I'm visiting the search engine several times a day, I'm spending time on Stackoverflow, and I'm reading up on technical things on various blogs I happen to find. And all this serves the purpose of finding answers to the questions I ask.

I imagine this is typical for other spheres of life, too. Looking things up is by no means limited to software development. But it is indeed especially pronounced in the everyday life of an engineer.

I'm a developer and I build things. I'm creating new schemas in the database, implementing backend logic for authorized API calls, building frontend components that look and feel professional, the list goes on.

I'm not a developer because I know how to build these things without ever getting stuck. Oh no, I am stuck a lot. What makes me a working professional is the acquired ability to get unstuck.

Young developers, and by this I mean capable minds who are new to the engineering profession regardless of their actual age, usually feel inadequate when faced with challenges they haven't faced before.

"But I haven't done this before. I don't know the answer. Can't you just tell me?"

What they don't know is that seasoned developers are stuck just the same. They too don't always have the answer. In fact, finding the answer in the first place is part of their job. You may feel like you're not ready for this, but rest assured that I too felt like an imposter and I had graduated with a master's degree. Your emotional turmoil is in good company.

That turmoil will resolve in time, just not by itself. You will have to apply yourself. Do you remember the school books which had solutions in the back?

You have been taught that there is an answer, it's in the back, and don't look!

Prudent advice for a school setting, but now you are left with the consequence of having to unlearn the unhealthy mindset of:

feeling insecure about not knowing the answer.

Let's go step by step and first explore what it means to discard knowledge you acquired in the past.

Did you know that knowing nothing is better than knowing something that is wrong when it comes to learning concepts such as gravity?

Derek Muller, the YouTube creator and host of Veritasium, found that students had a difficult time learning any given physics concept when they already had an understanding of it. Why? Because their understanding, their preconception of the underlying physics, often turned out to be false.

For example, you might think that a lighter ball falls down slower than a heavier ball when thrown up in the air for juggling. But weight is irrelevant to gravity; both balls accelerate downward at the exact same rate if we ignore air friction.

If you are under the impression that there has to be a difference, if your intuition tells you that heavier things have to hit the ground earlier than lighter things, then you now know what it feels like when your knowledge stands in the way of understanding the concept.

Muller's research focused on physics education, but I think we can translate his findings to software engineering, too.

Students in Muller's thesis were disabused from their misconception by being confronted with the scientifically correct understanding of the concept of gravity. We can do the same here.

Confront your preconceptions with reality, either through experience or imagination.

Of course, nobody likes to have their views challenged; every confrontation feels like the counterintuitive example with gravity: threatening and shocking to our understanding of reality. But confrontation with physical reality is an integral part of nurturing a developer's mindset. When something contradicts what you believe, don't ignore it but examine your misconception further.

Our generic junior developer believes there's an answer which they miss when, in the everyday life of a developer, missing an answer is part of the job description. It feels highly uncomfortable, maybe even unprofessional, to not have the answer, but that's exactly what the profession entails: cultivating the ability to figure things out, preferably on your own.

Confront your beliefs, confront your preconceptions, and challenge yourself. Discarding acquired knowledge may be the best thing you can teach yourself. If you are not willing to unlearn falsely held beliefs, you are running the risk of practicing ignorance in the face of new challenges. And that's not helpful to you or the people you serve.

To come back to the juggling example, you could take any two solid objects with different weights and drop them (do it in a safe environment and watch your feet). That's an experience and a confrontation with reality. You experience the result of dropping two objects, which confronts your understanding of what's supposed to happen.

The point of this exercise, imagined or not, is to realize the disconnect between your past way of thinking and the change that is required of you. Unlearn what you know when that knowledge doesn't serve you.

And then, rediscover a new way of thinking.

You may have heard how people jokingly answer 42 when asked something they don't know the answer to. This reference comes from the science-fiction novel The Hitchhiker's Guide to the Galaxy, where the supercomputer Deep Thought answers "42" to the "Great Question of Life, the Universe and Everything".

You might be tempted to say, "well, that's not very helpful. What do I do with that answer? What's the point of 42?"

The point is that it's not about the answer at all. Like a search engine the supercomputer Deep Thought provides an answer based on the question that is asked. That question is the "Great Question of Life, the Universe and Everything".

It may be obvious, but let me be very explicit here: if you want answers, you need to ask questions. Conversely,

if you don't know the answer, the question becomes your guide to finding the answer.

Being able to ask a question requires you to think about what it is that you don't know, which in turn forces you to formulate a question that targets the very answer you seek.

Why is it that both a 5kg and a 2kg ball hit the ground at the same time? Why is this difference in weight not affected by gravity?

If you want to learn anything from this article, learn how to become aware of the things you don't know. It will become your superpower. As long as you know what you don't know, you can ask for it. If you don't know what to ask for, no fellow developer and not even Google will be able to help you.

Senior developers who do not consult some kind of resource, be it a search engine, fellow developers, or internal systems of documentation, either do not exist or they're not senior developers. The more senior you are the better you know which questions you are permitted to ask.

Deep Thought's answer is 42 because, maybe, the question does not make sense to the supercomputer. It is as if you asked how long are 5kg? If we interpret the story in that sense, then the universe is the answer to the questions we are allowed to ask, tantamount to how a senior developer knows that the answer they get depends on their ability to ask the right questions.

Finding the right questions to ask is an enormous personal achievement because it is evidence of the ability to reason within the constraints of a given domain. It shows you understand your domain and are able to make sense of it. But your ability to ask the right questions is not complete unless you own the answer too.

Rediscovery is a learning technique and mechanism for creating a personal sense of ownership.

Most of the time you are satisfied with the answer you get and you get on with your work. Sometimes however, despite having a good enough answer to work with there is this nagging feeling that you don't really understand why this answer works. These upsetting inconveniences, if used right, are the antidote for the imposter syndrome.

The difference between feeling confident and feeling like an imposter is ownership. When you don't know why an answer works you have no ownership of it, the result of which is low confidence in yourself. In order to gain confidence you need to add an element of rediscovery.

• Why does a given algorithm work?
• How is it doing what it does?
• Can I make it faster/better?

Understanding where an answer comes from creates a personal sense of ownership. By digging deeper into the foundations and building blocks of an answer you discover things anew. You rediscover new details about something you used for quite some time and now you have a more fundamental conception of it, which in turn gives you confidence.

And if you are ever put on the spot for not knowing the answer make use of your confidence and remind them of what it means to be a developer: I'm sorry, I haven't yet had the chance to encounter that problem. But if you would like me to, I could take the time and figure it out. That's what I'm here for.