In my four-month software engineering journey, I’ve acquired insights and skills that reach beyond the scope of web application development. Don’t get me wrong; gaining proficiency in this skill is undoubtedly a valuable takeaway, but the true lessons lie elsewhere, and their significance cannot be understated. I’ve acquired a deeper understanding of essential software engineering concepts and picked up valuable tidbits of wisdom along the way. The first two topics that stand out in this regard are Agile Project Management and Design Patterns.
Think of Agile Project Management and its subset, Issue Driven Project Management, like planning a road trip. You’ve got a destination in mind, but you’re not mapping out every single mile at the start. Instead, you break the journey into manageable chunks (issues) and adjust your route as needed. This way, if you hit traffic (unexpected issues), you can reroute without scrapping the whole trip. This approach is not limited to web application development; its principles can be applied to a spectrum of projects across diverse industries, such as optimizing supply chain processes, or even guiding academic research projects.
Design Patterns, another cornerstone of software development, refers to reusable solutions to common problems encountered in software design. These patterns represent best practices, promoting maintainability, scalability, and efficiency. There is an intriguing parallel between programming design patterns and the world of sauces in a chef’s kitchen. In the culinary world, a chef may start by creating a versatile liquid mixture to add flavor to dishes, initially calling it a “flavorful liquid mixture.” As the need for variations arises, it becomes more practical to name it simply a “sauce.” This evolution mirrors how design patterns emerge in programming—designations for common practices that simplify communication and represent best practices discovered by experienced developers. The concept of Design Patterns can be extrapolated to other fields: manufacturing and engineering processes for instance.
Aside from software engineering concepts, one key lesson I’ve gleaned from this journey is the virtue of humility. It’s essential to openly acknowledge when you don’t know something or when a coding error might be at play. Striking the right balance between independent problem-solving and seeking assistance is crucial. It’s about knowing when to navigate challenges on your own without overwhelming colleagues or classmates with constant requests, and conversely, recognizing when it’s time to seek help rather than banging your head against an insurmountable wall. As someone who has been accustomed to solving problems independently, adapting to a collaborative work environment has emphasized the value of learning from those with more expertise. It involves discerning situations where collaboration proves beneficial, steering clear of unwarranted self-reliance, and yet, avoiding excessive dependency on others.
I’ve figured out the importance of keeping my distance – both intellectually and emotionally – from my designs in software development. Developers can often invest a lot of time and effort into their creations, forming a strong attachment that can make them hesitant to acknowledge or address potential shortcomings. When I step back and look at things objectively, it helps spot technical hiccups and security issues that might slip by in the thick of coding. At the same time, emotionally, I’ve learned to take feedback in my stride by treating each program as a chance to learn and grow. Striking this balance makes the whole evaluation process more down-to-earth, turning any hitches I find into opportunities to tweak and improve.