Live data from Hacker News

Embrace the Grind

jacobian.org

31–40 of 320 posts

Re: Embrace the Grind

#31

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…

Definitely agree with that.

My own personal experience with difficult bugs is that there is no substitute for taking the time to understand the problem domain, the systems involved, and the code itself. Getting to that point takes significant investment though, and I tend to trust engineers who are willing to do that much more than engineers who don't.

Re: Embrace the Grind

#32
The big question is, what's the reward? Magicians need to do tricks to eat. But what's the incentive to pulling off the impossible, as opposed to being a workaday employee, at the employer where the impossible was pulled off?

I don't mean to imply there is no incentive, I'm saying - what is it? If it's there and it justifies the effort, great. If not, you might as well be doing magic tricks at a party.

Now, some people like to be the fun guy at a party who can pull a quarter from behind your ear. If that's a fitting reward for you, then great! For me, that, or being able to write a blog post such as this one, would be a bit thin to justify it.

Re: Embrace the Grind

#33
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 an…

Personally I don't like facing the work to take something from 80-100% - I envision the potential work and I can see it laid before me, extending beyond the horizon. And sometimes that work doesn't even lead to a certain success.

I realize that more often than not it would likely lead to improvements and a better state of the world. But it can feel overwhelming at times. Whereas working on a shinier smaller thing brings feelings of gratification that much easier and faster.

Re: Embrace the Grind

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

One of my favorite magicians: Derren Brown

He does a coin flip trick where he flips a fair coin 10 times in a row and gets heads every time.

https://www.youtube.com/watch?v=XzYLHOX50Bc

The amount of time and effort he puts into this and other illusions is very large.

Re: Embrace the Grind

#35
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 the system actually doing what it is meant to do .... thus the bugs that result in the system failing to serve its purpose must be done first.

Re: Embrace the Grind

#36
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 an…

For me it's that 1) most people won't even care and 2) someone is going to ruin it anyway, eventually.

I've observed a cognitive dissonance that I can't quite put my finger on. You'll work with (and for) people who have an extreme admiration for Apple products because of the attention to detail and quality. And yet they are perfectly fine churning out terrible technology products in order to make a buck. Often times just little attention to detail can make a huge difference; you don't need to be a zealot about it.

Loosely related: I've found that I've made the most money while working with bad teams on terrible technology products. And I've made the least money working with great teams on great products. I really hate that.

Re: Embrace the Grind

#37
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 might be investing in tackling it, but I would guess that, more than that, it's that one person was tasked with doing it.

The problem with tedious grind work is, if it's a communal responsibility, then everyone will just sit around waiting for someone else to take care of it.

Re: Embrace the Grind

#38
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 an…

By the time you grind to get that 100% perfect solution, the number of requirements the business has put on you in your backlog has extended well beyond what you can keep up with. It's not like software engineers are the only actors in a software system. They are reactive to the needs of product development who are reactive to the needs of customers. You have to balance your limited development resources against a constantly changing set of requirements.

So you make trade-offs.

Re: Embrace the Grind

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

> Maybe a similar sort of thing with software would be spending time on animations -- the result is a cool flourish, but it lasts 0.15 seconds and it took 3 days to get it just right, and it's impossible to quantify how worthwhile it was beyond a gut feeling. Even still, that's not even in the same ballpark in terms of time or effort.

The difference is that movies are all or nothing productions in an industry set up for a waterfall process with directors who exert creative control. Everything from dealflow to billing to the unions are set up to support the industry's unique requirements. They do the same kind of budget triage as software companies do, but they emphasize the creative aspect far more relative to tech since they're competing over form not function.

The nearest creative equivalent would probably be Jobs-era Apple but I think the best analog would be NASA, whose missions are dictated by scientific and exploratory goals outside of their control. Except instead of an artistic direction, they have to contend with physics that dictates they spend extreme resources on seemingly trivial details like what tape or writing implement works best in zero-g.

Post reply on HN