6 Experiences That Made Me a Better Software Engineer
There are so many paths one can go down
Introduction
Every software engineer’s skills come from a mix of work, learning, and personal experiences. I’ve picked up some key skills along my journey, and I’d like to share them with you.
In this article, I’ll talk about six things that really helped me grow as a software engineer. These aren’t just about coding skills; they’re about all the different ways I’ve learned and improved.
Here’s what we’ll cover:
- Open Source Work: My experience with community coding projects.
- Algorithm Challenges: Why tackling tough problems is good for your brain.
- Teaching Coding: What I learned by teaching my cousin to code.
- Side Projects: How my own project helped me learn faster.
- Reading Tech Books: How books keep my skills sharp.
- Getting Feedback: The importance of other engineers reviewing my work.
Open Source Programming: My GSoC Experience
In 2019, I dove into open-source programming through Google Summer of Code, an experience that taught me immensely. My project was developing ‘gnostic-grpc,’ a tool to convert OpenAPI descriptions into protocol buffer files for gRPC interfaces. This project wasn’t just another application development; it felt like being part of a research and development team, pushing the boundaries of what I knew about software engineering.
Key Takeaways from My Open Source Journey:
Thinking Outside the Box: Open-source projects often require innovative approaches, different from conventional application development. It’s more about solving novel problems and less about routine tasks.
Rigorous Code Reviews: Contributing to a high-profile project like Google’s meant my code was rigorously reviewed. This process taught me valuable lessons about code quality and best practices. You can see the level of detail in the feedback on my pull requests during GSoC.
Strategies for Getting Involved: To increase your chances of participating in GSoC, consider applying to lesser-known organizations; they tend to have less competition. Another effective approach is to review the ‘Ideas list’ of various organizations and reach out proactively, even outside of GSoC.
Current Opportunities: For those interested in contributing to gnostic, there’s an ongoing issue to adapt it for async API descriptions.
Reflecting on my journey, I sometimes wish I had dedicated more time to open-source programming. The skills I developed and the impact it had on my career were significant, and I believe it could have been even more transformative
Solving algorithmic problems
The interview process for top tech companies often hinges on solving algorithmic problems, akin to those found on platforms like LeetCode. While some may view this as a peculiar aspect of tech interviews, I’ve come to appreciate its value beyond just interview preparation.
Engaging with these complex problems has sharpened my technical skills in several ways.
Teaching my cousin how to code
Recently, I’ve been helping my cousin, a new computer science student, with his coding assignments. Initially, I found these one-on-one teaching sessions time-consuming and somewhat frustrating. But as time passed, I began to recognize the benefits this experience brought to my own skills and perspective.
Simplifying Complex Concepts: Explaining basic programming concepts to someone new to the field forced me to break down technical jargon into simpler terms. This was challenging at first, but it improved my ability to communicate complex ideas clearly.
Transferable Communication Skills: The skills I honed in explaining programming to my cousin directly translated to my professional interactions, especially when dealing with non-technical colleagues and clients.
The Joy of Teaching: Witnessing my cousin’s progress and his success under my guidance was incredibly rewarding. It gave me a new appreciation for the power of effective teaching
Patience and Adaptability: In the beginning, I doubted his potential as a software engineer and often found myself doing most of the coding. However, I realized that for him to truly learn, he needed to be the one writing the code. We shifted our approach — I would outline the high-level solution, and then he would code it, line by line. This process tested my patience, as it took him much longer to write a single line than it would take me to write an entire function
Long-Term Benefits: This method paid off. Gradually, he needed less direct oversight, and I could just provide the overarching concepts for him to implement independently
This experience was a two-way street: as I taught my cousin, I also learned. It improved my communication skills, patience, and understanding of different learning curves. These lessons have been invaluable in my own development as a software engineer.
Side Project: Amazon Alexa Skills
The Ability to Fail: Despite the time and effort I put into my Alexa Skills, none of them turned out to be a big success. I had a few users, but not enough to make a significant impact or generate substantial income. Each skill I developed was a learning experience, though, improving in quality every time. While I consider each one a failure in terms of success metrics, they were invaluable in teaching me resilience and continuous improvement.
Taking a Project from Start to Finish: There’s a unique satisfaction in turning an idea into reality. From conceptualizing, coding, publishing, receiving feedback, to watching users interact with your creation, it’s a complete journey. This process taught me the importance of seeing projects through to completion.
Discovering a Love for Coding: Initially, I did the bare minimum coding required in my computer science studies. However, working on Alexa Skills ignited a passion for coding in me. The joy of being in the ‘zone,’ understanding concepts more quickly, and solving challenging problems was exhilarating.
Keeping Things Simple for the User: My initial skills received several bad reviews, primarily due to complex usability. I realized I had overestimated the technical knowledge of my users. This feedback was a crucial learning point. I shifted my focus to simplifying the user experience, diving into voice design best practices from Google and Amazon. Understanding that the fault lay in my design and not the user’s comprehension was a pivotal moment for my development as a software engineer.
Reading Books
As a software engineer, I’ve come across several books that are almost essential reading in our field. ‘Clean Code’ was a game-changer for me, significantly influencing my coding style and approach to structuring code. Currently, I’m exploring ‘The Pragmatic Programmer’.
Applying What I Read:
The tricky part is bringing the concepts from these books into my day-to-day work. I often struggle to remember and apply what I’ve read. To tackle this, I’ve developed a system that works for me, rooted in my learning style.
Repetitive Learning: I learn best through repetition. I need to revisit information or apply a concept multiple times for it to stick.
Note-Taking While Reading: To retain more information, I take notes while I read. This slows down my reading speed but improves my comprehension.
Using Notion for Notes: I use Notion for organizing my notes. Its toggle list feature is particularly helpful. It keeps my notes concise and easy to navigate, which is great for quick reference.
Writing Notes in My Own Words: I’ve found that rewriting the concepts in my own words helps in better retention. It ensures that I really understand what I’m reading.
Practice and Improvement: The more notes I write, the better I get at distilling and remembering important information. This practice has gradually improved my ability to apply theoretical knowledge to real-world coding challenges.
Challenge Your Work by Other Engineers
An essential aspect of my growth as a software engineer has been learning the value of peer collaboration and review. After my first performance review, I received feedback emphasizing the importance of discussing my approaches with other engineers, especially before implementing complex features. This advice has proven to be incredibly valuable.
Key Learnings from Peer Collaboration:
Diverse Perspectives: Sharing my approach with colleagues often reveals alternative methods or insights I hadn’t considered. It’s fascinating to see how different engineers tackle the same problem.
Balancing Time and Input: While discussing every detail with others can be time-consuming, I’ve learned to strike a balance. If I’m confident in my approach, I proceed independently. But for larger, more complex issues, I value and seek out peer input.
Independence vs. Collaboration: One of the most crucial skills in software engineering is knowing when to work independently and when to seek collaboration. I focus on discussing broader concepts and strategies rather than getting into the weeds on every detail. This approach helps me to not overburden my colleagues with minutiae, saving collaboration for times when I’m truly stuck or when the project’s complexity warrants broader input.
Incorporating this balance of independent work and collaborative review has not only improved my technical skills but also my ability to work effectively within a team. It’s a continuous learning process, figuring out the best way to leverage the collective wisdom of my colleagues while also trusting my own engineering instincts.
Reflecting on My Path
As I look back on my journey as a software engineer, I’m generally pleased with how my skills have developed. However, there are areas where I see room for improvement or a different approach
While I gained a lot from my time developing Alexa Skills, in hindsight, I might have over-invested in this area. Shifting some of that time to other endeavors like open-source programming earlier could have broadened my learning and had a larger impact.
Another aspect I’d change is the timing of when I read key software engineering books. I realize now the profound effect these classics can have on shaping coding practices and thought processes. Starting these readings earlier in my career would have been beneficial.
In retrospect, these reflections aren’t about regret but about learning and planning for the future. They remind me that the path of a software engineer is never static and there’s always room for strategic adjustments and growth.
