Sometimes, in a developer’s work, we get tasks that we can’t handle right away. Even more often than sometimes. When acquired knowledge isn’t enough, even though one would very much like to have all the knowledge in the world.
Unfortunately, it’s impossible to acquire knowledge at Neo’s speed from The Matrix. Even if it were possible, we would still need to choose which knowledge to invest in and which could wait. And it might still turn out that we end up with a technology we don’t yet know and need to quickly acquire some knowledge to land smoothly. Like it happened while our heroes were in a helicopter in a movie.
Such situations can evoke feelings of powerlessness and helplessness. Powerlessness – because one would like to do something quickly but can’t – a lack of sufficient knowledge stands in the way. Helplessness, in turn, kicks in when the inner critic says – but you should know this technology by now! But I don’t, because time isn’t elastic and knowledge doesn’t „upload” to mind faster than it does. Nevertheless, sometimes, when faced with a wall of ignorance, instead of rubbing my forehead, I stubbornly try to break the wall with my head.
Over time, I’ve noticed that powerlessness and helplessness are normal, and ignorance is more common than knowledge. Remaining in these states, however, hinders the search for solutions, which – in the era of rapidly developing technologies – is very important. And in many situations, it is precisely the proper search for solutions that is more important than knowing a given technology inside and out. Increasingly – it’s crucial.
When I started working in IT and could proudly call myself a junior, it seemed to me that feelings of powerlessness and helplessness were only appropriate for juniors and stemmed from a lack of knowledge. After all, knowledge is the key to all doors. And since its lack is the problem, there is a way to solve it – knowledge should be acquired in every moment free from sleep, work, and household chores.
So, podcasts, blogs, newsletters, books, and – my favorite – video courses came into play. Back then, it seemed to me that after completing a certain number of courses, finishing a bootcamp, coding daily for a year (and maybe even getting into some mentoring program), I would never hit a wall again. Never! All I had to do was learn frontend in a year, then backend in another year, cybersecurity in the following year, then tackle DevOps and LLMs, and I’d be able to handle anything. I’d be like Irena Kwiatkowska (a Polish actress known for playing a „working woman” who can handle any job):
„After all, I am a working woman, and I’m not afraid of any work!”
Over time, it turned out that I had focused on only one type of knowledge – knowledge of technology. However, there is another type – knowledge of how to solve problems. And this knowledge is much more valuable. Anyone who has tried to learn everything from courses knows that neither courses nor years of experience will help if we don’t start asking the right questions. Or if we don’t develop some system that allows us to ask those right questions.
As you can imagine, the „course craze” did not bring the expected results, except for an unexpected, yet completely understandable, increase in frustration. It took time and a bit of head-banging against the wall for me to realize that eternally acquiring knowledge for its own sake would not get me to my goal. And it certainly wouldn’t magically solve problems with writing code. Just as simply „pounding” code won’t solve them. Even pure practice, without a reasonable approach to solving programming problems, will not be sufficient.
So, what should be done to ask the right questions? A certain amount of knowledge is necessary, but often general knowledge of a given programming language or solution (architecture, methodology, library, etc.) is useful. Then, knowledge about the project in which we use these tools (language or solution) is helpful. These are the foundations that allow us to build further. Knowing where we stand, we can start practicing and using knowledge about how to find solutions.
And here, for many years, websites like Stack Overflow have been a friend to programmers, where you can either ask a question or search the database of questions and answers to find a similar problem and get inspired by a solution. Knowledge of keywords is also useful, and this comes with understanding the problem. So, if we answer the questions:
Then we can determine keywords and start looking for a solution.
Over time, by acquiring practical knowledge, it will be easier for us to formulate the problem so concisely that we can more easily find or create a solution. However, the ability to search for information is not yet something that can help us solve complex problems.
This is the moment when, without the ability to break the problem into smaller pieces, it is difficult to come up with a solution.
Sometimes it’s a matter of haste, more often a habit – we want to take a bigger step than is possible. We want to lose weight faster, handle errands in the city faster, or write code faster – just before the end of the sprint. But often it’s not possible. Many activities are composed of smaller blocks, which – until we stop and look closely – we don’t notice.
Losing weight requires a plan, time for its implementation, for travel or shopping more often than usual. A trip to the city – sometimes takes into account traffic jams, parking problems, and we still won’t foresee road accidents. The same goes for programming – sometimes it consists of a day when we have a lot of meetings and feel out of rhythm, but often it requires testing, thinking through certain elements, figuring out how to connect them, and at least a few tests along the way. Sometimes something works right away, more often it requires breaking down into smaller problems and solving them before we put these solutions together into a whole leading to the goal.
The issue of thinking through the problem before sitting down to it is more important than it might seem. Some time ago, Daniel Roziecki, in his post on LinkedIn, recalled 4 points useful in solving programming problems:
If we don’t start with this, we may have a lot of problems in the next stages, both with asking good questions and with dividing problems into smaller (pseudo) pieces.
However, let’s assume that we are at point four. What else can be done to avoid becoming friends with powerlessness and helplessness?
For some time now, I have been increasingly boldly using ChatGPT or Gemini for programming (and not only). My second attempt to become familiar with AI in the context of work or learning ended with the fruitful implementation of AI solutions in everyday life.
My first attempt ended in failure because I didn’t know how to formulate prompts to get a helpful answer. This, in turn, stemmed from a reflexive, holistic approach to the problem. If you need to write a plugin – I write to ChatGPT what it should contain and how it should work. If you need to write a questionnaire – I present the entire algorithm of operation. This approach omitted dozens of details that make up working code, which are only visible when the problem is broken down into smaller pieces.
In this way, I write code faster, but I also learn more while writing than before. This does not mean that I still don’t have mishaps when I write code, for example, incorrectly opened PHP tags (<?
instead of <?php
) on the account. And yes, AI doesn’t always help with debugging, and sometimes you have to wander through some dead ends to figure out what didn’t work and how to fix it.
Nevertheless – breaking the problem into smaller pieces is key, regardless of whether you use AI or not. Although undoubtedly breaking it into smaller pieces helps to work with AI when the free tokens for the better model run out
With such a mindset, it is easier to give up another groundbreaking course, inspiring newsletter, or blog post or some YT tutorial promising the ultimate learning of a given technology. It is easier, in turn, to choose the means of learning so that they actually have the knowledge that is necessary for our work.
Does this mean that it is enough to know how to solve problems? Of course not. However, this skill allows you to better manage time and resources in the search for a solution. And it doesn’t lead as often to the realms where powerlessness and helplessness thrive.
Although as a person who loves to acquire knowledge, I regret that I cannot acquire it at Neo’s pace. However, I acquire enough knowledge to develop as a programmer and, colloquially speaking, „deliver” projects – and this is more important than accumulating knowledge.
My code is not perfect. However, as long as this code works and brings money, and does not cause significant problems, it is good enough. Ok, it’s not always properly organized into modules and written without shameful code like the !important
tag in CSS. Probably in a few months, a lot of the code could proudly bear the title of Shame Code. And yes, this can generate some technical debt, but which project doesn’t have it? As long as it’s a debt that is manageable, not affecting the life or death of the project – it’s acceptable.
Thanks to this approach, instead of eternally waiting for my chance, I’m dealing with living, project code and gaining invaluable experience, developing 'programming thinking’. The most important thing, however, is that this approach allows me to build my sense of competence and operate in a land where there are no unsolvable problems – there are instead: challenges that I am ready for or not yet ready for, but can be. Or those that I don’t undertake because they are not within my competence, which is also perfectly fine.