Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embrace the Grind

jacobian.org

Post reply on HN
Print view View original

21–30 of 320 posts

Re: Embrace the Grind

#21

Post by trentnix »

barbiturique wrote: post #4

That'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.

Good stuff.

I've found that, as a manager, forcing the grind is also a useful tactic to get a new team member involved. Assign a challenging task that addresses a shared pain point and that requires some measure of tedium and lots of effort.

Not only will the completed work result in a new team member being accepted and respected (as you've experienced), the new team member will also develop a sense of value and ownership in the project. The faster new team members get through that period where they feel like an outsider to where they feel like they are contributing value, the better.

Re: Embrace the Grind

#22

Post by chrchang523 »

gkop wrote: post #10
chrchang523 wrote: post #5

Alternate 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

I had forgotten that the schlep essay was distinct. Interesting that they don't refer to each other.

Re: Embrace the Grind

#23

Post by munchbunny »

dceddia wrote: post #16

This quote stuck out to me: > More trouble than the trick was worth? To you, probably. But not to magicians. It makes me realize how fundamentally different the values are between some fields. The amount of time magicians put into the craft is mind-boggling. I see it also with how movies are made -- to think that sometimes they're spending days or months and tens of thousands of dollars, building sets, waiting for th…

I don't think it's that software engineers don't value it. I think we all understand, to some degree, that building resilient, simple software that solves the problem thoroughly requires incredible investment into carefully thinking through the problem and constant upkeep. It's just that we don't want to believe it because getting from 80% to 100% requires boring grind that we'd rather spend building something new and exciting, or because getting from 80% to 100% requires time we could spend building 80% of something else we want to sell.

Re: Embrace the Grind

#24

Post by hinkley »

barbiturique wrote: post #4

That'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.

I think in some ways this strategy, which I also employ, is rejecting the grind, rather than embracing it.

Generally I have coworkers who embrace the grind - One group happily show up to do some mind numbingly manual and error prone process, even going beyond apologizing into protecting it. That's one form of job security, but it leeches talent from the company. The other group abhors it and will try to do literally anything else to avoid going through it, including making all new things that turn out to be almost as bad (and never quite managing to get rid of the original).

Going through the grind a couple times and making sure that nobody else has to go through it ever again is acknowledging the grind, and then doing something about it.

Re: Embrace the Grind

#25

Post by mathgladiator »

dceddia wrote: post #16

This quote stuck out to me: > More trouble than the trick was worth? To you, probably. But not to magicians. It makes me realize how fundamentally different the values are between some fields. The amount of time magicians put into the craft is mind-boggling. I see it also with how movies are made -- to think that sometimes they're spending days or months and tens of thousands of dollars, building sets, waiting for th…

The key word is marginal. Sadly, software tends to align against art as pushing boundaries is marginal for the return of investment.

I can provide an example. I'm writing a programming language, database, and platform to power board games. http://www.adama-lang.org/

Most of my personal investments are marginal to most businesses (or deeply incompatible). If was going to run this as an enterprise, then this would be a death sentence. However, my hope is that when I get this thing moving, then I can ship games quickly with exceptional and redefining reliability.

The only reason I can pursue this as an art is that I'm close to retirement.

Re: Embrace the Grind

#26

Post by didibus »

Maybe this is a naive question, but why couldn't you just pick a bug at random, fix it, and move to the next? You said eventually you worked through all issues in about a year of time. How did having the issues prioritized from the get go really mattered, if you ended up closing them all anyways?

If I had to guess, the magic trick was simply investing in tackling all the bugs one after another for a year until they're all closed out. Maybe you needed to triage them all to convince people to invest in doing this?

Re: Embrace the Grind

#27

Post by hinkley »

mdpye wrote: post #14
barbiturique wrote: post #4

That'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.

I hadn't realised it til now, but I do the same. It's a really great way to get started, because it tends to coincide with not having yet gained a broad range of responsibilities pulling you in different directions. You become a domain expert in something (which was probably lacking across the team) and peers appreciate it. After they've seen that, you organically start getting invited to all kinds of more interestin…

One of my 'secrets of my success' moments was realizing that one of the grind areas I reject has to do with the all of the processes of building the application. You stare at that stuff long enough and you might not know how the application does what it does, but you have a pretty good idea of where it does them.

And inasmuch as you've also improved the testing situation, you've also created a system that allows you to iterate faster, which you are intimately familiar with, allowing you to poke at the system in a way that provides you feedback on your hypotheses. Meaning you can learn about the rest of the system on your own schedule instead of being hand-fed bits of tribal knowledge (which often turns out to no longer be entirely correct anyway).

Re: Embrace the Grind

#28

Post by aidos »

bluquark wrote: post #17

My secret weapon for bug diagnosis is that when a regression is reported on a system without an automatic bisect tool, while everyone else is trying to reason about the problem with guesswork and code inspection, I sit down and spend 2 hours just bisecting manually (full sync, rebuild and install of old versions of the software). This provides a guaranteed culprit CL, often one that no one guessed, and also a potenti…

That approach works well for regressions. I’ve used it myself to track down a bug in chrome and, as you say, having no idea how to fix it, I could direct it to the author via the bug tracker. In my case it was fixed within a couple of days. And obviously bisecting chrome is a slow process, but it only took a couple of hours.

I find that most bugs don’t fall into that class, and for the most part, just sitting and picturing the paths back from the bug is enough to work out what’s going on. If you’re less familiar with the code you’ll want it in front of you to trace your way back. In general you can narrow the search space pretty quickly.

Re: Embrace the Grind

#29

Post by mensetmanusman »

dceddia wrote: post #16

This quote stuck out to me: > More trouble than the trick was worth? To you, probably. But not to magicians. It makes me realize how fundamentally different the values are between some fields. The amount of time magicians put into the craft is mind-boggling. I see it also with how movies are made -- to think that sometimes they're spending days or months and tens of thousands of dollars, building sets, waiting for th…

The movie thing is a good example. I remind my kids that some of these movies cost $1,000,000/minute to make. That might be what they make in their lifetime, so it is about that many hours of work per minute (a life’s work).

Re: Embrace the Grind

#30

Post by PragmaticPulp »

When I joined a mentoring program targeted at recent college grads, I expected to be teaching things like interview prep, resume writing, negotiation skills, communication skills, and how to deliver results in a workplace.

For about half of the mentees, that's roughly true. However, for the other half much of my mentoring ends up being about time management, following through on commitments, and putting in the effort required to get a job done. A surprising number of young people are graduating college without ever having had to work any job. It's particularly difficult for talented coders who breezed through easy CS programs until they land in a work environment where tasks are challenging, expectations are high, and the only way to get things done is to sit down and put in the effort.

One of the best skills anyone can learn is how to sit down, focus, and get work done. In my experience, it's increasing challenging to convince young people that this is an acquired skill that they can practice and develop. There's a growing perception that traits like work ethic, focus, and motivation are fixed attributes that one is born with (or without) rather than abilities that are developed over time. It's frustrating to watch some mentees map out meticulous diet and exercise programs to improve their physical strength, but then turn around and tell me that they're only capable of coding for 2 hours per day as a sort of fixed upper limit. Like everything, the ability to work and focus can be developed over time with practice and dedication. It's worth it.

Post reply on HN