Realistic Measuring of Reactive vs Proactive
I know that launching a product with bugs shows a reactive approach. Similarly, if a reviewer catches an issue you missed, that’s also reactive.
But what if you’re thorough in writing and testing your code locally, and you catch a missed dependency before even raising a PR? You fix it yourself without anyone else noticing. Does this reflect positively on you for solving it on your own, or does it still look bad because it was missed initially?
Taking it a step further, say you forget a simple null check, causing errors in your unit tests. You catch this yourself and fix it, but technically, you were still being reactive.
So, how do people realistically measure “reactive” vs. “proactive”? And how are scenarios viewed where you catch and resolve issues on your own while writing code?
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(5 comments)- 1a month agoTech Lead/Manager at Meta, Pinterest, Kosei
This all counts as proactive in my book. You're being awfully harsh on yourself!
Does this reflect positively on you for solving it on your own, or does it still look bad because it was missed initially?
If you caught it on your own before the PR is public, no one could make a judgment or dock you for missing anything. Similarly for the null check example your brought up.
The north star is simple: how can I deliver a great experience for my coworkers?
- If your teammates need to point out a bunch of issues, that's bad 😭
- If you caught the issues but you clutter up the comments/revision history correcting your sloppy code, it's better than above but still room for improvement 🤔
- If you caught your mistakes and are presenting a "clean" PR for your coworkers, you're golden 🏆
- 1
a month agoTech Lead @ Robinhood, Meta, Course HeroYour thread brings up an interesting point as reactive vs. proactive is indeed a spectrum. Unless you are functioning 100% perfectly as a human being from the get-go, you will technically be reacting to some flaws along the way.
However, reactive vs. proactive is also a matter of perspective, and that's more important. If you find a bug while developing locally, literally nobody else will know (unless you weirdly tell them...?). From the team's perspective, all they see is a polished pull request once you submit the code and they will think that you proactively guaranteed the code's quality.
In short, I do think you're being at least a bit too harsh on yourself as Rahul mentioned, hehe. To me, it seems like you're doing just fine!
If you do want to measure your code quality, here are good metrics (the thread is about interns but it applies to pretty much everyone): "Internship Metrics For Conversion?"
Check out the code quality course as well: Level Up Your Code Quality As A Software Engineer
- 1a month agoMid-Level Software EngineerTaro Community
Then the behavior of taking 25% longer seems to fall under the disproportionate outcomes category lol.
my work life balance is amazing and I look great by having amazing behavior and communication.
that being said it sounds like these are the “easy” parts of the job so I’m curious what the parts that are true blockers that distinguish good from great?
the context is that taro advice is amazing and love it 😍 but that turns into a formula of “the burden is on you to turn the advice into actionable steps for succeeding in your team” and get rewarded.
- 0a month agoTech Lead @ Robinhood, Meta, Course Hero
I’m curious what the parts that are true blockers that distinguish good from great?
Great question! There's some awesome answers here: "What's the core insight behind quick growth?"
Zooming out though, it's a tricky question as there's so many "superpowers" an engineer can have. This can feel overwhelming, but overall, I think that's a huge reason why the field is so beautiful. There is so much room for creative expression as an engineer. In general, I recommend maintaining a close, honest dialogue with your manager about your strengths and weaknesses, and from there, craft a path to really expand on your strengths to add far more value to the team.
- 0a month agoMid-Level Software EngineerTaro Community
And just so I understand the superpowers aren’t saying something like oh yeah im an expert in real time data streaming or android right?
Can you give me some examples of amazing superpowers you have seen so I can get my juices flowing? This will help me talk to my manager in my 1:1 as he has identified me as a promo candidate to a senior engineer in 12-18 months.
My interpretation of an example of a superpower is stuff like “I like to thoroughly test beyond a simple functional integrated test using data analysis tools to prove correctness and performance or whatever”.
But I’m also thinking a superpower is not something like “I like to plan upfront or be nuanced about how we plan for the unique needs of every project”?
