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

71–80 of 320 posts

Re: Embrace the Grind

#71

Post by beaconstudios »

fartcannon wrote: post #68
beaconstudios wrote: post #67

Earlier quoted context omitted.

It's also a mistake to think that people are static. We can improve ourselves through the expenditure of effort. The reality is like the parent said: there are limits to everybody's abilities, but you'll probably have to work hard as hell to reach yours (not targeting you personally, the general case "you"). If you believe that your present abilities are all you'll ever have then you're wasting what could be tremendo…

Who said anything about not improving, the parent comment believes the ADHD sufferer is simply not working hard enough. He's trying to show him where his bootstraps are.

People who are currently struggling can fall into a self limiting mindset. I can attest to that from personal experience. I don't have ADHD, but I can imagine that having it might make you believe that you couldn't improve your attention at all. The reality is that you might just be able to, even though it would probably much harder than for the general population - in the same way that an underweight person would find it harder to build muscle than someone of average build.

From my perspective it's a positive message, not finger wagging at the impaired.

Re: Embrace the Grind

#72

Post by ZephyrBlu »

PragmaticPulp wrote: post #30

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…

I think being able to sit down and do work is more about removing distractions than improving focus.

Also, I'm curious about these statements:

> 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

Really? Who believes this and why?

> 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

Do they give you a reason? This seems pretty odd.

Re: Embrace the Grind

#73

Post by dopidopHN »

hinkley wrote: post #24
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…

Important distinction you’re making.

For me the litmus test is documentation.

Make a active effort to at least explain in plain English was the grind is and what it’s is purpose, then having a stab at documenting the steps.

It’s never a one time thing. Most likely you need to do it a few time manually. You won’t get all the steps right, and automating it will likely be a tall order; otherwise it would be done already.

But like you said I encounter groups of engineers that transform the grind into a cottage industry. They don’t publish their knowledge, they are the expert on it and one of the few group that can execute on those story. It’s depressing.

And you demasked me: by making it better and more documented I want to kill the grind. Or at least offload it to another group. ( BA, users, OPS running grind.sh )

Re: Embrace the Grind

#74

Post by WindyLakeReturn »

Unlike many comments here, this doesn't resonate with me. Grinds have always had some part that benefits from automation. Rarely can the whole thing be automated in any reasonable timeframe, but individuals parts can easily be. Often the magic is that those around me don't even realize that you can partially automate it so they end up thinking I did it all by hand.

There is a trap in over thinking the automation. Sometimes the partially manual solution takes an hour full while automation takes 8. But I'm failing to think of a time in my career where a grind was repetitive and fully manual but not improved by some trick of automation. Notepad++, regex, and your language of choice builds a very powerful set of automation for virtual problems. For the enhanced suite, toss in a library to get data to and from excel and access and another to navigate and scrape HTML pages.

Re: Embrace the Grind

#75

Post by titzer »

This is such a great article. It's the same reason I wrote an assembler, from scratch, by hand, and now I'm writing a fast interpreter in it. Nobody thinks this is a particularly fun thing. :)

Re: Embrace the Grind

#76

Post by lostcolony »

didibus wrote: post #26

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'r…

Partly, yeah.

If priority isn't clear, you spend hours on a bug, realize it's minor, realize the fix is difficult...and extrapolate that to the remainder of them. Morale sucks.

If someone can stomach sorting through them, then at least you know you're working on the most important bug at any given time.

Re: Embrace the Grind

#77

Post by aspaceman »

jldugger wrote: post #45

> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…

> And it takes a special kind of new hire to have the expertise to parachute in, recognize that work needs to be done, and then do it with little supervision.

About 6 months into a job I realized this was what I needed to do and totally cracked. Didn’t know the questions to ask or the way to learn what I needed to so I burnt out quick and quit. My fault for sure, but there was a ton of pressure to identify issues and fix them because senior people were “just too busy”.

Re: Embrace the Grind

#78

Post by rufius »

jldugger wrote: post #45

> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…

Honestly, I’d have approached it differently.

Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed.

This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead.

Put another way - if everything is important or “must fix”, nothing is.

So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.

Re: Embrace the Grind

#79

Post by marcosdumay »

didibus wrote: post #26

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'r…

My guess is that the noise of new bug reports was incapacitating the team. You can't fix anything if each few minutes somebody comes to complain about a new problem.

But with the bugs organized he could filter the repeated reports and let people work. As a bonus, he could direct people into solving the largest troublemakers first too, so things get quieter faster.

Re: Embrace the Grind

#80

Post by courtf »

The real magic behind that bug triage anecdote isn't the tedious work it took to get there, it's that a year later anyone noticed, gave a shit, or gave credit where it was due. In 9/10 organizations, such outcomes never materialize because no one is working for the common good, nor cares about silly little things like old bugs. Often there simply isn't time. You are instead being yanked from meeting to meeting, thrashing from one poorly defined management prerogative to another, because no one outside the code base has any understanding of what it actually takes to build a stable product nor do they really care.
Post reply on HN