1. 143
  1.  

  2. 31

    This is really good. One important thing, though: there’s a spectrum between total automation and zero automation. A couple years back I had to catalogue 2,000 Usenet messages. I wrote a set of Vim scripts that let me pull them up one at a time and classify them with a couple of keystrokes. It still took a lot of effort to catalogue them all, but still considerably less than time without the scripts.

    1. 39

      I think this is a lesson from carpentry. A skilled carpenter will sometimes, for a complex task, first construct a (potentially disposable) jig to make the specific job easier or even possible.

      1. 16

        Must steal this analogy for later. I like it.

        • it’s okay for a jig that only you are going to use to only be usable by you
        • a disposable jig doesn’t have to last past the current problem
        • a disposable jig doesn’t have to be generalisable to anything other than one specific problem
        1. 8

          To me, this analogy perfectly explains IDEs vs. command line.

          IDEs save you time in many common cases. But then there’s the 5% of situations where you can save 90% of your time with a script. Writing an IDE plugin is very different and more time consuming than writing a script to munge text. Either a shell script, or a Vim script, etc.

          So basically the point is that Unix programmers make jigs. People who work exclusively in IDEs don’t. Their tools are made for them and “canned”.

          Honestly I do think this is a pretty big connection between programming and woodworking, beyond the fact that there is perhaps a great-than-random overlap in the population.

          Everything is textis actually similar to “everything is wood” :) That is, both the tools and the final product are wood. So I’d claim it’s a closer connection than “Hackers and Painters”, etc.

          1. 7

            I find it’s a good way to think about increasing your own productivity; an initial investment in a jig program or set of programs that only works for you on your machine for the duration of a particular task can be a lot less work than building a tool you can ship to others or which is more generic.

            Brooks proposed a four tier taxonomy in The Mythical Man Month. Jig programs are firmly in the first tier, a program, which implies both the least general applicability and the least development effort required. But unlike jigs made in the service of woodwork, you can keep past jig programs around and maybe edit them to do something similar in the future – which is in the direction of Knuth’s re-editable rather than reusable code.

          2. 2

            I can personally attest to this. One of my relatives worked with metal furniture construction. He would always build jigs (by welding metal profiles on an iron sheet) to base the chairs or tables on, because it’s simply faster that way; you don’t need to calculate the metal profile angles for every chair then, and they come out perfect everytime.

          3. 1

            You could say that the grind was when you once studied how to write those scripts. I imagine this isn’t the only time your investment paid off.

            1. 1

              You need tools, but those tools can be zero automation pieces of paper and still be effective. As others have said, the Unix way gives people the flexibility to change tools to be most effective, even if that means ignoring the computer completely.

            2. 13

              Indeed. The hardest part of this “technique” is just getting started.

              1. 5

                May every struggle bus soar upon the wings of gumption.

              2. 10

                This reminds me of the long and repetitive text editing tasks that got easier when I had learned vim well enough. I had less resistance to begin. Teammates do tend to view the results or the process as wizardry.

                1. 6

                  Great example. In my experience it also reminds me of learning Haskell (or another pure functional lang) in that it’s frustrating at first but if you just stick with it it gets much, much easier and makes a great addition to your skill set. Also similar is the Rust borrow checker, though that is less frustrating.

                  1. 5

                    I can relate to both of these. Another that comes to mind is Linux, and perhaps particularly in terms of how it appears to the casual observer the usage of a TWM and a terminal-centric workflow.

                    Oh, and touch typing on a keyboard without printed keys. I learned to type properly last year after two decades of hunt-and-peck typing, and now - paired with the above - my partner often tells me I look like a wizard.

                    But it’s just a case of lots and lots and lots of repetition.

                    1. 1

                      Now get yourself some Linear A keycaps and really look like a wizard!

                      1. 1

                        I have runes on mine. Which in addition is 40% ortho. It feels exactly the same to use it among people.

                2. 9

                  This resonates with me, though as others have noted it’s missing one critical detail. Willingness to go shovel the crap until it’s all gone is one of the huge differentiators between the merely-smart developers and the ones that get “most productive member of the team” and “stop it, you’re making the rest of us look useless” feedback over and over again.

                  The missing detail is that you need to be able to pick or make the right shovel so your efforts are effective. To strain the analogy further: grit and determination and a shovel will get the job done better than grit and determination and a teaspoon. Accurately identifying cases where spending time building a tool and using that tool will get you through the immediate set of tedious work faster than doing the work without building the tool is more of an art than a science, but it’s a skill worth cultivating. “Always build a tool to automate every repetitive procedure so you save effort over the long haul” is often not the right answer, but it’s an easy trap to fall into.

                  1. 8

                    Can definitely relate. When faced with a ton of work it’s easy to fall into analysis paralysis to try to figure out the best place to start. The end result is usually that you never start at all. Usually you know deep down that what you really need to do is just to embrace the grind. There often are no shortcuts, and the optimal theoretical order of things is secondary to any order that results in actually getting it done.

                    1. 5

                      I just spent the last few weeks going through and categiorizing (and possibly fixing) all the test failures in a GCC port I’ve been working on for a while. It was tedious but necessary. The happy result is that nearly all of the failures were minor environment issues or simple, inconsequential errors.

                      As a bonus, I now understand much more about the interals of the product because in many cases I had to dig into the actual problem. That grunt work can pay off in much deeper knowledge.

                      1. 4

                        Our whole industry is dominated by hype. For any problem you want to solve, there are 74 different tools that will promise to solve it. Sometimes they can but mostly they can’t. Sometimes you need to “work smarter, not harder” – but sometimes you also just need to work harder.

                        1. 4

                          One caveat here: the grind with a goal you find valuable can be well worth it. The grind with a goal you find pointless can be soul-destroying. Magicians do magic because they really love seeing people interact with the trick. The guy closed the bugs because he really wanted to see that bug list empty.

                          The reason we starting using the word “grind” so much was that people really loved video games, but sooner or later, many of the games required them to do things just, well …. because. Perhaps because the game developers thought that making the people suffer would give them greater enjoyment once they finished. Perhaps because the games were poorly-designed. Whatever the reason, the grueling nature of the gameplay quickly departed from any shared goal the players had. It became a grind. (Grind was used, of course, before that, but the word really took off when grinding became a part of games)

                          I’ve heard a lot of folks say that the secret to success involves placing your butt in a seat and working and then continuing to do that. We have a famous problem in our industry of an inability to stay focused. This essay is very good and has value. There’s also a concept of choice and dedication that comes before you begin your embrace.

                          1. 5

                            We know exactly why video games in the late 80s and early 90s were “Nintendo-hard”: Because they were quarter-munchers. As the arcade-game producers migrated to home consoles, games were expensive and often rented from video-rental stores; game producers could no longer munch quarters with sheer difficulty, so they started making games longer in order to require multiple rental periods in order to complete the game. Eventually, this mutated into the grind with the advent of immersive social virtual worlds, which wanted to enmesh people with time sinks.

                            Surprise, it was capitalism all along.

                            1. 1

                              I don’t disagree that capitalism is why companies make what people will buy (which seems obvious), but the quarter-muncher thing doesn’t really add up, nor does the video game rental. In the wiki article of Nintendo Hard that you linked, it states that games got more difficult because the game devs were constantly playing them and knew how to do stuff, so they kept making them harder. This makes more sense than “quarter munchers” since the arcades frequently had different games altogether (i.e. a Nintendo release was not likely the same game as in the arcade even if they had the same name) and many of the hardest games for Nintendo never had an arcade release at all.

                              It also ignores games like Tecmo Bowl which had quarters-per-quarter (of the game) which weren’t difficult at all, but had a different model for checking to see if someone paid enough to keep going. I also remember some beat ’em ups that you could play X levels before popping more quarters in.

                              For the rental thing, some family friends owned a rental store back in the 80s and 90s and they paid a lot up front for a game, but didn’t pay per-rental fees or anything on a game. For example, let’s say a retail copy of Mike Tyson’s Punch-Out goes for $60, the rental one might go for $1000. Then the store makes their money back over time by getting people to rent it (and charging fees for being late). Especially in smaller shops in small towns like mine at the time, they pretty much got whatever was promoted as being the hot title. It was very rare to find a game that wasn’t mainstream/in gaming magazines.

                              I think the “grind” part of video games comes more from direct consumers than those other models. People want to get their money’s worth. A lot of Nintendo games were 2-6 hours long – if you could figure out the tricks to beating them, you could speed run them in a few minutes. So do you really want to throw $60 at a game that will only give you a couple hours of fun? Especially back in the 80s or 90s ($60 in 1992 is roughly $112 today), that’s a lot of money to spend on a short, unfulfilling game.

                          2. 3

                            I think the unmentioned part is that he had a boss willing to allow him three uninterrupted weeks to do this.

                            1. 2

                              I wrote a response to this: Grind Smarter, not Harder

                              1. 2

                                This is a perspective I really appreciate. Satisficing is an approach that’s appropriate for most projects - often the cost of producing an optimal, generalizable solution to a problem is greater than the cost of solving the problem you actually have in a sufficiently good way. I think the principle underlies a few common rules of thumb, like recommendations on how many times code should be reused before being made a function. But it’s a lot more general, and I suspect getting good at satisficing is a core part of what gets generally categorized as tradecraft, expertise, etc.

                                1. 1

                                  I baffled to see (again!) the magician metaphor that hindered and still hinder progress in Python and Django in particular.

                                  1. 2

                                    Where was it used before?

                                    1. 2

                                      It is common with Django to hear the following:

                                      • How it works?
                                      • Magic!

                                      Same for PyPy, or anything beyond rendering <a> inside <div> with string concatenation..

                                      1. 11

                                        That’s not how the article is using the magician metaphor, though

                                        1. 4

                                          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.

                                          The point is that it is not magic.

                                          1. 3

                                            Where have you heard that about Django? I haven’t heard Django described as magic since magic removal (pre-1.0).

                                            1. 2

                                              PyPy is not magic, for what it’s worth. It is big; a full understanding of how PyPy works usually requires covering some of what RPython is and JITs.

                                          2. 1

                                            I agree that the “magic” attitude is not great, and part of what makes Flask great is that you can always look under the hood and see what it’s actually doing. The __new__ stuff Django pulls off with models can seem like “magic” until you dig for a while and realize that it’s just putting the models in a dictionary and iterating through the subclass’ attributes to see what columns it should generate for the database schema.