25 ms·

Embrace the Grind

• longformworks 6y ago
  That was an enjoyable read and a gentle reminder to avoid the shiny tools and just get to work. Thanks for sharing.
• empiko 6y ago
  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.
• barbiturique 6y ago
  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.
  • BossingAround 6y ago
    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 6y ago
      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.
      • Too 6y ago
        Except redeploying is something that always must be done last minute in a hurry because the last version deployed has a bug that will explode any moment and launch-demo is approaching, so managements blood hounds are pushing for someone who really knows how to do it to make sure it's done swift and proper! 15 minutes earlier corporate sent out an email about their values and how important knowledge sharing is! Right after deployment is done the work on documenting or automating the process is put at the bottom of the backlog since it's highly unlikely we have to do this in a such a rush again! Make sure you have some kind of handover agreement in writing that you can point to when this happens. It sucks to be the "i told you so" guy but in situations like this you really need to protect your own back and as you say be very firm on not doing the job next time.
    • kache_ 6y ago
      Pair with someone else and have them do it, and be explicit about your intention to share the knowledge.
    • pilchard123 6y ago
      Never become the guy who can fix the printer.
    • tonyedgecombe 6y ago
      I used to be quite happy to do all the dirty jobs that needed doing until I had an epiphany and realised I wasn't getting any credit for this. In fact it seemed to be doing my career some harm. I stopped and refused any work that wasn't directly linked to bringing money in. Within a couple of years my salary doubled.
  • mdpye 6y ago
    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.
    • piva00 6y ago
      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.
    • hinkley 6y ago
      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).
  • trentnix 6y ago
    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.
  • hinkley 6y ago
    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 6y ago
      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 )
      • hinkley 6y ago
        Some things are just very hard to explain for various reasons. One of them is that it's painful to look at how stupid some processes are. But like the rubber duck technique, sometimes trying to 'document the bullshit' connects some dots in your brain and lets you either avoid the most frustrating part or at least chip away at it. And sometimes chipping away at a problem gets other people to contribute as well. Hope is a powerful thing. It's kind of a Hail Mary Play but even the 'bad' outcome is far better than inaction.
  • russellendicott 6y ago
    This strategy is common in any skilled labor trade. For example, joining a carpentry team the first thing you have to do is tote lumber to earn respect.
• chrchang523 6y ago
  Alternate framing: be prepared to "Do Things that Don't Scale" (http://paulgraham.com/ds.html http://paulgraham.com/ds.html ) when your organization is small.
  • gkop 6y ago
    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 http://www.paulgraham.com/schlep.html
    • chrchang523 6y ago
      I had forgotten that the schlep essay was distinct. Interesting that they don't refer to each other.
      • leeoniya 6y ago
        ah yes, his own submarine topic ;) http://www.paulgraham.com/submarine.html http://www.paulgraham.com/submarine.html
    • KerryJones 6y ago
      Out of curiosity, why not a fan of PG?
      • deleted 6y ago
        [deleted]
• 123pie123 6y ago
  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 6y ago
    > 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".
• arpyzo 6y ago
  It's interesting that while this often produces stunning results, it usually doesn't lead to pay increases and promotions.
  • kache_ 6y ago
    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 6y ago
    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 6y ago
    > 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.
    • MattGaiser 6y ago
      > 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.
• dceddia 6y ago
  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 6y ago
    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.
    • bentcorner 6y ago
      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 6y ago
      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.
• bluquark 6y ago
  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.
  • aidos 6y ago
    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 6y ago
    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 6y ago
    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.
• awillen 6y ago
  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.
• didibus 6y ago
  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?
  • andrewstuart 6y ago
    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.
    • rabidrat 6y ago
      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.
  • mumblemumble 6y ago
    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.
• PragmaticPulp 6y ago
  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 6y ago
    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 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.
• MacroChip 6y ago
  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.
  • tonyedgecombe 6y ago
    I'm not even sure what laziness is anymore, other than being a symptom of something else.
• Zelphyr 6y ago
  I just finished reading Arnold Schwarzenegger's autobiography and one thing he says frequently is, "reps, reps, reps, reps!". He obviously got his physical gains through many reps but he also says he would never film a stunt scene without rehearsing it at least 10 times. This made me think of something I read about John Resig. He had created somewhere around 75 open source projects before jQuery. Reps, reps, reps indeed.
• draw_down 6y ago
  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.
• 5cott0 6y ago
  Everybody's other favorite German word: "sitzfleisch".
• macando 6y ago
  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 6y ago
  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.
• jldugger 6y ago
  > 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.
  • pbourke 6y ago
    > 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.
    • dnautics 6y ago
      I agree but I wouldn't call it toxic, rather "foolish".
    • milesvp 6y ago
      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.
• louwrentius 6y ago
  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.
  • pm90 6y ago
    Its often more complicated than that. I worked on a team that interfaced directly with the semi-technical "Customer Account Managers" who did the technical setup for customers on our system. The system itself was pretty old, written by people who no longer worked at the company. There are often a number of things that are wrong with the system or don't scale, and every week there is a new issue that would bring down the system. Without the right manager/PM, other teams would constantly blame my team for fucking up. But every time we tried to work on things that would improve system behavior, a new feature would take priority, or some other thing would blow up requiring the entire teams focus to fix it. So even though we wanted to fix things, we were in this state where we couldn't put out fires long enough to fix the fundamental problems with the system.
    • louwrentius 6y ago
      Thanks for sharing this. I think this is a good example of the kind of story we encounter more often. But I think this is also a good example about values. Part of this is also how you 'sell' your story towards other teams, to get buy-in so we all get out of the fire-fighting. I bet you and your team tried, probably multiple times. However, if that doesn't work, you'll have to cut your losses. Stay for the money or leave for the values. What does an environment do for you long-term? I really wonder if there is some kind of way to negotiate a way out of this mess.
  • Nemrod67 6y ago
    I think the core of it is indeed values, but in the Real World it's about printing money. If the natural incentives for "Better Things" are replaced with "Get all the moneys, escape any consequences" then we get the current macro-economic incentives in all domains. I guess it will either devolve into total-vertical-transnational integration (imagine being a citizen of Apple), or we'll have to create a new country "for smart people that wanna do stuff", and that entails a whole lotta hard work and problems.
• annoyingnoob 6y ago
  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.
  • im3w1l 6y ago
    The 80/20 rule gets interesting when there is competition in the mix. Why should I see an 80% good magician who spent 20% of the time, when I can see the 100% one? Spending 20% of the time thus gets you ~0% of the money. The same actually goes for tech too, but here the answer is often that the 100% product isn't on the market yet, and by the time it is finished the need for it no longer exists.
• tarunkotia 6y ago
  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 https://news.ycombinator.com/item?id=25010373
• legerdemain 6y ago
  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 6y ago
    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) https://en.wikipedia.org/wiki/Forcing_(magic)
    • legerdemain 6y ago
      That's just trading one word for another! OK, how do you force the audience member to pick a specific card from a deck?
      • blandflakes 6y ago
        I have to ask - did you read the (quite short) link? > An example of equivocation can be as follows: A performer deals two cards on a table and ask a spectator to select one. If the spectator chooses the card on the left, the performer will hand the card to the spectator. If they pick the card on the right, the performer will take that card as his own and have the other card be the spectator's. In either case, the spectator receives the intended card. Or maybe you're asking more precisely exactly which forcing mechanism would be used, for the trick in TFA?
      • peteretep 6y ago
        Two very easy ones that I’ve never had fail in practice: 1. Get them to tell you to stop as you flip through the cards vertically, and then sleight the card from the bottom of the deck instead. 2. A simple counting trick like this https://youtu.be/ekPbMhJGYmc https://youtu.be/ekPbMhJGYmc
  • travisjungroth 6y ago
    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/ 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.
• maverickJ 6y ago
  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-career-on-technical https://leveragethoughts.substack.com/p/dont-hinge-your-care...
• beders 6y ago
  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.
• WindyLakeReturn 6y ago
  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.
• titzer 6y ago
  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. :)
• courtf 6y ago
  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.
• bumbada 6y ago
  I had a different experience solving similar problems. When I started working in Spain as an engineer I solved problems like that in the article, very hard, requiring people with very high technical skills. Companies creating big problems because short term mentality made the bluff to accumulate until emergency came. There was an important distinction with the protestant-puritan mentality of the US. After doing all the hard work and saving the company I was paid in peanuts and more work, filling all my time and making my life miserable. Emergencies bring enormous social pressure over you, you overwork and it is painful. They called you because "short term" mentality but solving the problem always takes more time that what they demand you take. It must be done for yesterday. The big bucks were given to the people that took the bad decisions in the first place at the top. I went to Asia and the culture was even worse, albeit this time I was benefiting from that. Then I discovered places in the world where hard work was rewarded. It is a very small part of the world. Most of the world does not work the way the Silicon Valley does, and even there socialism is coming to those places too. So I won't recommend that you work harder unless you are rewarded from it, that is your culture rewards you for that or you have your own business and work gives you an advantage. I would recommend the opposite, simplify your life so you need to work less, make other people(delegate) or specially machines do the hard work for you. Do not embrace toxic relationships. Let companies in eternal emergency mode burn and die, and work for(or create) those that do the right thing.
  • monsieurbanana 6y ago
    What toxic relationships? This is about fixing issues where spending two hours doing boring work (manually bisecting) can be better than spending two hours thinking about the problem without necessarily reaching a solution. Nothing about underpaid overwork, just to do The Boring Thing. I'm also trying hard, and failing, to understand why you're talking about socialism.
• brailsafe 6y ago
  Totally agreed. Sometimes, just putting in the labour is a great way to get it done. I wasted a ton of time last night thinking about how I'd write a scraper to download my bank statements from my damn bank that uses .net postbacks, which may lead to something, but ultimately I just took my damn ritalin and manually clicked and waited for each one. (then wrote a bash script to rename them all with regex and sed :))
• datavirtue 6y ago
  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?
  • emodendroket 6y ago
    This is a great way to end up being the "expert" in PHP, Rails, frontend dev, and other stuff you actually don't really enjoy doing, and have everyone just keep assigning you those tickets instead of lifting a finger to do it themselves. Ask me how I know.
    • datavirtue 6y ago
      Hmmm....it landed me as the tech lead for all of IT and development.
      • emodendroket 6y ago
        Well, glad it worked out for you, but I am not the first person to find that doing too good a job at undesirable tasks means everyone thinks of you when they want them done.
      • fctorial 6y ago
        Survivorship bias?
        • datavirtue 6y ago
          Yes. But it is common advice from CEO s and it fits with what my grandmother used to tell me: the boss gets all the shit jobs.
          • emodendroket 6y ago
            CEOs are not exactly a disinterested party here, are they?
• morty_s 6y ago
  > 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.
  • KerryJones 6y ago
    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_.
  • hashkb 6y ago
    And the difference is what? If I have no "talent" on guitar but I practice for thousands of hours until I can "trick" you into thinking you're listening to Hendrix...
• ChrisMarshallNY 6y ago
  It's funny. I was talking with the team on a call, yesterday, and one of them was telling me we should hire someone to do "the boring stuff," so I would be free to do "the fun stuff." I said no. I've been shipping (as opposed to "writing") software for over thirty years, and, if there's one thing I've learned, is that "shipping" software is about 60% - 80% "boring" stuff. I can avoid it, if I'm only interested in "having fun," but if I want to "ship" my work, I need to power through the grind. I also don't believe it's stuff I'm comfortable entrusting to others. When I'm at the car wash, I inevitably see someone driving a car -often not the fanciest ones- through the wash, because they don't trust the attendants. I guess I'm that guy. I really enjoy knowing that my work is out there, in the wild, and not just in a pitch demo. I consider it a craft, and I love to finish projects. That means that I need to take the time to break out the 2000-grit sandpaper. That makes it a lot less of a "grind," to me. But that's just me. YMMV.
  • mft_ 6y ago
    Different strokes for different folks - and a mix of different types is often necessary. I remember the very first time I ever completed (through by work at the time) a psychological profile. (I know such things are mostly discredited, but bear with me). I think it was based around Belbin's team profiles. I came out as a creative, innovative, 'starter' of things - which actually matches me pretty well: I'm excited by solutions and new ideas, but I often don't complete personal (and sometimes professional!) projects 100% - I've lost interest and moved onto the next shiny thing by then. (Professionally, I'm best with a complimentary team around me.) A colleague who I got on well with but also often found frustrating, came out as a 'completer finisher'. Which again aligned well with my observation of her and her own testimony of where she drew her gratification from, and also explained why I sometimes found her frustrating: because we were total opposites in this regard. --- Anyway... maybe the situation you describe on your team is explained somewhat by this? You both want to work on aspects of a project that you find gratifying - but you derive gratification from different aspects?
    • ChrisMarshallNY 6y ago
      More or less. I enjoy research and design. Thinking about architectures is fun. I enjoy implementation. Writing code is fun. I enjoy doing in-place documentation; especially as I am usually the poor schmuck that has to go back and refactor or fix. I really like solving problems; whether bugs, or vexing UX/mental model issues. I'm an extremely proficient troubleshooter. My first job was as an RF technician, so I have been solving problems my entire adult life. I enjoy creating a software infrastructure, for others to build upon; as opposed to "an app." I've written software that lasts decades, though with a vastly different face. That's kind of a cool feeling. Watching someone take my basic undercarriage, and add a hot rod motor and chassis, is wild. I enjoy creating documentation. I'm pretty prolix. I was trained as an artist, so I can do fairly decent illustrations, as well as prose. I enjoy creating localizable software. I've been dealing with different cultures my entire life, and love to explore our differences. I enjoy creating accessible software. I deal -almost daily- with folks that have various types of challenges, and they help me to keep a focus on what's important. I enjoy pitching the project. Having a product that is in very good shape at pitch time, makes this much easier. I enjoy releasing a refined, polished project.
• dwighttk 6y ago
  I assumed this was from https://www.jacobinmag.com https://www.jacobinmag.com and expected something quite different
  • Ericson2314 6y ago
    Glad I wasn't the only one!
  • zacharycohn 6y ago
    I know the author and yes, he gets this a lot...
• ecnahc515 6y ago
  This reminds me of a blog post by Steve Klabnik (on the community team of Rust currently) about how he went through the Ruby on Rails backlog once similarly. It's a good read: https://steveklabnik.com/writing/how-to-be-an-open-source-gardener https://steveklabnik.com/writing/how-to-be-an-open-source-ga...
  • steveklabnik 6y ago
    Thanks! I’m glad you like it; at the time I didn’t think it was a big deal but it’s probably one of the most widely-read things I’ve written... (Tiny nit: I am not on the community team. I am on the core team though.)
    • ecnahc515 6y ago
      Ah dang I knew I should have looked up your role!
• ilaksh 6y ago
  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.
• analog31 6y ago
  Any sufficiently unpleasant task is indistinguishable from magic?
• orangegreen 6y ago
  This is really what it takes to make a quality product. It's not only being able to focus long enough to get the job done, but also having co-workers that also value quality and focus. I get so annoyed with co-workers who don't value quality. Everything has to be done yesterday, quick and dirty, with little to no care involved. And for what? To move on to upper management's other random idea that probably isn't great? I desperately wish there was more of an emphasis on the simplicity of quality work in America. That doesn't mean spend years and years making something no one wants. That means making a product that is simple, effective, and elegant. Unfortunately, simplicity is actually harder to figure out than complexity. Adding is easier than subtracting. I think of software as art. And sometimes it takes an excruciating amount of time and effort to pay attention to the details, stomp out the bugs, and create that beautiful work of art. There are plenty of companies that do value quality, focus, and attention to detail. But far too often, it's about making a quick buck rather than thinking long term about making software that will last years on end.
  • JoeyJoJoJr 6y ago
    I find there is a general assumption that quality means things will be more expansive, and take longer. To the contrary, I have often times found that a quality driven approach ultimately gets you to the goal faster and cheaper. However there are strong incentives to get ‘something’ working as quickly as possible at the expense of quality. That then sets expectations of the standards of quality that persist.
• pugworthy 6y ago
  What he describes isn't grind, it's taking care of a big mess. Grind is management/company/etc. that says you have to work weekends and late all the time because there's more money to be made that way. Grind is doing that epic job of organizing and triaging the bugs, then your company doesn't give you a bonus and you're expected to do it all the time. Doing the right thing is what he did. I just hope his company did the right thing back.
• hiisukun 6y ago
  Read it anyway and agree that someone taking care of a task that requires technical understanding, but is in itself repetitive and time consuming is often a critical part of some business process. Many times I've witnessed such issues grow over time, slowly and surely reaching the stage mentioned in the piece. Every time, people up the chain have been aware but haven't acted, when usually the solution is (unavoidably) making the time and space available for a capable person to do it, and having then be incentivised/rewarded enough to proceed. Off topic: I was hoping based on the title for an unusually technical skateboarding article.
• posharma 6y ago
  This is such an amazing and inspiring article. Thanks for writing and sharing.
• mettamage 6y ago
  I embrace best tool for the job. Sometimes it’s code, sometimes manual grind or sometimes something else. One time I had to fix a bug that was estimated at 40 hours and consisted of getting Python 2 type coercion in Python 3 (IMO a silly idea). The users of this program were 5. Instead what I did: I taught them about strings and ints and how to cast (it was some template language they used). I added an answer with some examples to the FAQ. It took me an hour. The previous programmer on this project never considered manual solutions.
• mdip 6y ago
  Love it. I've written at length about my Dad's adventures as an entrepreneur, but I remember that one statement made over card group[0] about my Dad's company and my Dad that really stuck with me. The backstory is that Dad bought into a business he was working for. After several years of success, the majority shareholder decided to retire and sold the business, taking a deal that was highly favorable to him and violating contractual agreements in place with the other shareholders[1]. The end result was my Dad was out of a job at a company he worked hard to build and he did the legal things right to avoid getting here in the first place. The parts of that whole process that weren't blood-boiling infuriating were probably devastating, and I know he lost many night's sleep. The old company was being purchased by its direct competitor, which was a much bigger outfit, already. Now it would have the manufacturing and (some of) the staff of the old business since OtherCorp[2] decided to keep the old place running. My Dad did get a payout; he probably could have taken that, done all of the investing he did over the years, and ended up retiring in the same position he's in now, but he didn't. It wasn't that "all of this happened and so he buckled down and worked harder". He always worked hard. The Poker game comment was made shortly after my Dad had decided to open up a competing business, talking about his success at the previous one. And he was about to embark on taking on that competitor and his previous business as a completely new outfit running on a shiny bank loan. The table was talking about my Dad setting up the new business and a neighbor friend's Dad folded and said: "Hah! They're FUCKED[3]! They didn't buy anything. They don't know that (old company) is Russ (my Dad)! Ford/GM/Chrysler don't want to work with (old company), they want to work with Russ". Then (mind you, probably a few beers in), he went on about story after story of my Dad's various rabbits he's pulled out of hats. The stories were insane--I've got comments written in the past about my Dad concluding a 24-hour workday (as part of a series over a few weeks, I think) with a drive down to a plant in another state to ensure parts arrived when promised, only to be given sympathy by the plant manager -- my Dad wasn't in his usual suit, he had on what he wore doing manual labor. The plant manager took a shot at "the jerk/prick/asshole" who's forcing him to drive all night, to which my Dad said something along the lines of "I sure am", I'm sure, but I doubt he took offense. At crunch times, my Dad was more than "the guy working back in the shop with everyone else", he was the guy doing the worst/most painful job. Assuming skill level wasn't a factor, if a job involved risk, it was his. Now, I'm not saying he was a saint. My Dad did not manage the people, and my high-school friends (who all got jobs in the back in the summer due to near limitless amounts of overtime) used to tell me some hilarious stories about him blowing his top screaming at them for this or that thing[4]. As I grew up and learned more of the story, I learned of the struggles the new company had getting these large automotive companies to be willing to work with such a small shop. At the end of the day, it was my Dad's willingness to take whatever job was given to them, do it better than anyone else and further prove that "that (old company) was my Dad, new company is my Dad". Consequently, my understanding is that the lawsuits involved ended in my Dad's favor, but the lawyers were the only ones who profited. My Mom and Dad occasionally argued over the lawsuit. My Dad knew before they filed it that they'd never see a dime and would likely spend money. Nobody thought my Dad was holding out hope for a payout -- he was clear about it from the beginning that it was the principal of the matter. And when he won, I was moved out, but I don't recall being invited to any parties or even hearing about it except in passing. I'm sure it was important, but the thing that I did hear about was when he was able to purchase OldCorp back from the competitor about a decade later. What was left of his old company's staff was let go and the business was wound down shortly after that. My Dad's business is still around. He's (pretty much) retired; still has the same stake in the company, though they're always entertaining offers to sell. He's had many offers, but none of them came with strong guarantees for the existing staff -- a lot of whom were there day #1 -- and he won't do that to them, they are great people. I think part of it is having a taste of that, himself, when his last company/job disappeared out from under him. Part of it is not wanting to sell the company knowing it's just going to become "a customer list" at a larger company. It won't be the next Google, but I bet he'd love it if it outlived him. I'm sure there are several other reasons, but I know he deeply valued how much his staff was willing to give to his company and that would have been enough. [0] Mom/Dad played Pinochle and Euchre (Michigan thing) with a large group of couples, Dad played Poker. [1] If that sounds really vague it's because I was pretty young when this happened, this is not an area I have any expertise in and I've never been sat down and told the entire story from start to finish, so I'm putting together pieces of that memory. But I lived through it as a kid so it's pretty vivid. :) [2] Not their real name if that's not clear! [3] Sorry about that -- I try to keep it clean, but that word wasn't said in my house very often, so when 12-13 year old me heard my friend's Dad use it to praise my Dad, it stuck with me. There are times that censoring the profanity loses the effect. [4] A buddy of mine insisted that my Dad went into the back yelling at them for being behind on something, throwing F-bombs left and right. I spent a few minutes confirming he was talking about my Dad. Growing up, I think I heard him use it four times and Mom twice. When I went to work at a smaller shop in my teens (and every one thereafter in my life), I realize that's not all that surprising ... and that my buddy was also, probably, exaggerating. My Dad was a pilot for a long time and is well known for his cool head; he'd generally swore/yelled at "things" not people (other than the Lions, perhaps, but that's more yelling at the TV).
• zuhayeer 6y ago
  Having now hand-curated and updated 100s of level mappings for different companies by using a combination of research, leveling rubrics, and crowdsourced submissions on Levels.fyi, this article speaks to me
• mds 6y ago
  Reminds me of this Penn and Teller trick with a similar method but the opposite effect -- see https://www.youtube.com/watch?v=gnEGedfTrzc https://www.youtube.com/watch?v=gnEGedfTrzc (skip to 2 minutes in). Freely think of any card, then miraculously reveal the card in an improbable location. It's "easy", just hide all 52 cards and memorize where they're hidden.
• farrarstan 6y ago
  Ive simplified it but it still requires me to tell you about a lot of tea? Dont fukken hoist me! Stop!
• ttiurani 6y ago
  This article is very on point and every team benefits tremendously from people who do just spend the time and sleigh the monsters. In a bigger team, a big second reason why these kinds of very uncomfortable tasks aren't done is that they also often don't produce immediate business value. You then have double resistance: the PO wants features from you and grinding is boring. The people who first get to a position where they can spend the time and then do spend the time (instead of doing the even more fun tasks), are worth their weight in gold.
  • tome 6y ago
    > sleigh the monsters I love this image
  • ogennadi 6y ago
    This. I'm glad my employer has hack weeks twice a year when I can play, or grind out useful-but-low pricey tasks.
• dorkwood 6y ago
  I experienced this when I first started learning the piano. When I played the first song I had learned for my sister, she was amazed. "Wow, I could never play like that", she said, "my fingers don't work that way". But when I broke down for her exactly how I'd learned it -- by breaking the song down into manageable chunks of just a few notes each, practicing each chunk with each hand separately many times until proficiency was reached, stringing the chunks together until I could play the whole song separately on each hand, and then bringing both hands together and repeating the entire process all over again -- her amazement turned to a look of disappointment. It was a mix of both realizing that her brother wasn't actually a genius, and a sort of mild disgust that I'd dedicated so much time to this activity.
  • deleted 6y ago
    [deleted]
  • jonfromsf 6y ago
    A good magician never reveals their tricks.
  • pitspotter 6y ago
    Yes, which piece was that btw? I'm learning Rachmaninoff's Prelude in G minor, probably the hardest piece for me to date. I'm not timing the process but this must have been going on for six months by now. Practice occurs only when I feel like it, as I walk past the keyboard. Sometimes less than 5 minutes per day. Rarely more than 15 minutes. But it's getting there! If you added it all up, it would be a tremendous amount of work. Doing it to a schedule, or even just filling out a timesheet, would make it too grindy for me to bother with. So I think When it comes to learning, it's really motivation that is paramount. Not getting bored is a superpower. It's the ability to 'embrace grind' by discovering what's interesting about it.
    • pixiemagic 6y ago
      I agree. I think pretty much everything (I've seen it with piano, work, exercise) becomes so much easier when you're motivated. For me, it's been more obvious with piano as it's my main skill-based hobby and, although I see similar with work, ultimately I need a job to get paid so even if I'm procrastinating over a boring task, at some point that kicks in to make me get on with it. With piano, I'm only doing it for fun and there are so many pieces out there to learn, so if I realise I don't love a piece then I've now taken to stopping with it after a certain amount of time. At first I would get frustrated for starting but not finishing something, but the reality is that when I find the right piece, those moments you describe when walking past the keyboard and wanting to play happen frequently. With the wrong piece, they happen rarely if ever. Good luck with the Gm prelude! It's one of my favourites which I have yet to attempt to play but hope to one day...
• fighterpilot 6y ago
  The same advice applies to data science. The menial grunt work of checking data quality etc is some of the most important and often overlooked for the neater work.
  • disgruntledphd2 6y ago
    Yup. My digging into the data this week made a discovery that we'd been measuring our outcomes incorrectly for six months. That simple discovery is worth incredible amounts of money to the company, but because it's not an ML model, many people perceive it as low-importance work. Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
• igammarays 6y ago
  My personal magic trick is learning to speak almost fluently in a second language (Russian) in about a year. However, when people ask me how I do it, they quickly get turned off when they realize it's just a grind. You need to know about 20,000 words in any language to sound fluent, and there is just no way around brute-force memorization. And if you're serious about learning, you need to keep track of how many words you know, and add new words every day, and have a system for review (Anki). Although memorization alone won't teach you a language, it is a necessary but not a sufficient condition. In the beginning it is poring through grammar books and practicing basic concepts until they become second-nature. During the intermediate stages it is taking thousands of native-spoken complete long sentences with audio and building Anki card decks and memorizing them. Yup, memorizing complete sentences with audio. For advanced stages it is laboriously poring over classical literature (Dostoevsky) while having a repertoire of academic dictionaries on hand, manually recording every new word and brute-forcing every sentence, until one day the language opens up to you like magic.
  • WhateverHappns 6y ago
    > You need to know about 20,000 words in any language to sound fluent Are you sure about this? AFAIK the use of words in a language isn't distributed evenly, but according to a Pareto distribution. Thus, you can speak _okay_ knowing only ~500 words, I believe. It won't sound perfect but you'll speak and understand pretty decently. I once wrote a python script which read words from a .txt file full of french words with their english counterparts and then displayed the french word, waiting for you to type your guess. It gave instant feedback which I thought important for learning anything. The file contained the 500 most used french words according to large book surveys. This was in my last year of school and it saved me during tests where I had to write coherent sentences in french. Edit: Here it is! Zipf's law is what it's called.(https://en.wikipedia.org/wiki/Zipf%27s_law https://en.wikipedia.org/wiki/Zipf%27s_law) and here's an interesting video about it: https://www.youtube.com/watch?v=fCn8zs912OE https://www.youtube.com/watch?v=fCn8zs912OE
• eecc 6y ago
  Yes. Here I am, looking at a Salesforce integration to Dynamo. Several attempts at elegance thwarted by the trashyness of the AWS libraries. The Salesforce data-model a pile of hundreds of ad-hoc fields. I wrote the most Java1.4 code I ever wrote, copy-pasted the hundreds of fields into a spreadsheet and am slogging through the list picking what to keep and what to ignore. It will get done by pure force of labor, and the customer will be disappointed by “what took you so long” Sigh
• hutzlibu 6y ago
  "People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it." Well, for some people it is indeed impossible to keep on working on boring tasks regulary without going crazy or dying inside. I feel like this. And I was proven right on quite some times - to not do an endless work of stupidity - and instead find a clever way around to automate and save on it. Famous example would be the young Gauss, whose teacher gave them the task of adding all the numbers from 1 to 100, expecting them to be busy for a while. And Gauss just did (n+1)*n/2=5050 and was done. The problem is just, that very often there is no magic bullet like this and the work remains just dull work (like in the article) - and then you can just loose by searching for the magic solution, while avoiding the actual work. Organisational it makes sense, to have enough people capable of reliable doing dull work - and smart (but lazy) people who come up with clever tricks to save the dull workers at least some grinding.
  • beigeoak 6y ago
    It's not necessary that these two approaches can't coexist. In my experience, you HAVE to put in the slog to gain deep knowledge which lets you do these "clever tricks". https://twitter.com/ID_AA_Carmack/status/1311343418422046721 https://twitter.com/ID_AA_Carmack/status/1311343418422046721
• alfiedotwtf 6y ago
  Absolutely. I go through pain stalling detail to automate my laptop via Ansible. Spent many many weekends wasting time on small details that most people would not even bother to think about let alone burn hours working on it... but now, I have an environment that I can appreciate as magic. Although in the only person who sees the reveal, I’m happy that I get to be my own magician
  • sebelk 5y ago
    What I found in recent times is people that want to automate things that have no idea how they work :)
• ramdsc 6y ago
  I would argue this is predicated on others not knowing your doing on the days leading to the delivery of the result. This is fine for a magic trick, but I think the work example may be more difficult to realise if there is accountability. It'd be magic if you can deliver an extraordinary value per time unit spent. I also think there is challenge and beauty in completing something which you consider tedious. There is opportunity for exercising self-restraint and speed of delivery.
• monkeycantype 6y ago
  I was waiting for the Marxist analysis. (Ruin the gag by expaining it, I doubled back at the end and only the saw Jacobian not equal Jacobin : https://jacobinmag.com/ https://jacobinmag.com/ )
• hobofan 6y ago
  Going into off-topic: It's kind of funny that in the "Anatomy of a Scene" for "The Accountant" that is linked in the article they explain that for making the scene, they didn't have Ben Affleck write all the hand writing himself, but instead took a handwriting sample and used that to make a full wallpaper from it digitally. So they did exactly the opposite of embracing the grind and just simulated it.
• m_a_g 6y ago
  I'm a junior SWE and doing maintenance or working with legacy software is a big no for me. I realized this is mainly because I can't see the value these jobs would bring to me so I can't motivate myself. I wonder, what is the motivation for working with these kinds of systems career-wise?
  • Too 6y ago
    Working with a big legacy code base is an infinite source of teaching and knowledge, especially around system architecture; what works, what doesn't work, how the craziest workarounds can make something impossible possible, how APIs with the best intention got abused over time, value of tests and where to test, how to read code rather than just write code, and so on. Simply it gives you wisdom, rather than you reinventing the wheel to find things out along the way. I wouldn't want to do it forever but for a junior to try it out at least once is an important life lesson.
  • DocTomoe 6y ago
    I'm a senior developer, and that would be a major red flag for me, which I would remember during our annual feedback time. Your statement is indicative of a junior who is unwilling to learn about the system and to do grunt work, which directly translates to due diligence and bug avoidance once it's feature implementation time. Do not underestimate the value in working in legacy code for learning how to do things, how to do them better, and how sometimes not following the hip technology fad or the more academic approach is the right thing to do.
• heymijo 6y ago
  Anyone ever read The Phoenix Project [0] or The Goal [1]? The scenario the author described sounds just like the beginning stages from the Phoenix Project (overwhelming amount of tickets, what's the priority, what even are all of these tickets, printing them out to make the work visible). The concept is Work in Process (WIP). You first need to see it and understand how it moves, or doesn't move throughout the DevOps system. It seems like there might be a quick, easy read that could truly help OP. [0] https://www.goodreads.com/book/show/17255186-the-phoenix-project https://www.goodreads.com/book/show/17255186-the-phoenix-pro... [1] https://www.goodreads.com/book/show/113934.The_Goal https://www.goodreads.com/book/show/113934.The_Goal
• jeffrallen 6y ago
  Here's a tip: if you can put a number on some part of your grind, and you have some colleagues who are competitive, with each other or with the metric itself (i.e. "can't stop, the warning count is not ZERO!!1!) then you can get help grinding. I joined a team with 2000 compiler warnings, then set up CI. The "compiled, but with warnings" orange box stayed orange, even as I started killing warnings a few at a time. Then I put a "grep warn | wc" in the CI and another colleague got into the game and drove the warning count to zero a few days later. I immediately checked in -Werr and we never had a compiler warning problem again. Grind, but have a plan to stop grinding.
• matchagaucho 6y ago
  tl;dr "If you're too big to do the small stuff, then you're too small to do the big stuff"
• anm89 6y ago
  I thought this was from jacobin.com and I was very confused
• novosel 6y ago
  For example, no.
• permo-w 6y ago
  “Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding“
• garfieldnate 6y ago
  >People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it. Actually, what he did doesn't sound boring to me at all! I love cleaning and organizing, and it's one of my favorite things to do as a programmer. But it's the type of work that we tend to feel like we don't have permission to do.
• dicroce 6y ago
  I'm building a deep learning dataset right now... I feel the grind in my bones.