[HN Gopher] Embrace the Grind
       ___________________________________________________________________
        
       Embrace the Grind
        
       Author : karl42
       Score  : 348 points
       Date   : 2021-04-09 06:29 UTC (16 hours ago)
        
 (HTM) web link (jacobian.org)
 (TXT) w3m dump (jacobian.org)
        
       | annoyingnoob wrote:
       | I have to wonder what magicians think of the 80/20 rule. The
       | trick probably needs all 100% and the grind it takes to get
       | there.
        
       | 5cott0 wrote:
       | Everybody's other favorite German word: "sitzfleisch".
        
       | didibus wrote:
       | 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're
       | all closed out. Maybe you needed to triage them all to convince
       | people to invest in doing this?
        
         | marcosdumay wrote:
         | 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.
        
         | paxys wrote:
         | The effort to impact ratio is wildly different among bugs in a
         | large backlog. Sometimes a 10-minute single line change will
         | produce a massive benefit for all users. Other times a
         | developer can slog on a bug for weeks only to realize that no
         | one cares about the fix anymore. You want to start tackling the
         | ones in the first category before spending time on the second.
        
         | andrewstuart wrote:
         | 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.
        
         | lostcolony wrote:
         | 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.
        
         | thrower123 wrote:
         | Quite often what happens in these cases is that people get
         | paralyzed looking at the list of open things, and rather than
         | just digging in and doing something to chip away at the pile,
         | there are meetings and discussions and noise which generates a
         | lot of heat and sound and stress, but doesn't actually make any
         | positive progress towards resolving the issues.
         | 
         | An meanwhile things keep getting thrown on the pile.
        
         | mumblemumble wrote:
         | 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.
        
       | barbiturique wrote:
       | 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.
        
         | hinkley wrote:
         | 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 anything else to avoid going through it, including
         | making all new things that turn out to be almost as bad (and
         | never quite managing to get rid of the original).
         | 
         | Going through the grind a couple times and making sure that
         | nobody else has to go through it ever again is acknowledging
         | the grind, and then doing something about it.
        
           | dopidopHN wrote:
           | 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 )
        
         | mdpye wrote:
         | I hadn't realised it til now, but I do the same. It's a really
         | great way to get started, because it tends to coincide with not
         | having yet gained a broad range of responsibilities pulling you
         | in different directions. You become a domain expert in
         | something (which was probably lacking across the team) and
         | peers appreciate it.
         | 
         | After they've seen that, you organically start getting invited
         | to all kinds of more interesting projects and discussions.
        
           | hinkley wrote:
           | One of my 'secrets of my success' moments was realizing that
           | one of the grind areas I reject has to do with the all of the
           | processes of building the application. You stare at that
           | stuff long enough and you might not know how the application
           | does what it does, but you have a pretty good idea of _where_
           | it does them.
           | 
           | And inasmuch as you've also improved the testing situation,
           | you've also created a system that allows you to iterate
           | faster, which you are intimately familiar with, allowing you
           | to poke at the system in a way that provides you feedback on
           | your hypotheses. Meaning you can learn about the rest of the
           | system on your own schedule instead of being hand-fed bits of
           | tribal knowledge (which often turns out to no longer be
           | entirely correct anyway).
        
           | piva00 wrote:
           | I don't like to chime in with "seconding" on HN but I had the
           | same eureka moment about it. I have definitely always behaved
           | like that and it was just a natural and organic way to start
           | in any team or job.
           | 
           | I got a bit shocked because I realised this behaviour
           | repeated this past year when I changed jobs. I became a
           | domain expert in an obscure part of the codebase and have
           | been documenting it and sharing the knowledge for a while
           | now.
        
         | BossingAround wrote:
         | Same here. I like doing things nobody wants to do, especially
         | when I'm new in the team.
         | 
         | The problem I've identified is that you're then the go-to
         | person for the task you did in the beginning.
         | 
         | Example: You need to figure out how to deploy X. This is poorly
         | documented and nobody knows how to do it.
         | 
         | Action: You read the code, understand what needs to be done,
         | deploy it. Then, you document it. Finally, you create fairly
         | basic but working automation for future deployment.
         | 
         | Result: Every time there's a need for redeploy, even when the
         | code/procedure hasn't changed, you're the person the team
         | immediately asks to do it. After all, you've automated it,
         | shouldn't take too long, right?
        
           | mdpye wrote:
           | It happens at first. But point to the docs you wrote.
           | Politely, but firmly, every time. People actually prefer
           | being empowered to do it themselves, so they will pick it up,
           | it just not our default when we're unsure.
        
           | kache_ wrote:
           | Pair with someone else and have them do it, and be explicit
           | about your intention to share the knowledge.
        
           | pilchard123 wrote:
           | Never become the guy who can fix the printer.
        
         | trentnix wrote:
         | Good stuff.
         | 
         | I've found that, as a manager, forcing the grind is also a
         | useful tactic to get a new team member involved. Assign a
         | challenging task that addresses a shared pain point and that
         | requires some measure of tedium and lots of effort.
         | 
         | Not only will the completed work result in a new team member
         | being accepted and respected (as you've experienced), the new
         | team member will also develop a sense of value and ownership in
         | the project. The faster new team members get through that
         | period where they feel like an outsider to where they feel like
         | they are contributing value, the better.
        
       | chrchang523 wrote:
       | Alternate framing: be prepared to "Do Things that Don't Scale"
       | (http://paulgraham.com/ds.html ) when your organization is small.
        
         | gkop wrote:
         | 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
        
           | chrchang523 wrote:
           | I had forgotten that the schlep essay was distinct.
           | Interesting that they don't refer to each other.
        
       | WindyLakeReturn wrote:
       | 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.
        
       | tarunkotia wrote:
       | Few months ago I posted on HN asking the same thing. The author
       | addresses it pretty well with a good example.
       | https://news.ycombinator.com/item?id=25010373
        
       | longformworks wrote:
       | That was an enjoyable read and a gentle reminder to avoid the
       | shiny tools and just get to work. Thanks for sharing.
        
       | courtf wrote:
       | 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.
        
       | MacroChip wrote:
       | Every time I hear about the "Three virtues", I always think
       | "Well, there's 'laziness' and there's _laziness_ ". I know when I
       | or someone else is being 'lazy' or _lazy_. Same thing for the
       | other virtues. This is why we appreciate those who embrace the
       | grind.
        
       | PragmaticPulp wrote:
       | 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 required to get a job done. A surprising number of young
       | people are graduating college without ever having had to _work_
       | any job. It 's particularly difficult for talented coders who
       | breezed through easy CS programs until they land in a work
       | environment where tasks are challenging, expectations are high,
       | and the only way to get things done is to sit down and put in the
       | effort.
       | 
       | One of the best skills anyone can learn is how to sit down,
       | focus, and get work done. In my experience, it's increasing
       | challenging to convince young people that this is an acquired
       | skill that they can practice and develop. 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. It's frustrating to watch
       | some mentees map out meticulous diet and exercise programs to
       | improve their physical strength, 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. Like everything, the ability to work and
       | focus can be developed over time with practice and dedication.
       | It's worth it.
        
         | ReactiveJelly wrote:
         | I'm not gonna disagree but I want to add a couple things.
         | 
         | 1. Kids with ADHD probably can't develop executive function as
         | fast or as far as other kids. I'm pretty sure I have it, it
         | explains the repeated performance reports of "You're good when
         | you apply yourself and useless when you don't." Unfortunately I
         | struggle to _choose_ to apply myself.
         | 
         | Willpower doesn't seem to come naturally to me, even after 10
         | years as a professional programmer. Adderall didn't help - I
         | had to take it in the morning, after breakfast. So I was still
         | late for work, because eating breakfast is not something I'm
         | good at, and I couldn't start my day until I had finished
         | breakfast. Then after work the stimulants wore off and I felt
         | like shit and reverted to my normal do-what-i-want executive
         | function. But it made me feel normal without caffeine.
         | 
         | So I quit the Adderall and just cutting caffeinated soda with
         | non-caff every morning, as though I was lowering my dose on a
         | prescription. So far it's working. I still never clean my room,
         | which is status quo for the last 20 years, and work is still
         | pretty easy. The phrase "idiot savant" comes to mind. All I
         | want is for people to stop thinking that I'm doing this on
         | purpose. I don't enjoy constantly feeling like a moron and
         | being behind on simple household chores despite making decent
         | money at a job that is considered (by other people) to be
         | difficult.
         | 
         | And that might even be the case for the kids with detailed
         | exercise programs. I don't exercise at all because it's not my
         | interest. I program, because it is my interest. Kinda like how
         | autistic people can't choose their special interests. I pity
         | the kids whose interest is exercise but are trying to force
         | themselves through a CS program into a career track they can't
         | possibly do.
         | 
         | Dr. Russell Barkely goes into some detail in a 3-hour talk
         | about ADHD here: https://www.youtube.com/watch?v=YSfCdBBqNXY If
         | anyone thinks I don't have ADHD because I sat through a 3-hour
         | talk about psychology, maybe they need to watch it, too.
         | 
         | "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."
         | 
         | What if they are, though? What if it's like height, where
         | genetics sets a range and environment picks a point in that
         | range? If I had starved as a child, I would be shorter than I
         | am now. But if I had eaten more, I would not be taller. I'm
         | about the same height as my parents are.
         | 
         | There's a hypothesis that the current age of mass distraction
         | (TV, phones, Internet, etc.) doesn't _cause_ ADHD, but it does
         | _aggravate_ it. I don't know if the studies bear it out, but I
         | really want this to be true. What if it's something that's
         | latent in the human genome, and the fact that we can profit off
         | of exploiting it nowadays just brought it to the surface? In
         | early centuries, if I had nothing to do but my work, maybe I
         | would find it easy to just "accept boredom" and do my work
         | anyway.
         | 
         | 2. I'm not sure how many employers would have hired me in
         | college. I get the sense that unskilled labor just isn't worth
         | much anymore, and pushing kids to get more education is kicking
         | the can down the road since, as you pointed out, nobody wants
         | to hire an adult with zero work experience whether they're 18,
         | 22, or even 30.
        
           | PragmaticPulp wrote:
           | ADHD is a difficult topic to discuss on HN. I'll preface this
           | by saying that I'm not doubting your situation, or any other
           | commenter's particular situation. This [section of my]
           | comment is meant to be general:
           | 
           | In the context of this mentoring group, we go through phases
           | where almost _everyone_ suspects they have ADHD for various
           | reasons. This is usually triggered by one of two things:
           | Either someone shares an online  "Do you have ADHD quiz?"
           | that is sponsored by Takeda or another ADHD medication
           | manufacturer, or a front-page Reddit infographic
           | misrepresents ADHD as something like "Do you some times
           | forget people's names? Maybe you have ADHD!"
           | 
           | The reality is that ADHD is very challenging for those that
           | have it, but the pop-culture definition of ADHD has become so
           | vague that people who _don 't_ have ADHD are increasingly
           | convinced that common life experiences are symptoms of ADHD.
           | 
           | Focusing is hard. Studying is hard. The Grind is hard. It's
           | normal to struggle to focus, but it's even more of a struggle
           | for those with ADHD. However, having to work to focus for
           | extended periods of time, in and of itself, is not an ADHD
           | symptom, it's just life. ADHD is a much more severe
           | impediment.
           | 
           | (Again, not referring to the parent comment): Anyone curious
           | should avoid self-diagnosis and seek a trusted professional.
           | Ideally not a family doctor who simply writes prescriptions
           | on request, but someone who can recommend self-guided therapy
           | programs and combination treatment. Adderall isn't all it's
           | made out to be, especially after the initial motivating
           | effects wear off and you're left with the realities of long-
           | term stimulant use, which are nowhere near as exciting as the
           | first few doses.
           | 
           | > What if they are, though? What if it's like height, where
           | genetics sets a range and environment picks a point in that
           | range? If I had starved as a child, I would be shorter than I
           | am now. But if I had eaten more, I would not be taller. I'm
           | about the same height as my parents are.
           | 
           | Genetics and upbringing may set a baseline for focus and
           | motivation, but those traits are demonstrably not set in
           | stone. Contrary to your example, diet _does_ have a
           | significant influence on height, but it 's not the sole
           | determinant.
           | 
           | Height isn't a good example, though. Consider something like
           | running capacity. Some people are naturally more athletic
           | than others, but barring severe disorders, everyone can
           | develop more running capacity through training. Someone who
           | gives up and never tries to increase their capacity may not
           | believe this, but it's true. An average person can't simply
           | work their way up to competing with Olympic sprinters blessed
           | with perfect genetics, but they can significantly increase
           | their running capacity from baseline by putting in the work.
           | 
           | Likewise, attention is a learned skill. Some have more
           | baseline attention span than others, but it _can_ be
           | increased through training and practice. ADHD modulates this,
           | but it doesn 't prevent practice from helping. If anything,
           | people with ADHD need to invest more effort into training
           | their attention spans than those without.
           | 
           | > Willpower doesn't seem to come naturally to me, even after
           | 10 years as a professional programmer. Adderall didn't help
           | 
           | Adderall and other stimulants don't provide willpower,
           | contrary to popular belief. Only people without tolerance
           | will experience a temporary motivation boost from stimulants.
           | This effect diminishes as tolerance sets in, which is one of
           | several reasons why drugs like Adderall aren't successful for
           | treating disorders like depression.
           | 
           | Willpower is another learned skill. Expecting it to come
           | naturally won't work forever. You have to learn to embrace
           | the grind, do the work, and power through the urges to give
           | up and do something easier if you want to get anywhere.
           | 
           | > I don't exercise at all because it's not my interest.
           | 
           | The reality is that the things we need to do aren't always
           | going to line up with the things we like to do. You're lucky
           | that you have a natural interest in programming, but you
           | can't expect every necessary activity to have a natural
           | interest behind it. Some amount of physical activity is
           | essentially required for a healthy existence. You may not be
           | interested in it, but that doesn't exempt you from requiring
           | it and it certainly doesn't mean you won't benefit from it.
           | 
           | Some times the things we have to do in life aren't
           | immediately enjoyable. It's on us to find ways to make them
           | more enjoyable (e.g. find a sport you like, or take up
           | walking), and some times we just have to do the unenjoyable
           | thing for the sake of progress.
        
             | whimsicalism wrote:
             | IMO any chance of there being a constrained and clearcut
             | definition of ADHD went out the window in affluent
             | communities as soon as they started giving people test
             | extensions if they were diagnosed with it.
             | 
             | I say that as someone who definitely has something
             | neurodivergent going on, as I do not know other people who
             | get excited and have to pace around the house flapping
             | their hands.
        
             | fartcannon wrote:
             | Your comment makes me think of when they first designed jet
             | cockpits for pilots. It was expensive to modify the planes,
             | so they designed it to the 'average' person.
             | 
             | The result is that no one fit in it.
             | 
             | Expectations that other people can perform like you do if
             | they just put their mind to it is so blind to the reality
             | of human experience that it's hard to respond.
             | 
             | https://www.thestar.com/news/insight/2016/01/16/when-us-
             | air-...
        
               | beaconstudios wrote:
               | 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 tremendous potential out of
               | false self imposed limitations.
        
               | fartcannon wrote:
               | 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.
        
               | beaconstudios wrote:
               | 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.
        
             | travisjungroth wrote:
             | You said "This comment is meant to be general." and then
             | quoted and replied to things the commenter shared about
             | themselves.
        
         | ZephyrBlu wrote:
         | 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.
        
           | narshian wrote:
           | No it's not. Speaking as someone who specifically has this
           | problem: even eliminating all possible distractions does not
           | do the trick.
        
       | titzer wrote:
       | 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. :)
        
       | legerdemain wrote:
       | 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?
        
         | cercatrova wrote:
         | The article links to this Wikipedia page, looks like you can
         | "force" the user to pick a specific card.
         | 
         | https://en.wikipedia.org/wiki/Forcing_(magic)
        
           | legerdemain wrote:
           | That's just trading one word for another! OK, how do you
           | _force_ the audience member to pick a specific card from a
           | deck?
        
         | travisjungroth wrote:
         | That's an entire family of tricks called card forces. I used to
         | have a whole routine based on them. Here's a blog post with
         | three of them: https://conjuror.community/best-card-forces/
         | 
         | I had about a 50% hit rate on the natural force. You just fan
         | through the cards and time it so they pick the one you want.
         | Wouldn't work for the tea trick, but works fine if you have a
         | fallback.
        
           | legerdemain wrote:
           | Thanks for the link. Of the three techniques mentioned, one
           | (the entire deck is all the same card) obviously doesn't
           | withstand any scrutiny; one (riffle through a deck and skip
           | to your chosen card when they say stop) feels like it'd be
           | too risky for a trick that took days to set up; and one (the
           | "natural" force) says "please pay us to learn the secret."
           | 
           | I don't think the trick that's the show pony of this blog
           | post has been revealed to us.
        
         | wott wrote:
         | He has put in his article a link to the Wikipedia definition of
         | 'Forcing' (and once there, there is a link to a book describing
         | techniques).
         | 
         | edit: sorry, I hadn't refreshed and seen the other 2 replies
         | before I replied myself.
        
           | legerdemain wrote:
           | I don't understand what you comment contributes to my
           | knowledge. The author says that he will explain a magic
           | trick. He says that step one is to XYZ. He does not say how
           | to XYZ. He instead links to a Wikipedia page that says what
           | XYZ is, but doesn't describe how to XYZ in a way that would
           | work in the magic trick. Instead, it links to a book that
           | _might_ say more about XYZ. I am not about to buy that book.
           | 
           | Do you consider that trick to be sufficiently explained?
        
       | draw_down wrote:
       | 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.
        
       | macando wrote:
       | _The only "trick" is that this preparation seems so boring, so
       | impossibly tedious, that when we see the effect we can't imagine
       | that anyone would do something so tedious just for this simple
       | effect_.
       | 
       | Even magicians who know many tricks will still enjoy the show and
       | appreciate the effort.
       | 
       |  _Prestige_ is a great movie about this very topic.
        
       | godot wrote:
       | I can really relate to this. Countless times I've run into tasks
       | that are even only minor grinds (some tedious work that maybe
       | takes 30 minutes to an hour to do), and countless engineers I've
       | worked with will just complain, avoid, or just plain be unwilling
       | to do them. They'll indulge in discussing why things are wrong
       | this way, what architecture should be like etc. And countless
       | times, I'll just get through the minor grind and do the thing.
       | Many of these engineers are smarter and more knowledgeable than I
       | am, but when the time comes for performance reviews, promotions,
       | these grinds really count. It's exactly as the author describe
       | it, these grinds look like magic to the audience (management);
       | because they are impactful to the business. Having said that, of
       | course it's no excuse to create or perpetuate poor engineering or
       | architecture by grinding. It's a balance.
        
       | 123pie123 wrote:
       | Thanks, I enjoyed that.
       | 
       | I'd like to think this applies to a lot of professionals work,
       | putting crazy amounts of effort in for a simple outcome, that
       | just works.
       | 
       | except the outcome is not as exciting as watching loads of
       | cockroaches
        
         | BossingAround wrote:
         | > putting crazy amounts of effort in for a simple outcome, that
         | just works
         | 
         | There's a fine line though. You want to put in the effort into
         | a task where it makes sense, like in the article.
         | 
         | Personally, I see a lot of effort put into tasks where the
         | person is comfortable with the effort, because they know they
         | can do the task manually, the old way, and "don't have time for
         | anything else".
        
       | empiko wrote:
       | Something similar can be said of writing survey paper in
       | academia. Nobody wants to go through 150 papers about some
       | godforsaken topic, but the one guy that goes through it is
       | immediately considered to be a top notch expert.
        
       | dceddia wrote:
       | 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 the right weather or lighting, braving
       | subzero temperatures, or whatever it might be, just to get a
       | single shot that might be on screen for a few seconds.
       | 
       | 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.
        
         | munchbunny wrote:
         | 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 and
         | exciting, or because getting from 80% to 100% requires time we
         | could spend building 80% of something else we want to sell.
        
           | chrisco255 wrote:
           | 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.
        
           | bentcorner wrote:
           | 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.
        
           | 0xFACEFEED wrote:
           | 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.
        
         | mathgladiator wrote:
         | The key word is marginal. Sadly, software tends to align
         | against art as pushing boundaries is marginal for the return of
         | investment.
         | 
         | I can provide an example. I'm writing a programming language,
         | database, and platform to power board games. http://www.adama-
         | lang.org/
         | 
         | Most of my personal investments are marginal to most businesses
         | (or deeply incompatible). If was going to run this as an
         | enterprise, then this would be a death sentence. However, my
         | hope is that when I get this thing moving, then I can ship
         | games quickly with exceptional and redefining reliability.
         | 
         | The only reason I can pursue this as an art is that I'm close
         | to retirement.
        
         | akiselev wrote:
         | _> 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.
        
           | olivertaylor wrote:
           | > they emphasize the creative aspect far more relative to
           | tech since they're competing over form not function
           | 
           | Yes and no. There are a lot of "make it fit in the box"
           | requirements when making a movie. The unions mandate a
           | certain make up of the crew, and a certain size, the stage
           | rental costs are a certain amount, there are various laws and
           | corporate budgets to take into account; all that adds up to a
           | certain number of shots you can do in a day, which adds up to
           | a dollar amount, and ALL THOSE THINGS cascade down to
           | enabling only certain creative things. The difference between
           | a brilliant director and a ok one is not the beauty of their
           | art, it's their ability to pull-off something incredible in
           | the middle of all that machinery. In a way, it's WORKING that
           | machinery in your favor.
           | 
           | So while, yes, the industry is set up to support a creative
           | endeavor, that industry runs on a template that makes certain
           | things possible and certain things very difficult. But
           | brilliant producers and directors find ways around it.
        
             | akiselev wrote:
             | >* So while, yes, the industry is set up to support a
             | creative endeavor, that industry runs on a template that
             | makes certain things possible and certain things very
             | difficult. But brilliant producers and directors find ways
             | around it.*
             | 
             | Totally agree, and IME that's par for the course for any
             | creative endeavor that becomes profitable but
             | unpredictable, whether its cinema, music, or software
             | engineering. I meant more that the final product is judged
             | on aesthetic qualities more so than in software, so the
             | industry naturally allows for more creative expression at
             | the highest levels of decision making.
        
         | rcurry wrote:
         | I wanted to be a professional magician when I was younger, and
         | there's a single-handed cut that I learned from Daryl Easton
         | (at a seminar he gave at some Holiday Inn). It took me a month
         | or two of solid practice to get it down, but over thirty years
         | later I can just pick up a deck of cards and flip that cut out
         | like it was nothing. I was saddened to learn that he had
         | committed suicide a while back. Every time I do that flourish
         | playing cards with people or whatever I just remember that time
         | when one of the world's best magicians hung out with me for a
         | few minutes after his seminar just to make sure I had it down.
        
         | mensetmanusman wrote:
         | The movie thing is a good example. I remind my kids that some
         | of these movies cost $1,000,000/minute to make. That might be
         | what they make in their lifetime, so it is about that many
         | hours of work per minute (a life's work).
        
           | mwcampbell wrote:
           | When you put it that way, that's obscenely expensive. Maybe
           | we should be steering kids toward entertainment that we can
           | create as well as consume because it's not absurdly
           | expensive.
        
         | david422 wrote:
         | 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.
        
           | phpnode wrote:
           | 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 heads in a row.
           | 
           | I think that kind of brute force approach would have been
           | excessively boring to him, and it's much more likely that he
           | switched to a gimmicked coin to get the ten heads in a row,
           | then filmed a few shots of throwing tails for the
           | "explanation".
        
         | IncRnd wrote:
         | > 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.
         | 
         | Larry Wall was quoted in the article, regarding laziness.
         | 
         | Bill Gates has a famous quote, "I choose a lazy person to do a
         | hard job. Because a lazy person will find an easy way to do
         | it."
         | 
         | Neither of those people can be accused of laziness, yet they
         | both embrace it. Laziness in the context of productivity is
         | often misunderstood as not doing things, but it is more aptly
         | the stopping of doing in order to observe, think, and let the
         | answer come to you. Work diligently, but think and simplify
         | first. It seems to me that is also what the magicians do.
        
       | bluquark wrote:
       | 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 potential bug assignee
       | who's an expert on the problem in question (the author of that
       | patch).
       | 
       | It's "one weird trick" to get bugs stuck in limbo for weeks
       | suddenly making fast progress towards a fix, and all it takes is
       | a willingness to do something so tedious and mindless that no
       | other engineer volunteers to do it.
        
         | ip26 wrote:
         | However, every time I reason about the problem & debug it, I
         | gain a little knowledge and do it a little faster next time.
         | Bisecting never really gets faster, aside from maybe writing a
         | script.
        
         | aidos wrote:
         | That approach works well for regressions. I've used it myself
         | to track down a bug in chrome and, as you say, having no idea
         | how to fix it, I could direct it to the author via the bug
         | tracker. In my case it was fixed within a couple of days. And
         | obviously bisecting chrome is a slow process, but it only took
         | a couple of hours.
         | 
         | I find that most bugs don't fall into that class, and for the
         | most part, just sitting and picturing the paths back from the
         | bug is enough to work out what's going on. If you're less
         | familiar with the code you'll want it in front of you to trace
         | your way back. In general you can narrow the search space
         | pretty quickly.
        
         | munchbunny wrote:
         | 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.
        
         | TameAntelope wrote:
         | Heh, my answer is that I just refuse to build or work on
         | systems where bugs aren't always super obvious. If the system
         | gets too complex, I bisect the system.
         | 
         | I think I've infuriated many colleagues with this attitude, and
         | I'm sure there's at least half of the people here who would
         | similarly be angry working with someone like that.
         | 
         | Honestly, I'm not very good at writing software, I just tend to
         | be similar to the author -- I grind more than I out-think most
         | of my problems, and it results in a deliverable that solves it,
         | usually, which ends up being enough to move on with.
        
       | arpyzo wrote:
       | It's interesting that while this often produces stunning results,
       | it usually doesn't lead to pay increases and promotions.
        
         | kache_ wrote:
         | Doing a good job is important. Pay increases and promotions are
         | obtained through way of leverage, but doing a good job and
         | building a strong reputation pays dividends in the future.
        
         | ptudan wrote:
         | Yep, learning to optimize for visibility is one of the things
         | every corporate worker should do.
         | 
         | It's unfortunate, but the main way to actually see your
         | compensation and respect increase.
        
         | PragmaticPulp wrote:
         | > 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. Your peers
         | will form your future network as everyone diffuses into
         | different companies.
         | 
         | It's a mistake when someone scales back their own effort and
         | learning simply because they don't expect an immediate monetary
         | reward. We're all building careers and networks over the course
         | of decades. Don't let a lack of pay increases at a single
         | company alter hamper the trajectory of your entire career.
         | 
         | And if you find yourself stuck at a company that isn't
         | rewarding these things, move on. Some other company will gladly
         | reward you for the accumulated experience. It only goes to
         | waste if you stay put at companies that don't reciprocate.
        
       | jldugger wrote:
       | > 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 into, where
       | nobody feels empowered to ignore the rest of the business for 3
       | weeks to put the bell on the cat. The only person without
       | deliverables and due dates is the new hire. 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.
       | 
       | But he's right in general, that you can get some surprising
       | things done by just putting in the time and focus. Which is why
       | it's so utterly toxic that corporate America runs on an interrupt
       | driven system, with meetings sprinkled carelessly across engineer
       | calendars.
        
         | habitue wrote:
         | One of the most important things I think Kanban[1] emphasizes
         | is that once you eliminate unnecessary bottlenecks, you're left
         | with unavoidable bottlenecks, and this naturally means there
         | will be slack. Explicitly expecting slack time is super useful
         | to allow developers at all levels of seniority to do surprising
         | and necessary things like this that would otherwise never be
         | scheduled.
         | 
         | [1] not the project board shape, but the original process it's
         | named after where you set a hard cap on work in progress in
         | each stage to find out where bottlenecks are.
        
         | pbourke wrote:
         | > 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 relatively open schedule, one is dissuaded from
         | engaging in longer stretches of work for fear of having it all
         | go to waste when the next meteor strike arrives.
        
         | hyperpape wrote:
         | Interruptions are definitely harmful, but if you look at what
         | he did, he could have done it in spite of meetings. What would
         | be bad would be starting it and being told (implicitly or
         | explicitly) not to finish it.
         | 
         | Better to have meetings than to have what you're doing
         | cancelled several weeks in.
        
         | aspaceman wrote:
         | > 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".
        
         | rufius wrote:
         | 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.
        
           | fossuser wrote:
           | 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 position.
           | 
           | You also irritate people that spent time writing up product
           | issues for potentially important bugs by auto closing them
           | (so many important things may not come back), but the bigger
           | loss is that going through all of them gives you solid
           | product historical context.
           | 
           | For what it's worth, the best PMs I know go through the
           | backlog and understand what they're killing when they
           | approach a project that's currently fucked. I think it has a
           | positive side effect of giving them a lot of credibility too
           | (as well as helping them ramp up).
        
       | awillen wrote:
       | Really well written and so true... I think that far too often,
       | people get intimidated by the size/scope/hairiness of a problem
       | and try to reduce their intimidation by breaking it down.
       | 
       | Particularly if it's a one-off problem, you're often far better
       | just doing something. Anything. Whatever comes to mind first.
       | Just take some sort of step.
       | 
       | You may find that the problem isn't as hairy as you thought, and
       | in fact just by continuing to do stuff, you solve it pretty
       | quickly. When that's not the case, doing stuff often leads you to
       | the kind of understanding that allows you to put in place a good
       | plan, where just starting with planning forces you to make a
       | bunch of incorrect assumptions that you then have to fix when
       | actually implementing the plan you worked so hard on.
        
       | beders wrote:
       | This is so true for every bug tracking system I ever encountered
       | in any company.
       | 
       | We called it the P3 graveyard.
       | 
       | And there's always that lingering feeling that there are few
       | nuggets hidden in there that would resolve the majority of them.
        
       | louwrentius wrote:
       | This article may be the most important article on Hacker News you
       | may read this year.
       | 
       | The message of this story is obviously beyond just our IT related
       | professions.
       | 
       | I really wonder if people do understand what needs to be done but
       | won't. Or that they really don't see a way out of a mess.
       | 
       | Are people really wilfully blind to 'obvious' solutions that are
       | boring, labor intensive and terrible to implement? Don't they see
       | the even worse alternative?
       | 
       | This is in the end probably not about smarts or insight.
       | 
       | This is about something more fundamental: values.
        
       | maverickJ wrote:
       | What a fascinating story.
       | 
       | I think of success as having infinite patience for doing a few
       | boring things repeatedly.
       | 
       | Some other parts are having a higher mission to embrace the
       | grind;Some call this purpose.
       | 
       | Something else I have observed by studying other engineers is the
       | theme of not depending on your technical skills alone. One needs
       | to market/show their work to the right audience, own equity in
       | businesses/business.
       | 
       | "As a technical person in your career, you must not rely on your
       | technical brilliance or rest on your laurels. You must acquire
       | some financial education. There is a tendency for technical
       | people to think that they are the best; That they will always be
       | on top; That will be always be creative; That their inventions
       | won't be usurped quickly by newer inventions. However, history
       | says otherwise. Life was quite unpleasant to Tesla; He died alone
       | and poor depending on handouts from former associates. A tragic
       | end for one the most creative minds of the early twentieth
       | century."
       | 
       | https://leveragethoughts.substack.com/p/dont-hinge-your-care...
        
       ___________________________________________________________________
       (page generated 2021-04-09 23:00 UTC)