This is so spot on. Two things:
1. Being focused on producing output the fastest way possible means that you will never prioritize "going deep"
2. Going deep (and down the rabbit hole) is how you learn more: but you need to balance it.
Figure out how to do both: it's tricky!
1. Being focused on producing output the fastest way possible means that you will never prioritize "going deep"
2. Going deep (and down the rabbit hole) is how you learn more: but you need to balance it.
Figure out how to do both: it's tricky!
Comments
OTOH, that’s clearly hopeless because people don’t assume that of other people. 😀
Turning that into fast output (blog post with learnings) is hard for me, but future iterations produce more quality.
Probably 60 hours hitting head against the wall, all in.
It is hard though! Difficult to justify that level of research on company time.
Having helped setup eng at incident, I’ve had a huge focus on few/simple tools & enabling eng to work without going deep on infra.
Whenever eng end up too deep on infra details that’s a smell for me. But it’s where I learned a lot myself…
Someone who is putting a lot into the team can rightly pull time back to go deep into areas that are mutually beneficial to learn.
But even so, past a point and it’ll be on your own time!
If they are: they understand the value (and cost) of going deep. They might even help! If they are not: they will see this as "slacking" or "being slow"
When I encounter a bug and have no idea what is going on, it shows me that my mental model is wrong. So I begin peeling away the abstractions until I can properly fix it.
Using that new understanding, I can often spot many more defects in the same codebase.
The fix in place was "just reload the entire SPA". It worked, but it was fixing a symptom.
By diving deep, I learned about the framework and the gap in the owners of the web app.