30/60/90 Feedback: How to get feedback early and often and how to up your communication skills as a developer.

I really enjoy getting feedback on the work I'm doing at a company. I love code reviews and I really enjoy pairing. Instinctively, I over-communicate about how I'm thinking about approaching problems to my peers to make sure there aren't any gaps in my thinking and that I'm not going down a rabbit hole wasting time on an irrelevant solution. It's okay to do this on personal projects and side work, but at a company, ultimately your primary purpose is to improve the product and ship features. In order to be effective at that, it's important to not waste time in isolation ( struggling or perfecting! ). It's meaningless to spend endless amounts of time building the worlds greatest feature if it never sees the light of day.

I became aware of the 30/60/90 framework at my current company and I think it's a great way to think about feedback and communication. It's also incredibly simple. 30/60/90 are percentage benchmarks for when you should be sharing work or asking for feedback.

At the 30% mark, you should have a solid understanding of the problem and potential approaches. You've thought through the different pieces that will need to be built and possible edge cases. You may even have some pseudo code or proof of concept in place. This is the time to get feedback on the general approach so you don't build a full feature soup-to-nuts, tests and all , only to have to delete it all in favor of a different direction .

At the 60% mark, you pretty much have a fully working feature and implementation ( maybe sans full test cases ) and perhaps some TODOs left in your code. Now is the time to get a more thorough review of your work by your peers. Open a draft pull request on Github and seek out feedback. This is a great time for a more senior engineer to review some of the implementation details and see if there are any gaps in your approach. I personally have learned a ton during this phase. Things like, this function will cause React to re-render too many times and will be a performance bottleneck; 60% feedback will really expand your understanding of your tech stack.

At the 90% mark, you have a PR that is ready for review. Here you should mostly be getting feedback on stylistic things in your code that aren't caught by eslint. You have full test coverage and your tests are passing.

Of course, 30/60/90 should be guidelines and not strict measurements of your progress. I've found it to be a really helpful nudge to myself to communicate early and often to my teammates and is a great reminder to be collaborative with others while still being async and not requiring hours of their time.