1. 2

    I love this question.

    • Decomplect as a verb, to remove complications. I think I got this one from the Clojure community.
    • Smoke as a verb, to overwork or stress a person, piece of software, whatever. I got this one from the Army, where one of my drill sergeants would often threaten to “smoke us.”
    • All chewed up, to be completely unusable. Also from the Army, where drill sergeants would call us “all chewed up.”
    1. 13

      listen to everything and ignore 90% of it

      This is probably good advice. I’ll apply it to this article.

      1. Avoid comments.

      This varies heavily by language. If the language features documentation strings, as Common Lisp does, then it’s fine advice and that’s how I operate; if it lacks them but still has many first-class structures for documenting intent and whatnot, such as Ada, then I’ll write less comments, but perhaps one or two where I think it’s fine.

      It’s just my preference, but I’ve never been fond of names such as getUserAndAPITokenFromLocalStorage and would rather read the comments, but I’d rather avoid reading JavaScript at all, so this could be seen as a superfluous aside.

      1. “Never use a plugin you would not be able to write yourself.” (credit to Jamis Buck).

      I don’t see any issue with this advice, amusingly. This seems like programmer common sense, perhaps, or should be. I’d prefer to use libraries for what I don’t want to write, not what I can’t, such as implementing a complex protocol I need to interact with but don’t otherwise care about.

      1. Use simple tools.

      Without any malice, this is the worst advice in the article and I vehemently oppose telling new programmers this. Ostensibly, the computer is a machine that is to reduce work on the human and aid in tasks; this advice runs counter to that. Firstly, Emacs is just one tool that enables one to use a remote machine with local tools with its Tramp mode; there are undoubtedly others. Secondly, I’m of the opinion that a programmer can and should gradually replace tools they use with ones they’ve written themselves, although I understand others would see differently. I’m doing this in my own way, gradually, but at least I’m making some progress.

      I don’t in any way support the idea that whatever dumbassery the UNIX or Microsoft gods decided decades ago is the baseline and anything on top of that is superfluous. That is stagnation. That is awful.

      About 10 years ago, I remapped Caps Lock to Ctrl on my keyboard. I like that position so much better. Now I can’t use anyone else’s computer without either getting frustrated or going into their settings and remapping the keys on their computer. Is my enjoyment worth this? Probably not.

      Is this a work machine you’re using for hours every day or a toy? Would, in any other setting, a professional who spends years or decades of his life doing something be faulted for customizing his tools to work best for him and remove strain or friction?

      I suggest one reads what Erik Naggum had to write about this general idea: https://www.xach.com/naggum/articles/3065048088243385@naggum.no.html

      1. Working code is good code.

      I’d argue that working isn’t the only qualification for good code. Good code is eventually finished and requires no further changes to accomplish its purpose elegantly.

      1. Don’t be afraid to delete code.

      I have no argument here, really.

      1. Prefer data.

      This isn’t bad advice, with how it’s phrased. I suppose I would’ve used this: ``Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.’’ –Fred Brooks

      1. Always do the hard thing.

      To me, this is the most original advice in the article, but perhaps I’m simply differently read. I’d be wary of a system that is poor at the outlook, though, such as tens of thousands of lines of some poor language, or really tens of thousands of lines of anything.

      This sums my thoughts on the article; perhaps someone will find this a pleasant read on its own or a good critique. I’d be glad for my articles I submit here to receive the same attention, certainly.

      1. 3

        “Never use a plugin you would not be able to write yourself.” (credit to Jamis Buck).

        I don’t see any issue with this advice, amusingly. This seems like programmer common sense, perhaps, or should be. I’d prefer to use libraries for what I don’t want to write, not what I can’t, such as implementing a complex protocol I need to interact with but don’t otherwise care about.

        This literally goes against human nature, this recent Human Brian podcast[0] explores why humans depend on others before them to solve/understand things that they can build upon.

        My immediate reaction to this comment though was: if you wanted to make a new car seat, would you (or do you need to) know how to make the engine, frame, wheels, etc? I would argue “no”, and that depending on systems you don’t understand is nominally ok. Another silly example: I depend on my local grocery store to sell me food, without me knowing about how to make most of it myself..

        1. https://www.npr.org/2019/01/11/684435633/how-science-spreads-smallpox-stomach-ulcers-and-the-vegetable-lamb-of-tartary
        1. 2

          To “be able to write something yourself” covers a very wide range of possibilities. Do I need to be able to write it myself in a reasonable timeframe? Do I have to already have the knowledge to write it now, or can I take time to study it when I actually need to write it? Given enough time, I should be able to learn most things, so that would actually rule very little out.

          I think a more useful focus is “Can I fix problems in a dependency if I discover them?”. For me, this means preferring open source dependencies, as without the source you are at the mercy of the vendor (who may cease to exist). It also means preferring dependencies with simple, well designed code, which I should be able to understand with a little studying, but without necessarily having to have the expertise right now.

        2. 2

          I really appreciate your thoughts, even though we’re likely to disagree on many things. I only want to reply to one thing – about the keyboard. I remapped Caps Lock to Ctrl on every machine I use, including my work machine I use for hours each day. If I could go back 10 years and tell myself not to, I would. I use other people’s computers a lot more than most people, though; I pair-program with students on their computers all the time.

          I really like your opinion that programmers should replace tools with ones they’ve written themselves. It’s bold and solid advice.

          1. 5

            I pair-program with students on their computers all the time

            Yeah, that’s a bit of a special case. I use other people’s computers… approximately never, so I’m very happy with the Colemak layout and a CapsLock that acts as both Ctrl and Escape and shifts that act as parens on their own.

          2. 1

            Upon reading blog post’s point 3. I got the “somebody is wrong on the Internet” rash.

            Thank you for posting a soothing response, I lathered it in generously.

            1. 1

              You are right about 3.

              If we would not progress with the tools the recommendation would still be “use sh instead of the fancy korn shell or crazy bash”.

              The key is - as always - balance. Be careful about the bleeding edge but don’t limit yourself to the largest common denominator just to be perfectly safe all the time.

            1. 0

              I’ve read a lot of books this year – I set a goal for 52 at the beginning of the year and passed it earlier this month. Of those, here are some of my favorites:

              • [historical fiction] The Half-Drowned King and The Sea Queen by Linnea Hartsuyker. An action-packed fictionalization of the rise of the first king of Norway. It’s very well researched and close to reality, as far as I can tell. Really recommended if you like Bernard Cornwell (and especially if you like him but find a lot of historical fiction troubling when it comes to its treatment of women. Hartsuyker doesn’t shy away from the fact that the past was terrible for women, but also writes well-rounded women with agency.)
              • [kids fiction] Abel’s Island, William Steig. A colleague with a Ph.D in literature told me this was her favorite book, so I had to read it. I read it to my 7-year-old and he loved it, and I found it to be one of the saddest and most thoughtful books I’ve read. If you like books where the protagonist lives by themselves and contemplates nature, you will love this.
              • [fantasy fiction] Senlin Ascends and Arm of the Sphinx by Josiah Bancroft. These are delightful. An unlikely protagonist visits a steampunk Tower of Babel with his new wife. She disappears and he has to dive into the dangerous, crime-filled, and seemingly endless Tower to find her. The book cover says something like “the most unlikely hero since Bilbo Baggins” and that made my eyes roll, but dang if it wasn’t right. I can’t wait for the next of these.
              • [literary fiction] Gilead, Home, and Lila by Marilynne Robinson. These three books, all telling the same story from different viewpoints, are some of the best American literature written. I haven’t stopped thinking about them since I read them. They are meditations on religion, family, loss, history, and more. If you have a strained relationship with your father, they will haunt you and make you cry. Highest recommendation
              • [spiritual] The Way of Jesus: Living a Spiritual and Ethical Life, Jay Parini. Very thoughtful memoir/spiritual guide for those in love with Jesus and not so in love with Christianity.
              • [classic] One Day in the Life of Ivan Denisovich, Aleksandr Solzhenitsyn. I’m so glad I picked this up. I thought it would be incredibly sad and detail the misery of living in a Russian work camp, and I was right, but I didn’t know that it would be one of the darkest of comedies. I don’t want to give away the best part of this book by naming what makes it so good, but I highly recommend it.
              1. 1

                Why did this get downvoted?

              1. 10

                I have yet to hear anyone say that they enjoy pair programming all day, every day, forever.

                I love pair programming — a key part of my interviews includes a pairing session — but I quite frankly can’t pair for more than about an hour at a time, tops about four sessions per day with at least two different people. That’s my personal preference.

                I would be interested to know if the authors team consistently concludes during regularly scheduled retrospective sessions that everyone enjoys doing forced pairing enough to keep it a thing.

                1. 6

                  Let me be the first. :) I love pair programming, and miss it whenever I have to code without it. Doing it for a year kind of ruined me for working alone. (And I’m not an extrovert! In general, I shy away from being around people.)

                  I read about bad pair programming experiences and count myself as lucky that all the partners I had were really great people and invested in the process. I can see how it could go sideways.

                  1. 7

                    In the past, I’ve misunderstood what “pair programming” actually means. Could you elaborate and say more exactly about what it means to you? What does your daily process look like? How did you deal with the practical problems stated, like, say, different editor configs or such?

                    1. 2

                      I’m not the OP, but here is a write-up of my good experience pairing.

                      http://deliberate-software.com/pairprogramming/

                      1. 2

                        OP here: I remember reading your article a while ago (it’s really good!). When I saw the below quote I realized you were talking about me.

                        Some developers love the idea of pairing, not the practice of pairing; they often leave when they discover that distinction

                        A lot of days I would wish I could like it, so I could enjoy my job. I felt like I gave it a fair shot too (2 years).

                        1. 2

                          Do you all have a notion of “going odd”? I probably am “odd” at least 3 sessions a week, which helps for time to think and recharge.

                          1. 1

                            We did but if you’re on a team with an even headcount you’ll never go odd. I wish we could’ve gone odd more often.

                            1. 1

                              Hmm that’s unfortunate.

                              Even with 6-10 in our office, one pair splits most of the time to handle odd work, research, or support.

                              Recognizing when to split pairs while still maintaining the tenet of “all production code written by a pair” goes a long way.

                      2. 2

                        Sure – when I did it full time, I had the same partner for about a week at a time before switching. We worked on a project for 8 hours a day, coding for about 45 minutes at a time with 10-15 minute breaks in between. We usually were co-located, although not always. We had two keyboards and mice, and usually two monitors, and would switch off who was writing code differently depending on the partner dynamic, but it was usually pretty organic – whenever your partner was stuck on what to write and you had an idea, you’d take over.

                        Different editor configurations were definitely a thing that could cause friction, but I don’t see that as a bad thing. I both learned a lot about editor tricks and gained an appreciation for keeping your config as simple as possible. We mainly worked in console-based editors (vi and emacs) as we were sometimes pairing remotely.

                        Remote pairing was easier in some respects. Instead of using one person’s machine, which could have its own config issues, we spun up a VM on AWS from an image we made, so there was a standard base configuration.

                    2. 4

                      I would be interested to know if the authors team consistently concludes during regularly scheduled retrospective sessions that everyone enjoys doing forced pairing enough to keep it a thing.

                      Pairing was already a part of the culture when I originally joined, so it was actually pretty hard to get people to admit they didn’t enjoy it (politically unpopular). It was never brought up in retrospectives. That said, I’d say the majority of the people who worked there did enjoy it and it worked well for them.

                    1. 2

                      This is too bad. I understand the business reasons for it and they make sense, but I really like using Unity. The experience feels more cohesive than anything else on Linux I’ve experienced. Before Unity, I used xmonad inside of Gnome. I’m not sure how that works these days, but I imagine I’ll have to go back to it.

                      1. 2

                        xmonad inside of Gnome?!

                        1. 1

                          you can run xmonad inside plasma4 session, and i3 inside gnome3, so I suppose making the first work with the last one is in the realms of possibility.

                      1. 2

                        I mainly use Python 3 and JavaScript. I use PyCharm to write 90% of my code, with the rest in various text editors (Sublime Text, Atom, VS Code). I do all my version control, controlling processes, and searching over my code in the terminal instead of in PyCharm; I’m just more used to it that way, even if it’s more steps.

                        I use direnv heavily to set up individual development environments and use Webpack to compile my front-end assets.

                        I recently used Docker on two projects and feel ambivalent about it. I might use it more for development environments. I also used to use Emacs for about 10 years and always consider going back. PyCharm and VS Code work well for me for now, though.

                        1. 1

                          fish with essentially zero configuration (some aliases and environment variables). It’s great out of the box and makes living in the shell all day even more pleasant. I don’t install it on servers – I just revert to bash there.