Embrace the Grind
jacobian.org
Embrace the Grind
1–10 of 320 posts
Re: Embrace the Grind
#2That was an enjoyable read and a gentle reminder to avoid the shiny tools and just get to work. Thanks for sharing.
Re: Embrace the Grind
#3Something similar can be said of writing survey paper in academia. Nobody wants to go through 150 papers about some godforsaken topic, but the one guy that goes through it is immediately considered to be a top notch expert.
Re: Embrace the Grind
#4That's my tactic to blend-in in a engineering team and gain some respect / credibility.
I try to find the most boring, utterly broken part, that nobody wants to touch... and I sink time into it.
Once I made it somewhat usable, I document it.
Re: Embrace the Grind
#5Alternate framing: be prepared to "Do Things that Don't Scale" (http://paulgraham.com/ds.html ) when your organization is small.
Re: Embrace the Grind
#6Thanks, I enjoyed that.
I'd like to think this applies to a lot of professionals work, putting crazy amounts of effort in for a simple outcome, that just works.
except the outcome is not as exciting as watching loads of cockroaches
Re: Embrace the Grind
#7That's my tactic to blend-in in a engineering team and gain some respect / credibility. I try to find the most boring, utterly broken part, that nobody wants to touch... and I sink time into it. Once I made it somewhat usable, I document it.
Same here. I like doing things nobody wants to do, especially when I'm new in the team.
The problem I've identified is that you're then the go-to person for the task you did in the beginning.
Example: You need to figure out how to deploy X. This is poorly documented and nobody knows how to do it.
Action: You read the code, understand what needs to be done, deploy it. Then, you document it. Finally, you create fairly basic but working automation for future deployment.
Result: Every time there's a need for redeploy, even when the code/procedure hasn't changed, you're the person the team immediately asks to do it. After all, you've automated it, shouldn't take too long, right?
Re: Embrace the Grind
#8It's interesting that while this often produces stunning results, it usually doesn't lead to pay increases and promotions.
Re: Embrace the Grind
#9That's my tactic to blend-in in a engineering team and gain some respect / credibility. I try to find the most boring, utterly broken part, that nobody wants to touch... and I sink time into it. Once I made it somewhat usable, I document it.
Same here. I like doing things nobody wants to do, especially when I'm new in the team. The problem I've identified is that you're then the go-to person for the task you did in the beginning. Example: You need to figure out how to deploy X. This is poorly documented and nobody knows how to do it. Action: You read the code, understand what needs to be done, deploy it. Then, you document it. Finally, you create fairly…
It happens at first. But point to the docs you wrote. Politely, but firmly, every time. People actually prefer being empowered to do it themselves, so they will pick it up, it just not our default when we're unsure.
Re: Embrace the Grind
#10Alternate framing: be prepared to "Do Things that Don't Scale" ( http://paulgraham.com/ds.html ) when your organization is small.
Not a fan of pg, but his schlep essay is a better alternate framing of this article (if my reading comprehension is accurate...): http://www.paulgraham.com/schlep.html