Intro: The Transition of a Computer Engineering Student
My starting point upon graduation wasn’t strictly in software engineering; I actually majored in Computer Engineering. However, as fate would have it, the day I stepped out into the real world with my degree, I took a sharp turn to become a Software Developer.
At that time, my baggage contained nothing but some foundational knowledge and a strict mindset: If I’m working, I can no longer be lazy. If I don’t do my job, absolutely no one will do it for me. That pressure of responsibility forced me to grow up, think independently, and learn to swim in the whirlpool of technology.
Episode 1: The “Welcome Gift” Named Oracle Database
During my first days on the job in 2011, I received a memorable challenge: a thick stack of documentation on how to install Oracle Database on my assigned desktop. For a rookie, Oracle was famously known as a complex and “heavyweight” relational database. Configuring environment variables, listeners, or tnsnames.ora felt like reading encrypted code at the time.
After days of struggling, blindly reinstalling it over and over, the local screen finally showed a successful connection via PL/SQL Developer. The “exhausting” experience of those early days laid the foundation for me to battle with Oracle Forms & Reports — an incredibly popular technology in large enterprise systems back then. It taught me my very first lesson: Don’t fear new technology; just get your hands dirty. Reinstall it a dozen times, and you’ll naturally understand its core.
Episode 2: Java, Play Framework, and the “Don’t Hide Your Ignorance” Mindset
Not long after warming up my seat in the Oracle team, I was moved to the Java team to code Desktop applications using Java JWT/Swing. But before I could even settle in, the Department Head decided to pivot the entire team to a very new technology at the time: Play Framework.
Today, this name might have faded into the past with few remembering it, but back then, it was a whole new world. I survived this period of constant shifting thanks to a core philosophy: Don’t be afraid of people judging you as incompetent, be willing to learn, and absolutely do not hide your ignorance. If you don’t know, ask; if you don’t understand, dig deeper. That “shameless” attitude unlocked my ability to proactively learn any system.
Episode 3: Epiphany on the Core of PHP, MySQL, and Legacy ASP.NET Web Forms
The technology merry-go-round showed no signs of stopping. Right after Java, I was pushed straight into an old project running on PHP and MySQL. Then came SharePoint, bringing the opportunity to get familiar with the Microsoft ecosystem including C# and SQL Server, and even some legacy ASP.NET Web Forms projects with their convoluted Page Lifecycles and ViewStates.
Facing a basket of constantly changing technologies within just a year, my mind suddenly cleared, and I experienced a massive leap in my thinking: A new language? So what? A new DB? Nothing to fear. There must be core commonalities between them! Instead of rote-learning every line of syntax, I chose a top-down approach:
Focus on the Business Logic: Any technology must serve a business problem.
Debug when wrong: No more guessing games. Just set breakpoints to watch the data flow and logically deduce why the system behaves the way it does.
After those projects, I realized that SQL fundamentally shares a common standard (ANSI SQL), only differing in a few specialized functions per DB type. From that moment on, I didn’t have to waste too much time “relearning” from scratch every time I switched databases or languages.
Episode 4: The Optimization Battle and the “Cherish Every Byte” Lesson
The peak of my first-year challenges was writing fingerprint recognition software for an AFIS handheld device. It was a hardware “monster” weighing nearly 1kg, running Windows CE 5.0, with a meager RAM of exactly… 128MB, written in MFC (C++).
The mission was to capture fingerprints and match them locally; if it failed, call an API to push the data to the Server. With a tiny 128MB of RAM, continuous image data processing turned the memory into a sensitive battlefield. Just one “forgotten” pointer deallocation (Memory Leak), and the Windows CE OS would mercilessly “kill” the app.
Back then, we didn’t have fancy Profiler tools, and phones were still “dumb bricks,” so there were no smartphones to take pictures for documentation. Finding a memory leak relied entirely on step-by-step debugging, observation, and intuition. Through hundreds of crashes, errors naturally turned into experience and reflexes. From that grueling battle, I forged a professional standard that has stayed with me ever since: When resources are limited, you must pay attention to every memory block to avoid leaks. You must write clean code and be responsible for every byte of data, no matter how powerful modern machines are.
Conclusion: The Master Key of a Software Engineer
Looking back at my “stormy” first year of working, I silently appreciate the immense pressure and constant changes of those days. Ultimately, technologies, languages, or frameworks are merely vehicles; they are just the branches. The roots that help a developer go far and never fear obsolescence are: A business logic mindset, logical debugging skills, and an attitude of not hiding your ignorance.
Don’t turn yourself into a code monkey boxed within a specific language. Be an engineer who solves problems with an adaptable mindset, because technologies may rise and fall, but the ability to adapt to the market lasts forever.
답글 남기기