1. 13
  1.  

  2. 9

    For reference purposes, here’s the original (maintained) guide, by ESR: http://www.catb.org/~esr/faqs/hacker-howto.html

    1. 6

      One section I strongly agree with is “Don’t research forever”! I’m extremely guilty of this. I could use a little more advice on how to avert this tendency, though. As a recovering perfectionist, I struggle to do anything if I’m not absolutely certain I’m doing it “right”.

      How do you break out of researching and actually start trying stuff?

      1. 3

        Define “right”. As long as the program does what you expect of it, it’s “right”. It might not survive garbage input or thwart dedicated attacks, but that can be rectified once you have a program that works. A few stores. Twenty-plus years ago I started writing a blog engine. I took over 18 months to write it, as I was constantly paralyzed by design choices and how to handle some very obscure corner cases. I finally had enough and “shipped” what I had, and in the long term, the obscure corner cases were never a concern and in fact, some of my initial designs were downright incorrect (but never implemented). Also, the code you see now is not the code I initially released—every bit of code has been rewritten over the past two decades although it was never a full rewrite.

        Several years ago, I wrote my own gopher server. It served my purpose, but it was absolutely not fit for anyone else to use. I rewrote it so it’s usable by other people, but it took me a bit of time to all the pieces (domain knowledge about what I want for a gopher server, better modules, etc.) into place for that rewrite to occur. In this case, a rewrite was the right choice.

        Also, Steve Jobs always said, “Real artists ship.”

        1. 3

          I’m going to echo the advice I received as a pretty theory-minded engineering student: the map is not the territory. Researching helps you draft a map of your trip to whatever it is you want to achieve, and it’s absolutely true that the better you plan, the better the trip goes. But a) planning is no substitute for the trip and b) there are a myriad obstacles that you won’t encounter by researching and planning.

          Also: imho “doing things right” is overrated – it’s finding out what “right” is that’s actually hard, and that’s often orthogonal to the programming the goes into it. Lots of things are done according to tradition or spec and therefore considered “right”, even though they’re actually pretty awful. Some things you just gotta invent for yourself.

          1. 2

            My experience is obviously different from yours but I also struggle from this to varying degrees, periodically. I tend to break out of it when I’m able to focus on just enjoying the process of programming without thinking of the result of whatever I’m doing. That’s sort of key, actually: in those moments I don’t think about “oh, this might turn out bad, but that’s okay”; the evaluation thing just doesn’t come into my mind until the latter stages of finishing touches and what not.

            This results in a pattern of me having side projects that might be good proofs of concept but are hilariously unpolished, and long stretches where I felt guilty about not producing good, polished projects thus resulting in a dearth of side projects at all. I’ve sort of learned that it’s important not to judge yourself for not being able to get started on something as easily as others can, as the adjustment process for learning how to start earlier is best approached without that extra self-inflicted baggage. Indeed, that might be good advice not just for software but for many other areas of life as well.

            It’s also a good idea to read blog posts from a wide variety of perspectives outside of hyper-productive FOSS developers just to get a better view of what the reality of software is. One of the pieces I’ve seen quite recently, either posted here or on The Dreaded Orange Website, was “It’s OK for your open source library to be a bit shitty”. It helped me feel re-validated in my love for my craft, even when I’m having a dry spell of productivity.

            1. 1

              Developing thick skin is what I’m trying to do.

              Every time that I do anything, it is inevitably terribly embarrassing! I’ve done too much research and can see how badly I did this thing but without practice what can I expect? or I try to emulate something and it just ends up like it’s made by a four-year old.

              So, thick skin. Keep trying while holding a steady gaze on imperfection without casting judgment, I guess this is what meditation is supposed to teach you.

              One really good hint: “Make smaller circles” which Joshua Waitzkin talks about in The Art of Learning.

            2. 2

              There’s a lot to learn

              It’s really easy to forget how much material we have in this medium, especially when you start digging into relatively niche topics. The linguistics themselves is a giant barrier.

              I think every programming or even IT book should preface with “this subject is huge don’t worry if you don’t understand everything from the first go. Going back a chapter or using external material and asking questions is completely normal”

              Whenever I teach someone this is pretty much the first thing I say.