1. 10
  1.  

  2. 7

    Folks - take notes!

    I am shocked at the number of developers/engineers I work with that are debugging an extremely complex problem, and force themselves to keep so much state in their head. If you can write out the debugging steps more like a journal / record of every action you took, it’s much easier to reinflate your subconscious state.

    Make it refined enough someone else could reasonably follow along, and you’ll be able to as well. Lots of coworkers in other functions take detailed daily notes as a habit to show their progress to management, software gets lucky as there is an “output” on a small granularity of work.

    As I get more and more reprioritizations & interruptions in my work, I’ve found it’s helpful to have confidence that all but maybe the last 30 mins of work are recorded in a decent fashion (org-mode!).

    1. 2

      I took notes on running a specific regression test at work. It’s something like 50 steps just to set it up [1]. And even then, others that have tried running it have had to fill in information I’ve neglected. It is hard to know at times what should be written down and what doesn’t have to be written down. And that changes over time, unfortunately.

      [1] Why not automate it? Not that easy when you have to set up the programs and associated data across four machines. And then when it’s automated, it’s an even harder issue to debug if the automation breaks down [2].

      [2] About half the time the test fails anyway because the clocks are out of sync. I had to code a specific test for that in the regression test, and yes, for some reason, ntpd isn’t working right. The other times the test fails is because the Protocol Stack From Hell [3] fell over because someone looked at it funny.

      [3] Six figures to license a proprietary SS7 stack that isn’t worth the magnetic flux used to store it. This is the “best of breed” SS7 stack, sadly.

    2. 6

      I can’t agree with this article.

      When writing new code, I can accept that making tasks smaller and discrete doesn’t require as much mental scaffolding, therefore it might be possible in some contexts to handle being interrupted without it being disastrous, but most of the time we’re working on existing code. We are compiling code in our brains and making all kinds of mental leaps stashing temporary memories as we debug and process what’s going on.

      I’m not saying programmers are special snowflakes; I’m sure there are other fields of brain work that are as taxing, but yes, interruptions are catastrophic for programmers.

      1. 2

        I definitely agree, interrupting a debugging session is effectively resetting all progress. Not to mention the fact that the more you have to restart a specific debugging session, the harder it gets, because a sort of learned helplessness sets in.

      2. 9

        This post follows the rule of headlines perfectly: when a headline asks a question, the answer is always no.

        I am not completely convinced that the article’s stated reason is “the reason”, or that the solution is “the solution”. But it’s a good start. And it’s one of my specific pet peeves, so I’m going to share. My general pet peeve is when people of all stripes behave as though they’re unique snowflakes and the rules that govern all other work does not and can not apply to them. My specific pet peeve is when programmers play this “we do black magic and therefore need to be treated specially” game.

        It drives me nutty.

        The solution presented here is a good start. We should all endeavour to implement this.

        1. 2

          This post follows the rule of headlines perfectly: when a headline asks a question, the answer is always no.

          In case you’re wondering, it’s called Betteridge’s law of headlines.

          1. 1

            You might consider why this is your pet peeve and it “drives [you] nutty.” Does it bother you when other people ask for understanding and accommodation in how they work because you aren’t getting your needs met at work?

            Also, I’m downvoting this as trolling and will do the same for any other comment I see on lobste.rs that uses “special/unique snowflake” because we’re all intelligent and articulate enough to communicate without obvious epithets, and the use seems to always precede or be interlaced in some insensitive/dismissive rant.

            1. 2

              Interesting. I hadn’t considered “snowflake” to be an epithet necessarily, more tongue in cheek. Thanks for pointing this perspective out; I will keep it in mind.

              1. 1

                I should also answer your question, because I think it’s a good one.

                The reason it drives me nutty is because my (especially recent) experience is the people who are demanding Complete Silence because they are doing Very Serious Work are also doing at least one (but usually both) of the following: 1) over-engineering and making complicated messes of fairly simple things, and/or 2) implying (or worse) that those who do not demand Complete Silence are not doing Very Serious Work.

                I realize that not everyone will share this experience, but we’re all shaped by our experiences to some extent, and this is mine.

            2. 5

              I’ve never been able to connect with the idea that “programmers should not be interrupted” since for as long as I’ve been programming, interruptions have not been a problem for me. And I do get into a “flow” on a regular basis. Like most programmers, I’m working on existing code and a lot of my time is spent trying to understand it.

              It would be arrogant of me to say that what I do would work for everyone, but I’ll take a stab at listing why I don’t think interruptions are typically a problem for me. This includes meetings.

              • I take a lot of notes to remind myself of things. I also write a lot of throwaway prose in some random file to collect my thoughts. I review them a lot.
              • I repeat steps many times to hammer the point home. What, exactly, did that code do there? Run through it. Then again and study it. Again. And make notes.
              • I avoid doing too much at once. If I’m doing too much, I’ll try to work out some of the details with someone else who is working on a related thing. (I guess I’m interrupting that person, but usually they’re receptive to having such a conversation.)
              • Turn notifications off. I expect many people already do this. Notifications are largely useless even when you’re not doing anything.
              • It’s rare that I consider a meeting an interruption because I tend to know when they’re going to happen and they are often pertinent to the task at hand, even if tangentially.
              • If another developer needs to talk to me, it’s usually related to my work.

              Maybe I’ve been lucky, but if that’s the case, it’s been nearly 20 years of it.

              1. 3

                For me, programming is more of an “atmosphere” than it is an interruptible concentration. When in this “atmosphere” I work on and off but generally persist and keep the state of mind even with distractions and breaks - which I often take small breaks to help think and avoid getting stuck.

                1. 1

                  I like the mental image that “atmosphere” conjures up. Another one that could work might be “milieu.”

                2. 1

                  Once I get into the “flow” I have to be scraped off the ceiling when I get interrupted it’s that jarring to me. Granted, I can only get into that “flow” at home (even there it’s rare when I can descend that far into “flow”) and I work on stuff I enjoy. I don’t think I’ve ever gotten into the “flow” at work to that degree, but that’s mostly due to the work not being that difficult, nor an excessive amount.

                3. 2

                  Distractions are unfortunate but rarely as dramatic as forum circlejerks suggest. And whenever someone explains how they struggle to maintain their Galactic Brain scale puzzles against distracting coworkers everyday I can’t help feeling skeptical.

                  And no, it’s not unique to programming or even knowledge work. I remember municipal buses had “don’t distract the driver” plaque.