Building Solutions, Not Just Software: The Story of Maciek’s Career

Maciek is a software developer with over 20 years of experience, though his career beginnings couldn’t have been more unexpected. Discover how he landed his first job in IT, how he immerses himself in clients’ business domains, and how he challenges himself beyond work hours.

How do you recall your programming beginnings?

It was tough because I had to learn programming on the job. I graduated from Gdańsk University of Technology with a degree in Electronics and Telecommunications, so my studies weren’t directly related to software development.

It was a very stressful period for me, and I remember it as an intense learning experience. From the very beginning of my first job, I worked on systems that had to function reliably – I didn’t have a transition period where I could ease in with internal projects. There was no time for that. The team was small, and I had to quickly catch up and contribute right away.

Why did you decide to become a software developer despite having a completely different educational background?

It was completely random. I wasn’t looking for a programming job – I was actually searching for something related to my studies. But one day, after leaving an office building where I had an interview, I ran into a friend who worked nearby. After finding out I was looking for work, he encouraged me to apply at his company. It turned out to be a programming job, and that’s how I got into software development over 20 years ago.

You struck me as someone who enjoys diving into clients’ business domains. Why is that important to you?

Perhaps it’s because software development was never my original career path, and the technical side of it has never been my primary focus. What truly fascinates me is understanding how different industries operate – often even more than the technical implementation itself.

Why? Because I see it as our mission as programmers. No matter how advanced my technical skills are, they’re useless unless they solve real problems. Code needs to have a purpose. Crafting code isn’t the main priority; delivering value through my work is. It also has to be simple to read so that my team members can easily work with it as well.

I’ve always been intrigued by the industries I’ve built software for – how they function, how they use our tools, and whether our work truly makes their jobs easier. Do they actually need what we’re building? When you understand their domain, you can answer that difficult question.

So, what are your methods for deeply understanding clients’ business domains?

When you show genuine interest in what people do, they naturally open up and share details with you. If your attitude is, “My job is just to write code, I’m not responsible for anything else,” then your knowledge sources will be very limited. But if you listen and ask questions, people will naturally start sharing more and more insights.

The key is to seek contact and show curiosity – knowledge sharing will follow. For me, it has always been natural to exchange knowledge, so I don’t follow a strict method. It all comes down to conversations; once you engage, the learning process happens organically.

If you’re passionate about something, you’ll find a way to learn more about it. Curiosity is the key – it all starts there.

I’ve heard from some colleagues that starting a software product from scratch has many benefits. What is your take on that?

I think I’m on the opposite side – I don’t find starting from scratch particularly appealing. At the beginning of a project, there are so many possibilities and directions to take that it can feel paralyzing. You’re unsure which technology to choose, and you need to go through a well-thought-out decision-making process. At the same time, you need a high level of self-discipline to avoid getting lost in endless deliberations.

There are so many “toys” on the market, and there’s always the temptation to try something new, but that can lead to poor outcomes. Naturally, when it comes to side projects, experimenting is fun and exciting. But when building a product for a client, the real challenge is making crucial decisions without excessive delays. Otherwise, there’s a risk of programmers getting caught up in endless debates about tech stacks while the client is still waiting for tangible results.

For me, it’s easier to join an existing project that already has a structure – where some architectural and stack decisions have been made. They don’t have to be perfect; what matters is that I can focus more on the business domain and less on the technical aspects.

You are part of the team building a solution for the shipping industry. What are the challenges and specific aspects of building software for logistics?

What strikes me the most is finding the right balance between strict rules and regulations and the flexibility that this industry still requires within those constraints.

For example, a client might expect all transportation details to be entered before a driver starts the journey. However, in reality, there are cases where this isn’t possible, and our system must be flexible enough to accommodate missing information that will be provided later. This kind of flexibility isn’t easy to maintain within a rigid set of rules in the code. Yet, the challenge is to design software that can handle both structured compliance requirements and the dynamic, ever-changing nature of logistics.

As one of the top Bright runners, share with us your running goals for 2025.

This year, I am planning to participate in the Backyard Ultra for the first time. It’s a unique competition where all runners must complete a loop of nearly 7 km in under an hour – and then do it again, and again, until only one person remains. Essentially, it’s a race where you are mostly competing with yourself, and you never know how long it will last. The world record is over 100 loops! My personal goal is to complete at least 10 loops.

It’s a huge challenge because this type of race can go on for days, with very few supporters. Unlike traditional races where you feel the energy of the crowd, in Backyard Ultra, you run day and night, often alone. Mentally adjusting to these conditions is tough and very different from other races.

This race is also part of my preparation for my ultimate goal in 2025 – running a 100 km mountain race. Unlike Backyard Ultra, that will be a more traditional race with a defined start, finish line, and direct competition with others.

Do you see any similarities between long-distance running and software development?

Oh yes! In both, so many things can happen – you experience moments of euphoria when everything runs smoothly, and then there are tough crises. But if you push through those difficult moments, you somehow find extra strength, just like your legs do in a long race.

I think it's similar when working on a long-term project. There are always dull periods, and that's when some people start looking for other projects. Not everyone wants to go through the boring or challenging phases. We often justify it by saying we need a change for self-development, and while that might be a rationalization, sometimes we’re simply chasing the excitement of something new.

I believe that if you push through these tough moments, something rewarding and exciting will eventually come – and with it, a deep sense of satisfaction.