Embrace the Grind • Hacker News Board

Re: Embrace the Grind

#151

Post by piyh » Sat, Apr 10, 2021, 1:35 AM UTC

phpnode wrote: post #44

david422 wrote: post #34

Earlier quoted context omitted.

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.

I used to be a big fan of Derren Brown when I was younger, and I do still like a lot of his work, but he readily admits to deceiving the audience, and the deception includes the explanations he gives for his techniques. The video you linked to was part of a longer show (The System) which gives an explanation for how this trick was done - he says they kept filming take after take, for 9hrs, until they finally got ten…

He wrote Tricks of the Mind and that was a great book. One piece that has stuck with me for ~15 years now is the 20 word series that I can recite forward or backward after spending 5 minutes visualizing them in a "linked list". For example, telephone - sausage - monkey. Vividly imagine dialing a payphone with a sausage. Next up, sausage monkey. Vividly, using all your senses imagine a monkey flinging sausages to the point of absurdity where he's swimming through sausages.

You just created a mental linked list that you can traverse from either direction, and that you'll remember for as long as you want to. Push it to the extremes, build up your method of loci to arbitrary lengths, build your memory palaces and become Hannibal Lecter.

Re: Embrace the Grind

#152

Post by titanomachy » Sat, Apr 10, 2021, 1:48 AM UTC

heterodoxxed wrote: post #142

jokethrowaway wrote: post #113

Earlier quoted context omitted.

I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years. We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day. This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 20…

I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that wo…

The people who do this job at large companies are called Staff or Principal engineers. One reason startups might be less likely to have them is that they are extraordinarily expensive.

Re: Embrace the Grind

#153

Post by ilaksh » Sat, Apr 10, 2021, 1:49 AM UTC

I want to apply this grinding idea to hard technical challenges that could take many months or even years. For example, neural networks applications. My understanding is that the principles were around for years but the idea was largely dismissed because of poor practical performance. But by grinding, they worked out things about how to initialize and activate etc. that made it work.

Re: Embrace the Grind

#154

Post by Aeolun » Sat, Apr 10, 2021, 1:52 AM UTC

heterodoxxed wrote: post #142

jokethrowaway wrote: post #113

Earlier quoted context omitted.

I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years. We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day. This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 20…

I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that wo…

> The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project

The problem being. People don’t want to hear that it’s going to take them a while to get from 0 to 100%. They’d rather hear they can get from 0 to 99% in a day, then spend a month slogging through that last percent.

Re: Embrace the Grind

#155

Post by outime » Sat, Apr 10, 2021, 1:54 AM UTC

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…

>Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.

As a person who’s worked in both american and european big companies... I can tell it’s not an american illness only and I have heard the same from asian friends. Best I got was one or two meeting-free days (at least on paper, in reality these would be ignored as well). I just got used to these things.

Re: Embrace the Grind

#156

Post by analog31 » Sat, Apr 10, 2021, 1:54 AM UTC

Any sufficiently unpleasant task is indistinguishable from magic?

Re: Embrace the Grind

#157

Post by mrec » Sat, Apr 10, 2021, 1:54 AM UTC

pixl97 wrote: post #130

EmptyMoon wrote: post #95

Earlier quoted context omitted.

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.

A bug left alone long enough grows from an child bug to an adult bug. You're still caring, feeding, and maintaining that bug the entire time.

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

Re: Embrace the Grind

#158

Post by narshian » Sat, Apr 10, 2021, 1:55 AM UTC

ZephyrBlu wrote: post #117

narshian wrote: post #86

Earlier quoted context omitted.

No it’s not. Speaking as someone who specifically has this problem: even eliminating all possible distractions does not do the trick.

Which problem exactly? Not being able to sit down and code for more than 2 hours?

>Which problem exactly? Not being able to sit down and code for more than 2 hours?

Yes.

Re: Embrace the Grind

#159

Post by Aeolun » Sat, Apr 10, 2021, 1:55 AM UTC

emodendroket wrote: post #119

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…

If the meeting is on a calendar ahead of time it's not really an interruption.

I don’t know how you work, but my schedule of meeting, work, meeting, work definitely feels like the meetings are interruptions.

Especially since they don’t add any value, but that’s arguably a different problem.

Re: Embrace the Grind

#160

Post by edoceo » Sat, Apr 10, 2021, 1:59 AM UTC

jokethrowaway wrote: post #113

pbourke wrote: post #57

Earlier quoted context omitted.

> 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 think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years. We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day. This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 20…

We do: we've identified this is the most important bug; work it till its "done" so we can't task-shift that work till its done. No daily (or less) priority shift.