GoKawiilWatching construction workers balance progress with minimal disruption revealed what truly makes a software engineer. It's not the code you write, but how you navigate complexity, communicate intent, and deliver value under constraints.
Today I found myself observing the construction site at Ljubljana's central train station. I've always taken their work for granted, but today I looked deeper. The station can't close, since it would severely affect tourism, transportation of people and goods, and much more. The work is carefully broken down, workarounds are implemented, and trains are logistically shuffled to minimize impact on everyone. These are good old-fashioned engineering practices, and they're universally applicable.
As I watched the workers coordinate their efforts, some maintaining existing infrastructure while others built new platforms, I quickly realized this is exactly what we do in software engineering. We face the same fundamental challenge: keeping systems running while simultaneously improving them. While building new features, we ensure minimal impact on users and customers, whether it's a database migration, refactoring a service, or updating libraries to resolve security vulnerabilities.
Early in my career, I naively believed engineers were measured by lines of code written. Now I strive for the opposite: do more with less. I still recall comparing code output with friends, celebrating 10,000 lines as a milestone, a metric that seems absurd in the age of AI.
Now I understand there are always trade-offs. You need to consider the customer, be aware of potential crashes in the middle of the night, and push back on certain ideas instead of mindlessly coding. These traits are even more important in the age of AI. Code creation is amplified, but good engineering practices are needed to tame AI's sheer output. What good is AI generated code if the feature isn't used or the application constantly crashes? None, I'd say.
Over the years, I've identified several core skills that define what it means to be a software engineer. These aren't about writing code—they're about thinking, communicating, and delivering value. Let me share some aspects of what I've learned.
As an engineer, you connect the dots and make systems talk to each other. This means understanding how different components interact, anticipating downstream effects, and designing solutions that work within the broader ecosystem. Throughout my career, I've integrated various third-party services, but my proudest accomplishment was generating a completely new app store backed by our product marketplace.
This project required true system thinking. I had to understand not just our marketplace API, but how the app store would consume it, handle errors, and present data to users. It was the first time I had to handle REST API calls — before that, I only had SOAP message exchange experience. It was challenging: lots of documentation reading, payload checking, and troubleshooting. Swagger and OpenAPI weren't widely adopted back then, so manual integration was the only way forward.
System thinking alone isn't enough, you need to communicate your intent clearly. I didn't have proper code reviews from the start, but when I did, I realized how important "communication" - or rather, intent — truly is. Code is read multiple times per day by fellow engineers, and the goal is to communicate to them what it does. Which brings me to my first code review: I felt like I was stripped to the bones, but I quickly realized how valuable feedback is for improving code quality.
Proper naming for functions and variables matters. Tests should be meaningful, not just achieve coverage. Principles like DRY and KISS should be applied when they make sense, not at all costs.
... continue reading