5 Lessons from My First Dev Job

5 Lessons from My First Dev Job

I recently bid farewell to my first job as a software developer in North Carolina as my family and I headed back to Brooklyn. One of the greatest gifts of our two years in NC was the opportunity to pivot careers. After many years as a Product Manager and Leader, I finally had the time and space to focus on learning to code.

Gaining this skill - I thought - would make me a more technical Product Manager. I hadn't anticipated being swept away in the sheer satisfaction of coding, and gaining a much clearer understanding of the deep challenges all developers I've worked with in the past must have faced. With a specific lens as a former Product professional - here are some lessons I took away from my first developer job:

1. Communication is Critical

As a Product Manager, my favorite developers to work with were not necessarily the most technical but rather the strongest communicators. The developers who knew when to pause and weigh options, choose a direction, or ask questions - and when to continue down their chosen path.  Those who could explain their progress in language that a non-technical team member can fully understand. I have a special affinity for developers who are strong product-thinkers, and naturally weigh cost versus product benefit when discussing requirements and estimations.

As a developer, I feel even more intensely how critical communication skills are to effective and efficient technical work, especially in an environment with time and budget restraints. When I realize that a story will take longer than anticipated, that we've discovered new edge cases, or that a stakeholder is not correctly in the loop - I imagine what I would want as a Product Manager. I pause, and I make sure the entire team is on the same page. 

2. Code Reviews are a Learning Tool

As a newer developer, I leaned hard on the code review system at my first developer job. On senior developers reviewing my code and giving helpful suggestions - of course - but even more so on examining the code reviews of others. A strong code review system depends on reviews being a priority for everyone on the team. In an effort to be a team player and to learn as much as possible, I set a calendar reminder daily to grab a few reviews even when my own tasks were at their most difficult and challenging.

As part of a supportive team, I felt free to ask questions in my reviews as well as give suggestions and kudos - and more senior members were generous in explaining or pointing me to more robust resources. Code reviews are a fantastic way to learn and gain access to different programming styles, languages, and ways to solve a problem. 

3. Tests First, Code Later

Write a test. Make sure it fails - so that you don't spend time writing code to pass a test that didn't fail in the first place. Then write the code to make it pass. The act of writing a test also forces you to identify a clear understanding of the feature's requirements. Otherwise, you may find yourself writing tests that allow your code to pass rather than crafting tests that ensure your code meets a requirement. 

When working on a team, thorough tests minimize the chance of regression errors causing other developers to spend time fixing your mistakes.  And it serves as yet another useful tool for developers to decipher what you were thinking when you wrote that code. 

4. Most Things Take Longer Than You'd Think

In product development, it is common to encounter unexpected issues and challenges along the well-paved way. It is notoriously difficult to estimate technical work - even in the rare case that everything runs smoothly - and I now understand this much more thoroughly than I did as a Product professional. 

Little delays add up in aggregate - a simple merge reveals a hard-to-find bug; a deployment issue takes the attention of several developers for a day; the office has Internet issues; someone's child gets sick. Several of my colleagues operated under the rule that you should double estimates, always, in anticipation of the above hiccups reducing your team's overall productivity. While I wouldn't take it that far, I have learned that planning for a more realistic scenario helps set expectations upfront and makes unexpected delays easier to manage and accommodate.

5. Product Managers Matter!

I had a hunch that Product Managers were important, and am relieved to have confirmation of this fact. Without clear requirements and planning, as well as diligent and thoughtful communication with stakeholders, development runs the risk of complete derailment. Rather than focusing on architectural decisions and writing clean, readable code, developers can get bogged down in chasing the feedback that allows an agile process to run smoothly. 

As a Product Manager, it was my responsibility to ensure that my team of developers always had a robust backlog of important work to do. I've found that when this component is glaringly missing, developers end up spending a lot of time gathering their own requirements or pursuing side projects - or, in the worst case, doing nothing. In the case of people like me who thrive off of being busy and productive, this is a morale killer. 


I am eternally grateful to my team and mentors at Smashing Boxes who taught me so much about how to be a developer, and exposed me to a wide breadth of technical projects. Now back in Brooklyn and seeking my next opportunity!  

The Human Side of a Code Audit

The Human Side of a Code Audit

Houston, We Have Apple Push Notifications

Houston, We Have Apple Push Notifications