Live data from Hacker News

Embrace the Grind

jacobian.org

101–110 of 320 posts

Re: Embrace the Grind

#101

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

Just had a meeting with some students looking to outsource some dataset validation work. I had them time themselves for a couple hours doing it themselves, and we found that seeing aside am hour a day for a couple weeks will get them through everything... And they'll end up with higher quality data than they'll get from outsourced validation, with a better idea of the pitfalls of the dataset.

Re: Embrace the Grind

#102
post #57

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

> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a r…

I agree but I wouldn't call it toxic, rather "foolish".

Re: Embrace the Grind

#103

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

> it takes a special kind of new hire

Yeah, it does. I’ve had a good amount of experience doing this. You need to have tact and a kind of humbleness that can be difficult to maintain (tbh, it was for me at least). In my most recent experience with this, many of the bugs were unknown. During my ramp up, I read through nearly all of the code I’d be working on and got a good sense of what needed to be done, but the code changes were the easy part. The issue that required more work IMO was navigating the social waters as a new hire.

I found that you can use being a new hire to your advantage, eg “hey I was reading through this piece of code and I had a question about XYZ.”

Sometimes I’ve felt certain bugs are, for one reason or another, difficult to discuss. One thing I’ve done in cases like this is to refactor a bit of code in a way that makes a subtle bug painfully obvious; then in review, where the reviewers were the original author and reviewer, it’s easier for them to see the bug and say “this looks weird,” to which I respond “ah, yeah, this seems like a bug, I’ll fix this.”

The rough part of this is that you can get so good at being the fixer that this becomes all you (ie. maybe you’re not working on new features, etc) which can suck. The bright side is that you can strengthen the team—-everyone gets a chance to build/rebuild context and mental models, design docs can be updated, and the teams foundation gets stronger as a result. Of course, ymmv.

As a new hire, I find it important to build trust and relationships.

Re: Embrace the Grind

#104
post #57

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

> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a r…

I've experienced this professionally. It's super debilitating. At some point, the only thing that you are willing to spend energy on is preventing the last fire you're exhausted from just fighting from happening again. I don't know what I'd have done if I didn't have good support from my manager at the time. He cleared a lot of expectations of other deliverables out of the way, so I could stabilize the infrastructure. Now, I know enough to work the politics to give myself room to do this work, but junior me couldn't have done it alone without cracking.

Re: Embrace the Grind

#105
post #8

It's interesting that while this often produces stunning results, it usually doesn't lead to pay increases and promotions.

> it usually doesn't lead to pay increases and promotions Individual companies may or may not reward the grind over the course of a few years. Companies that don't tend to bleed employees. These things do pay off over the course of a career, though. The Grind builds skills, builds reputation, and builds an ability to get work done when it matters. The company may not recognize the value of this, but your peers will.…

> Companies that don't tend to bleed employees.

Are there any companies that don't bleed employees? Amazon bleeds employees. Google bleeds employees. Every company I have ever worked for bleeds employees.

The only organizations I know where people regularly have 10 year stints are government agencies. Everywhere else 2-3 years.

Re: Embrace the Grind

#106
One of the best pieces of advice I ever learned was to volunteer for the jobs no one else wants to do. Shitiest job imaginable rears its head? Jump up and wave your hand like a happy idiot. Managers' sigh of relief. Who can compete with that?

Re: Embrace the Grind

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

It's a good question. i.e. if it takes a year to fix all bugs then why does order matter? The factor he did not mention is that there are unnamed people who see certain bugs and when they see those bugs, they judge the quality of the software to be poor. Thus, for human reasons you must fix certain bugs first because it makes certain people feel that the software quality is not poor. OR because certain bugs prevent t…

Human psychology is a thing. If you point a team at a growing pile of bugs that no one has wrapped their head around, then the team will feel demoralized, overwhelmed, and unmotivated. But if someone does wrangle the bug list and produce a plan and strategy for tackling them, then there is hope and mission and maybe you can even get buyin from management for more resources--maybe not headcount, but even just easing the roadmap for a year in pursuit of Quality.

The difference between "nobody has gone through this entire list" and "somebody has gone through this entire list" is huge.

Re: Embrace the Grind

#108
> You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.

Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.

Re: Embrace the Grind

#109

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

> it takes a special kind of new hire Yeah, it does. I’ve had a good amount of experience doing this. You need to have tact and a kind of humbleness that can be difficult to maintain (tbh, it was for me at least). In my most recent experience with this, many of the bugs were unknown. During my ramp up, I read through nearly all of the code I’d be working on and got a good sense of what needed to be done, but the code…

The best advice I was given (when I was a new hire, by my manager) was something along the lines of "You're smart, and you aren't burdened by tradition or seniority. If you see something that looks weird or confusing, ask about it! No one will hold it against you, and your point of view may keep us from committing to something more complex than it needs to be."

I've tried to keep that level of intentional naïveté.

Re: Embrace the Grind

#110

> You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest. Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.

Ooh, good call. I've had so many people tell me that I'm so talented in various areas that I was previously very _untalented_ (such as swing dancing). It was confusing to me for many years until I realized that the hundreds of hours I agonized over fundamentals paid off in ways that people thought I was inherently _talented_.
Post reply on HN