Lessons Learned from a Rotational Software Engineer - Part 1

Hi! I'm back with another post as I recently graduated from my two year rotational program. It was my first job post-college so it's very surreal how fast time flew. 🥳

Now is the perfect time to reflect on what I've learned in the past two years. I did 4 rotations, 2 as a software engineer, 1 as a site reliability engineer, and 1 as a platform product manager. In Part 1, I'll talk about my first two rotations, and save the other two rotations for Part 2 since they aren't strictly dev roles.

As a software engineer with 6 months per rotation, I generally
🕸Coded in React & Polymer
📝Wrote unit tests using Mocha, Chai, Cucumber, & Selenium
🧠Received technical & business trainings both domestically & internationally
🤝Collaborated with UX designers, UI developers, QA testers, tech leads, PMs
🎓Volunteered for buildOn as a mentor through their Career Readiness program for high school students

Overall, it was a fantastic experience. The nature of the rotational program has enabled me to adapt quickly to changing priorities and to overcome any learning curve set in front of me. If you think about it, it's like a six month audition per team in which you have realistically about 3 weeks to onboard and to become a contributing member.

What Did I Learn?

The most important lesson I want to share with all of you is the importance of understanding the bigger picture and of understanding how the application on which I'm working is architected and the design decisions factored into it, whether I have 6 months, 1 year, or more on the team. If I don’t put in the additional effort to understand the bigger picture, my contributions or how I communicate them to my friends, my peers, and my managers will be isolated to the part of the overall application on which I worked.

Think of it this way. Imagine if puzzle pieces didn’t come with a picture of the solved puzzle on the box. How would you assemble the pieces together without knowing what the final result looked like? 🤔 Relating this back to engineering, I'll have only understood a fraction of the application's complexity based on my pull requests.

I translated this lesson into three key points, summarized below:

✅ Top-down vs bottom-up thinking
✅ Identifying technical tradeoffs & communicating them
✅ Understanding my individual impact on the entire system

Top ⬇️ or Bottom ⬆️?

Yes, I borrowed this concept from recursion and dynamic programming.

I prefer top-down thinking because, well, I am a top-down thinker. It’s difficult for me to move forward with a concept until I’ve understood its importance with regards to how it fits in with the bigger picture. When I was first introduced to programming, it was through Java. By making a robot named Karel move. This way of learning didn’t click, primarily because I was unmotivated by the goal of programmatically maneuvering Karel through a maze.

So what changed?

💡 Reading Web Architecture 101 by Jonathan Fulton. The subtitle itself "The basic architecture concepts I wish I knew when I was getting started as a web developer" resonated with me SO much.

"So THAT's what a load balancer is! THAT's why API design is important and so hotly debated! Caching, CDNs, all these ways to improve performance and availability - wow!" - Me, circa May 2019

In short, I used the web architecture in the article above as a blueprint and delved into its specific components to further my understanding. Hence top-down thinking.

It's All About Tradeoffs ⚖️

But knowing these terms isn't enough. Arguably, as you level up in seniority as a developer, you take on more responsibilities in scoping out projects, proposing designs, and justifying said designs to your colleagues.

I know nothing can really replace practical experience in this area and I'm not suggesting anything can. What I am saying is by understanding the types of decisions developers have to make and the types of questions they have to ask, I can feel more empowered to take part in design meetings despite being junior and to apply this understanding to the work assigned to me and to the existing application architecture.

Might I suggest a hack?

💡 Studying systems design. Even if you aren't actively interviewing.

Systems design is a multi-headed beast on its own. Many different potential approaches but it's an exercise in technical communication and technical depth. Watching YouTube videos on frequently asked systems design questions such as designing Google Maps or TinyURL were extremely informative.

It helped me formulate a framework to approach these types of problems:
💭 How to refine the scope of the problem - alignment on the # of Monthly Active Users (MAUs), on the features to be discussed, on special considerations
💭 How to structure the discussion - begin with data modeling, API design, interaction between components of the system, discussion on how to improve performance & ensure scalability
💭 Databases - why NoSQL vs SQL? What are advantages/disadvantages of either? What techniques exist to ensure availability of databases as the amount of data scales?
💭 Database replication vs. partitioning - What are advantages/disadvantages of either?
💭 Microservices vs. monolith - What are advantages/disadvantages of either?
💭 Load balancing & API gateways - can API gateways in microservice architecture be considered a type of load balancing technique?

I could go on forever. You start to see that the questions often segue into the next and are focused on advantages/disadvantages of one approach over the other. This knowledge acquisition helped me introspect on the first two teams I worked on as a rotational software engineer and will help me in the future as well.

Be Empowered 💪🏼

Any contribution is significant, no matter how big or small, front-end or back-end, QA, etc. Think about it - no matter what your role on a dev team, understanding the system will help you perform better. At the very least, it will help you confidently talk about your past work experiences or avoid downplaying by hastily summing up your contribution as "Oh, I was a front-end engineer on that team" or "I worked on the back-end mostly". Take pride in your work! Elaborate!

In short, figure out what type of learner/thinker you are, understand architecture at a high-level and design decisions associated with said architecture, and then apply it to your own work for that application. This really worked for me, and I hope it works for you, too.