Live data from Hacker News

Embrace the Grind

jacobian.org

171–180 of 320 posts

Re: Embrace the Grind

#171

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

I feel like by far the biggest impediment to my productivity is the knowledge that I have a meeting any time in the next two hours. Unfortunately, that's usually the case.

Re: Embrace the Grind

#172

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…

[deleted]

Re: Embrace the Grind

#173
post #10

Earlier quoted context omitted.

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.

ah yes, his own submarine topic ;)

http://www.paulgraham.com/submarine.html

Re: Embrace the Grind

#174
post #165
post #157

Earlier quoted context omitted.

I think the oldest bug I've raised that's still open is this Webkit one from 2008 [1]. It still gets plaintive comments from various people every few years. A few more and it'll be going off to college. [1] https://bugs.webkit.org/show_bug.cgi?id=22261

> We are fixing in Blink (c2103)

That's no help for Safari. Personally I haven't needed to care about Safari in half a decade, but presumably others still do.

Re: Embrace the Grind

#175

Earlier quoted context omitted.

The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period. This context is really valuable when reasoning about the product or determining what's important to prioritize. The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same po…

I have to agree. There is nothing more demotivating for me than documenting a bug thoroughly, only to have it returned to me two months later as part of a bulk 'we didn't get to this in time' cleanup. Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.

And yet this is what several open source projects do, including VSCode. They've even automated the process. If there's no action on a bug for X amount of time it's auto-closed.

Re: Embrace the Grind

#176

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

I tend to be verbose in tracking bugs, but poor in tagging, categorizing, and prioritizing them.

Ultimately, I've found the important bugs prioritize themselves no matter how sloppy your system is. The rest of the bugs are simply there to (1) provide context, reference (2) serve as fallback if product work tends to lag.

Re: Embrace the Grind

#177
post #78

Earlier quoted context omitted.

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.…

We're doing it in my current company and we lose a lot of valuable data. On top of this, other teams are not encouraged opening a bug anymore because no-one will fix it. It's great for individual contributors who don't care about understanding the product and are probably going to be in another team in 3 months. In a previous job I did what the author did and it helped building an understanding of the project and wit…

I've found a happy medium is to have a garbage collection section of the backlog. You'll probably never touch it, but having the data can be important.

Re: Embrace the Grind

#179

OK, so you spend hours and days sealing threes of clubs into tea packets. But how do you make the volunteer pick the three of clubs during the show?

Forget the three of clubs, how you stop the volunteer from picking a second packet to check for the most obvious solution? You have to be incredible dumb to not check it.

Re: Embrace the Grind

#180
post #10

Earlier quoted context omitted.

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

Out of curiosity, why not a fan of PG?

[deleted]
Post reply on HN