박선동 (Sundong Park)

No regrets about this love.

4 minute read

Six months have passed since I started working as a software engineer. Looking back, the biggest change hasn’t been my programming skills-it has been the way I think about software itself.

During my undergraduate and master’s studies, most of my projects were research prototypes or small personal projects. The objective was usually straightforward: solve a research problem or make the software work. Once the expected results were achieved, the project was considered complete.

Working in industry completely changed that perspective. Building software as part of a large team is fundamentally different from building software alone. Writing code that works is only one part of the job. The way software is designed, documented, and maintained often has a greater impact on a project’s long-term success.

Software Engineering Finally Made Sense

One experience that changed my perspective was participating in the software design process. Before implementation even began, we discussed architectures, responsibilities, interfaces, and system structures. UML diagrams and design documents became the foundation of those discussions. When I first learned software engineering in university, I honestly thought many of these activities were overly formal and unnecessary. Now I understand why they exist. Documentation is not written for the compiler-it is written for people. Good design documents make communication easier, reduce misunderstandings, and allow teams to maintain complex systems over long periods of time.

For the first time, software engineering stopped feeling like a collection of methodologies and started feeling like practical problem solving.

Learning With a Clear Purpose

Another realization was how much I still had to learn. To fill those gaps, I started reading software engineering books much more actively than before. Over the past six months, I read:

  • The Pragmatic Programmer
  • The Software Craftsman
  • Tidy First?
  • Head First Design Patterns
  • The Mythical Man-Month
  • Clean Architecture
  • Software Engineering at Google

The biggest difference compared to university was motivation. Previously, I read books because they seemed interesting. Now I read them because they solve problems I encounter almost every day. Once I experienced those problems firsthand, it became much easier to recognize what knowledge I was missing and why it mattered. There are still many books waiting on my desk, and I hope to continue writing about what I learn from them.

Engineering Is About Solving Problems

Another thing I learned is that software engineering extends far beyond programming. During graduate school, I spent most of my time studying AI algorithms, optimization, computer vision, and machine learning. Today, much of my work involves understanding physical fields and translating them into computational models.

Improving My Development Workflow

My development workflow has also changed significantly. I started using Git more effectively instead of treating it as a simple backup tool. I also began exploring features in Visual Studio and Visual Studio Code that improve productivity, rather than using them only as code editors.

One goal I still have comes from The Pragmatic Programmer. I want to become comfortable enough with my development environment that I can work almost entirely from the keyboard. It may sound like a small improvement, but small habits accumulate over thousands of hours.

Managing Knowledge

Another habit that changed dramatically is how I manage information. At work, I learned how collaborative documentation platforms such as Confluence help teams share knowledge and preserve technical decisions. More recently, I started using Obsidian for my own learning. Instead of scattered notes that disappear over time, I now build a personal knowledge base where ideas gradually become connected. Looking back, I only wish I had started earlier.

Small Automation Matters

Not every improvement comes from sophisticated algorithms. Many repetitive tasks involved creating reports and documentation. By automating parts of those workflows with PowerPoint and Excel macros, I saved time while reducing repetitive work. That experience reminded me that productivity is often the result of many small improvements rather than one revolutionary idea.

Learning How Everything Connects

The first few months were not easy. Like many new engineers, I received an overwhelming amount of information during onboarding. The hardest part was not learning individual concepts-it was understanding how everything connected. Figuring out what to learn first, what could wait, and how different pieces fit together took time.

Looking back, that process itself was part of becoming an engineer. It also made me realize the importance of documenting what I learn. Writing not only helps others, but also forces me to organize my own understanding.

Looking Forward

The biggest lesson from these six months is simple. Software engineering is not just about writing better code. It is about designing systems that people can understand, maintain, and improve together.

I still have a lot to learn.

But compared to six months ago, I spend much more time thinking about why software is designed the way it is, why engineering processes exist, and how small improvements accumulate into better systems.

Now I spend much more time asking questions like:

  • How should this system be designed?
  • How can we make it maintainable?
  • How can we verify that it is reliable?
  • How can we make future development easier?

This blog is part of that journey.

I hope to document what I learn, share practical experiences. And through that process, I hope to connect with a wider variety of engineers and become an engineer with a broader perspective.

You may also enjoy