In the last five to six years, I’ve been looking for a grand goal in life. My search yielded nothing. The more I looked, the more it concealed. Then I stopped and turned around to look at what had happened so far. Something appeared out of nowhere. This retrospective look didn’t reveal the meaning of life to me, but there was a beam, hidden behind my back, guiding me. That ray of light materialized as an eagerness to solve problems. That’s when I realized I had found it.
My clearest memories start from high school. Memorizing topics or formulas always drained my energy. Most of my weak subjects were the ones that forced me to memorize word-for-word: history, geography, literature, and even biology. The ones I thrived in—mathematics, physics, and sometimes chemistry—always gave me problems to solve. Naturally, I chose to follow a STEM degree and graduated as a computer engineer.
It’s boggling my mind how this eagerness to solve problems has always been there, but disguised. Apparently, it was scattered across multiple fields, and my forward-looking approach hid it behind me (you can’t see your back unless you use a mirror; and you don’t see yourself in a mirror all the time).
As little as I knew, this joy of solving problems has evolved throughout my career.
Problems with programming
I first enjoyed solving software problems because the stupid, riling, wily machine—ahem, computer—was puzzling me.
I remember very clearly the first lecture of the Introduction to Computer Science I had at the university. The professor told us, “The computer is stupid. I mean, really stupid.” We need to think and act as if it’s the dumbest thing that has ever existed. His job was to teach how to give clear instructions to the machine so it would do what we wanted. Learning those instructions became the first of many problems I tackled. I spent a decade working on it.
I solved many problems in different programming languages; I learned best and worst practices, fundamentals, patterns, and paradigms. The more I learned, the more I realized that the problem wasn’t the computer. It was doing precisely what I was telling it to do, but what I said was sometimes wrong. I had to start from scratch multiple times. That was the problem I needed to fix next: how to think clearly and give precise direction—the exact thing the professor told me years ago. So, the problem was hominid.
Problems with thinking begin to appear
The human mind caused all bugs, not the machine. For the machine, it was all a matter of true or false, 0 or 1. It was the humans who coded those incorrect bits. That’s when I thought we would be better off if we had solved the problems before coding. I moved one step to the left in the process.
I focused on designing a solution up front, shaping my thinking about how to solve a set of problems rather than letting the design emerge over time. I learned more about quality, automation, better software architecture, system design, and the importance of building guardrails. The coding was much easier once we solved the problem on a whiteboard (or paper) and once we defined how we would shape the system for future iterations.
After a while, I realized that approaching this way required a different mindset that not everyone possessed. If I helped people gain a fresh mindset, we could solve more problems efficiently. This approach paved the path to management and leadership.
Leadership and Management
I focused on avoiding wasted time by looking at the team’s culture, structure, and interpersonal dynamics that enable healthy problem-solving and debate culture. A culture in which people lift each other, in which incentives are correctly placed, in which everyone is encouraged to think in and outside of the box, in which debate for finding the best possible solution rather than ego satisfaction, and in which delivery speed is high thanks to high-quality work, became my goal.
In the end, it also became my job, and I became an engineering manager. At this stage, the process was no longer linear.
I learned that I needed to jump one or two steps to the left, right, up, or down, or even around corners, in the process (I didn’t know systems thinking at first). This demand changed how I approach problem-solving overall.
The management and leadership problems were drastically different than machine problems. The biggest one I recognized was that the teams were often solving the wrong problems. We wasted money and time solving a problem nobody cared about (and for sure weren’t willing to pay for).
I began working closely with product, design, and other business units to understand why we are doing a project, what we aim to achieve, and how to make it feasible for the business.
I’m still learning, but so far, this is the steepest learning curve I’ve faced, not the programming languages. Because it not only includes product and business thinking, it also encompasses all the things I’ve learned (machine language, software architecture, system design, people, culture, incentives, etc.).
Problems at the intersection of software systems, psychology, and economics have become interesting not only because they reflect what I have learned so far. They are interesting because of the sheer complexity they contain.
Software Engineering, Psychology, and Economics on Complexity
While the software systems are technically sophisticated by themselves, we can’t leave out the psychology (especially social psychology, the study of how people’s thoughts, feelings, and behaviors are influenced by the real, imagined, or implied presence of others) and economics. Solving problems with software in socio-technical systems (the word ‘technical’ doesn’t necessarily mean software; rather, technicalities of an organization) effectively and efficiently demands understanding both.
Effectiveness has a lot to do with psychology, while efficiency is more about economics.
Understanding motivation architecture (what motivates people), reading invisible signals (how to build psychological safety while working with different cultures), managing cognitive load effectively (why is a team/an employee underperforming) and navigating conflicts constructively (what unmet need created the conflict) require a good understanding of psychology. Learning psychology doesn’t mean becoming a therapist. It’s about understanding the operating system a person/a team is running on, so we can work with human nature rather than against it.
While psychology examines why people behave as they do, economics focuses on the consequences of those behaviors within systems and how to optimize resource allocation. Learning more about economics (the study of how individuals, businesses, and societies manage their scarce resources to produce, distribute, and consume goods and services) opened my eyes to various instruments I wasn’t aware of. Opportunity cost, marginal analysis, incentive structures, transaction costs, economies/diseconomies of scale, sunk cost fallacy, supply & demand, impact of biases, information asymmetry, and other mechanics raise awareness of how to increase the system’s effectiveness; I was ready to learn them all, but…
Learning all of these takes considerable time and energy. However, none of them solved the majority of the problems that I have faced single-handedly. Instead, each helped me to avoid some stupidity.
“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” —Charlie Munger
Instead of trying to make a smart move, focusing on avoiding stupidity is the best approach I’ve found, since we have a minuscule amount of control over the components of socio-technical systems, unlike software.
In a way, it is all clear to me now. Software engineering leadership (regardless of the job title, Engineering Manager, Director, VP, CTO, etc.) sits right in the middle of these three disciplines; practicing all demands time and focus.
Focusing on the right problems
While some people focus on influencing others or advancing the industry, I focus on building socio-technical and software systems that solve problems worth solving. I constantly remind my ego that influencing one person is a big win in the attention economy and solving one problem can be a much bigger gain for the community than earning a million Euros (if the problem is the right one).
It’s correct that through solving some problems, I get paid. I earn enough to give me a headspace to learn a variety of topics, think about them and share them here.
Still, not all problems are worth solving.
I don’t mean focusing on problems that bring money when I say the word ‘worth.’ It is the other way around. If a problem is worth solving, it has a high probability of bringing some benefits, whether monetary or not.
The world is a vast garbage heap of problems that were unnecessarily solved. People solving the wrong problems (careful, not solving them the wrong way) is the biggest waste of resources. That’s also one of the main reasons many organizations fail. I intend to avoid that.
People getting stuck with the wrong problem is the grand challenge of our modern age. It’s a knotty task as most problems have become more layered, intertwined, and vastly complex. Nobody can solve any problem without going through the levels of complexity. That’s why I’m still surprised by how people think they can jump to bigger problems without going through the evolutionary process (a few can do, many can’t).
Career journey
A junior engineer needs to solve problems at the code level; they need to learn the language of the machine (this might seem like changing with AI, but I think foundational knowledge is still as crucial as before). They can become senior engineers once they accumulate enough solved problems.
During seniority, they should see enough problems and solutions to start recognizing patterns and different architectural shapes of the system(s). This approach will help them solve different problems and become reliable. That’s what experience means.
Now I understand better why job postings ask for some years of experience: solving problems needs time—the biggest constraint of all.
If you claim that you have great knowledge to be called a senior engineer after 1-2 years of software engineering, I can’t diminish your knowledge, but I can play down your experience. I am 100% sure that you haven’t solved enough problems.
What is enough? It’s a big question that I can only answer famously: it depends. It’s one of those “you’ll know it once you get there” questions. But then, how do you know you’ll arrive? Well, it depends on how your organization defines the destination. When it comes to me…
I see this as a journey and a race with myself; a journey through complexity and a race between humbleness and ego. The ego is pushing in every possible direction to contain life and always tries to bite more than it can chew (e.g., seeking the next promotion, surrendering to hustle culture, or being the servant of the attention economy). That’s why humility comes from knowing how much I don’t know and being aware of gazillion problems, and from facing the challenge of finding the right one.
A journey through complexity, because resolving problems at work is already arduous, let alone the whole life.
The journey going forward
I focus on the complexity of life and on solving problems at the intersection of software systems, psychology, and economics. One branch of this, in which I have dedicated my last 9 years, is solving problems for small- to medium-sized businesses—the backbone of the economy. Imagine solving an admin problem of a restaurant owner, a freelancer, a bakery, a landscaper, an event planner, or a handicraft shop. That enables them to focus on what matters to them and brings joy: their craft. That’s where I believe many wonders are hidden.
The other branch I’m focused on is helping others learn how to approach solving these complex problems. If I’m learning something to solve a problem I faced, I want to share my learning with others, and writing it down ensures that I have a clear understanding of what I’m talking about. Repeating what Feynman said: “If you want to master something, teach it.”
That’s why this blog exists.
