기차역 건설로 인해 소프트웨어 엔지니어링에 대해 배운 것

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. But communication extends beyond code. You need to write documentation, document technical decisions with RFCs or ADR documents—because code explains the "what," not the "why." Another aspect is asking meaningful questions, which can sometimes help you scrap an idea and save time. Even with clear communication, bugs happen. Finding bugs isn't always straightforward. Being able to attach a debugger and see what's happening "behind the scenes" has saved me many times. I recall checking code once, going through a method from start to end to no avail. Only later did I realize a condition wasn't met, so the method was never actually called. I was certain the state change only happened within that method, which led me down the wrong path. This is where the debugger helped me realize my fallacy. Debugging skills matter, but so does knowing when to stop perfecting and start shipping. I've rarely heard of anyone finishing a project, feature, or code-related task on time in the software field. It's a running joke that people like to share. This clearly shows there's always a need to properly manage time and complexity in software development. And doing this is not straightforward, you rely on experience to make it happen. I recall working on a rewards program for a credit card with a tight deadline. It wasn't smooth sailing. Whenever we hit a roadblock, we either simplified our approach or defined functionality as "nice to have" to get the MV