Circadian Landscape: Part 3. Retrospective

At this point I had reached the two week time limit that I set for myself on this project and had let myself get pretty distracted from my job hunt. I found that coding and solving problems in this way waswith super addictive for me. It was at times incredibly frustrating but also at times incredibly rewarding, and overall I really enjoyed it. I knew I wouldn’t be able to focus on writing resumes and cover letters if my other choice was to be working on this, so I decided that it was time to put it aside with some notes on what my next steps forward from here would be so that I could jump right back in when I had time.

Retrospective

Over the course of this project I was able to confirm 2 of my original hypotheses. Building a slideshow like this was totally possible, and I was able to break the whole process down enough to turn it into coding problems I could tackle with my limited knowledge.

Additional things I learned were definitely some expansion of my coding vocabulary and several big time saving/error reducing coding practices, mostly around how I was making database calls and setting up their errors. I also learned more about where and how obstacles occur when you are building something you don’t know how to build, even when you understand all the pieces to do it. For example, getting less definitive results than expected from the photo analysis or the Javascript slideshow not being setup for vertical photos.

I also learned about the difficulty in estimating how long something will take because of those obstacles. I knew both these last two just from my experience as a PM working with engineers, but it was cool to see it for myself, and I think will help me coach engineers how to recognize it better, which can be really helpful for communication and remaining flexible when you are in the weeds of a project.

The Biggest A-ha!

“Coding is mostly debugging” — My Husband

Probably the final and most important thing I learned was to optimize for debugging. By moving through all the steps of the process and building something that works end-to-end, I will have answered the biggest questions around “How is this possible?”. I will get myself to a place where I can iterate effectively, knowing that any improvements I make are improving the actual end product I wanted to create, and not just finding some “local minimum” around how to best code one task in the process.

I didn’t do this in this project and that led to two bad things:

• Spending too much time on the wrong things in the middle
• And not finding out some of the big unknown unknowns until the last minute when I didn’t have enough time left to fix them. From a product perspective

Man, as a product manager these are like your WORST nightmare and you’d think I would have been able to avoid them, but when I was in the weeds of this project, I totally missed the signs. It’s really driven home the importance of having those different roles and perspectives on an engineering team, and why it feels so magical when things really click and you are all producing more than the sum of your parts.

Coming to understand the difficulties of estimating projects and how bad organization of project work can really exacerbate the mistakes that get made has already improved the way I interact with my engineering team and how we organize our work!