Working with Seasoned Engineers & Understanding the Planning Process as a New Software Engineer out of Bootcamp

When I started SurveyMonkey, I was handed my first production project as a full time employee, straight out of bootcamp, and that I thought it would be a piece of cake: a simple webpage. I grossly underestimated the time it would take me to work on it. During that time, I learned a lot that I presume will help me to tackle projects in the future.

My biggest learning was understanding how to work with other seasoned engineers (remote and in person) as well as learning how to build a custom planning process. Pair programming with other engineers or simply asking prepared questions gave me

• Quicker resolutions when I was stuck or unsure how to do something,
• Learning where helpful documentation is located and conventions that are commonly used on the related team/service,
• Best coding practices, and
• More confidence asking for help.

That said, I was given feedback throughout the process:

• Clue my manager in as I go for timeline. This was helpful for them and myself because it helped gauge when they might need to jump in and help and gave me ownership when help wasn't necessary.
• SurveyMonkey gives employees access to Udemy learning courses, which I found was helpful built in learning as I worked on the project. I was tempted to utilize this outside of work hours, but as a single parent of two young children and prioritizing work life balance, that wasn't realistic. I was able to tackle bits of courses as I worked and even built a recommendations list from engineers I've paired with on things I could strengthen.
• When working with PMs, I failed to ask clarifying questions in the beginning and found myself asking questions as I went along coding. I learned that I need to think beyond simply coding, not only my scope of the project, but how my project might relate to others' around me. This line of thought will help me to address knowledge gaps in the future around projects I am handed.
• Consult documentation to see if there is a built in approaches the team/service has for tackling things or writing their code. You don't want to reinvent the wheel and there's nothing more stressful than doing things your own way and not being able to figure out why your tests aren't passing because you're missing brackets, or something simple.
• Distribute your questions first via your team who is your primary support and then to the service's team you are working on, if separate.
• If your online convo with an engineer is more than 3 to 5 responses, calendar pair programming session for focus on approaches you've already tried. I schedule these from a range of tests not passing to not understanding how to write particular code. In my scheduled invitation I write a line of context about the issue I am trying to tackle and what I have tried, link to any relevant code, and screenshots if relevant.
• Seek out similar code to mock and examples in the repo to try and follow, they will teach you of the various use cases as well as how to use new territory code.
• Share links to code with lines highlighted instead of copying in chat.
• Test locally to prevent lots of little commits for testing on PR.

So, how do I plan to be learn from this experience and implement? I've come up with a set of steps of phases I plan to follow critically:

1. Understanding the deliverables and timeline / dates.
2. Asking clarifying questions to the timeline of the project and your own features to build out and how they relate to other pieces.
3. Confirm both obvious user experiences and error/not obvious user experiences.
4. Read service / team documentation for tips and tricks (i.e. code structure, commit and PR practices, testing conventions, etc).
5. Think about tests to weed out any clarifications you still seek.
6. Break larger things up into smaller parts for multiple, smaller PRs.
7. Seek out examples of similar features or code you will need to use for understanding of how things work.
8. Identify new coding territory - language, testing, feature to build, etc. Find an engineer that specializes in said territory. Schedule a few pair programming time to go over what you have tried with said engineer. Spread out the sessions over the course of your sprint appropriately.
9. Ask your team to evaluate your PR, then ask someone on service or service team to review your PR.
10. Code all the things.

I'm still learning and I'm sure there is much more to report on, but I'm thoroughly excited about the new technical skillset and knowledge I've acquired from this project and can't wait for more.

#celebratethejourney