1. 20
  1. 14

    I’ve learned, about myself anyway, that “frustrated” and “annoyed” are nice-sounding synonyms for degrees of anger, which in turn is always rooted in an inability to control something I want to control.

    I notice that sometimes I feel the same way about a programming task as I have about chess or ranked Starcraft. I haven’t the least doubt I can do it, but it’s so mentally taxing it’s not fun, it’s stressful.

    1. 22

      can confirm the grinding frustration will continue. the best way to mitigate it is to iterate as fast as you can. take a zero tolerance policy to slow modify-compile-execute-reflect loops.

      it doesn’t matter if it’s a binary on your desktop or some rube goldbergian enterprise fizzbuzz on cloud.

      if you can iterate in 1s, it’s less frustrating. way less. it can even become fun.

      all of my github projects are about faster iteration, so i can be less frustrated. the loop shrinking will continue until morale improves. this is the way.

      faster loop on aws: https://github.com/nathants/libaws

      faster loop on webdev: https://github.com/nathants/new-gocljs

      faster loop on services: https://github.com/nathants/aws-rce

      faster loop on browser testing: https://github.com/nathants/py-webengine

      faster loop on react: https://github.com/nathants/runclj

      faster loop on docker containers: https://github.com/nathants/docker-trace

      faster loop on distributed data processing: https://github.com/nathants/s4

      1. 1

        This is a great philosophy, thanks for sharing your projects

        1. 2

          of course! life is too short for needless frustration.

      2. 8

        I agree with some of this, and not the rest. Computer frustration (which includes not just coding, but also various sysadmin-type tasks, setting up hardware, etc.) induces in me obsessive hyperfocus, which other types of frustration (people, writing) don’t. I’m not sure if this is because of computers being a special interest of mine (how I wish they weren’t!) or because they have the property the author notes: that you know the problem should be solvable.

        1. 3

          I’d still argue that programming is still hard, at least in the same way that any of the other other fields given are hard.

          The thing about programming is that it is a very thorough test of your understanding of the details of a thing, a test on the level that most folks who don’t either engineer or build things have not experienced. And, unlike woodworking or model-building, the shape of it is almost always largely in the heads of those who are building it.

          Which means that interacting with a programming artifact, either through tests, build errors, or just poking at it, is how you understand the reality of how it works, as opposed to your intention. Which means your ego needs to either tolerate a lot of blows, or not be based on getting things effortlessly right the first time. Tool Assisted Speed Runners are perhaps the most extreme examples of this sort of understanding.

          So yeah, a high frustration tolerance tends to come out of folks who stay in software development.

          1. 2

            Not sure I completely agree with the main premise - “A very high tolerance for daily, grinding frustration.” - but some probably see it that way.

            1. 6

              I think there’s some truth in it. A few weeks ago, I spent a day chasing a bug that ended up being a one-character fix. Recounting this to a non-programmer, the reaction was ‘I don’t understand why you like computers, that sounds really frustrating’. The same person happily spends hours doing Sudoku and similar puzzles and to me this kind of programming is just another kind of puzzle which, like cooking, has the added benefit that you get something tangible out at the end and not just the feeling of enjoyment from completing the game.

              Whether you regard this kind of puzzle solving as frustrating or not probably has a large impact on whether you will find days full of programming to be an unmitigated torture of frustration or a joyful activity that you can’t quite believe people are willing to pay you for.

              Of course, some parts (notably, almost anything involving build systems) will be frustrating for almost anyone.

            2. 2

              I don’t want to be dismissive with that, but maybe it’s time to get a different job then? In my experience people who consider programming to be frustrating tend to also be pretty bad at it and kind of were pushed into that job in one way or another.

              The most (openly) frustrated people are in there because it makes them money, spend most of the day in meetings and don’t solve problems but glue things together rather than solving (new problems). So their job seems to mostly be building prototypes of products, sometimes doing things that for example someone with a CMS could easily do.

              My current hypothesis for that state is that we have a lot of people that can program, but shouldn’t/don’t want to be programmers (the way that someone who can write, might not be the perfect author or someone who can cook might not be the best chef). Some of them then made their way into a management position or into technical sales or writing introductory books, etc. being way happier and a lot less frustrated. However, there is a lack (perceived or real, that’s another discussion) of software developers (and other fields, like SRE), so as soon as you mention it the whole world wants you to write code for them offering you good money for doing so. And once you are in there it can be very scary to think about changing the career, either completely or just another field in IT.

              I think the solution isn’t laying abstraction above abstraction, having the five millionth web framework that is mostly marketing and tricks programmers into thinking they just need another tool, language, platform, etc., but encouraging the take a break for a while and try out a different career path.

              The reason for writing this is also a bit selfish. People who are among the nicest people I’ve worked with, simply were a drag. Lack of motivation and frustration can get developers into a state where they just want to be over with stuff, hacking things together that others have to deal with later on. And then we have the effect that it’s not just one person being frustrated, but others having to cope with sometimes pretty subtle effects coming from that.

              It also certainly doesn’t help that people are told that they have to be passionate all the time about what they are doing. That way they are taught to feel wrong when they are not which I think enhances the chance of self-delusion.

              Of course all of this isn’t the only reason and it’s just a hypothesis. But maybe that applies to someone reading this and pushes them into doing something that doesn’t cause them to always be frustrated, thinking that it’s just their tools, their employer, their team, etc. Maybe they get a way better job and will have a life of joy rather than constantly or frequently being frustrated about what they are doing day to day.

              1. 2

                “But when you’re stuck on a coding problem, it feels much more like a deeply personal failure: My inability to follow a logical sequence through.”

                I personally find this mental stretching far less frustrating than many other types of problems. At the end of the day, coding problems are solvable by following some logical sequence, however complex. They are solvable. I came from teaching, where a huge number of the problems that came up in my day-to-day were not solvable in the same way.

                1. 1

                  Yet we do often subject ourselves to more frustration than is necessary. From the article:

                  You solve a problem by taking a break, by letting something ruminate in your backbrain, by confabbing with someone else, by rubber-ducking it. Minds are weird and nonlinear, and so coding can be weird and nonlinear.

                  I often manage to forget this in the heat of a work session. The transition from focused progress to unfocused rumination is necessary, but recognizing that is itself a change in approach. I might eventually figure it out after repeated hammering, but usually I’d have had the same insight with less frustration by stepping away earlier.

                  On the other side, when I find myself unable to reengage with a project, sometimes this is because I’m subconsciously working through problems. One day I’ll suddenly know how all the pieces fit together, and then it’ll be hard to stop. I’d be less frustrated by the lack of progress if I treated this as a formal work mode, but it’s hard to distinguish from low motivation, burnout, or suppressed concrete problems.

                  1. 1

                    Seeing people say that “programming isn’t hard” frustrates me.

                    1. 2

                      Programming isn’t hard, understanding a problem well enough to formulate an elegant solution is hard. Programming is just writing it down.

                      1. 1

                        both are hard. Also, why separate the 2? Both need to be understood by the person working on it anyway (you will never see someone juste write the code thought out by someone else, -I hope-.)