1. 14

I’m working on a management article and would love some input/data/stories/discussion from the community on this particular topic. Specifically what makes you happy when writing software? It could be a handy script, part of the development process (humans included), the problem domain, the code itself, a particular library/framework/language etc…

For example, when I am writing software for open source projects, I am happy when the barrier of entry is very low. Ideally, I can clone and run the project locally very quickly. It is easy to reverse engineer the code and figure out where to jump in. Additionally, pull requests are reviewed and merged in a timely manner. Someone “cares” and acts on the work I put in.

Another example of joy (from my full time job), is a script we have that will perform an “automerge” for us. We have a very strict policy of requiring a code review (+1), a quality review (+10 or +QA), passing unit/functional/integration tests, code coverage thresholds met, security assessments, etc… before we allow a merge. When all of this has been accomplished on a pull request, this automerge script kicks in, scans for all the requirements, and if satisfied actually performs this merge. This eliminates a PR sitting waiting for a human to perform these checks (which can be error prone).

Perhaps better stated: What are the patterns, qualities, and/or characteristics of a project/process that makes writing software enjoyable? I’m looking for good stories from the field.

Thanks in advance for the help. Keep smiling :)

  1.  

  2. 13

    Knowing someone cared about the thing you made. Even just one user is enough to make me happy.

    1. 6

      I’m happy when this is normal and easy:

      • Get an end user bug report and reproduce it.
      • Write regression test.
      • Write fix.

      The support for testing needs to already be there, the code needs to be designed well enough that adding new tests is easy, and enough information can be gleaned from a bug report (e.g., useful logs) that one can understand the actual problem.

      1. 6

        I don’t enjoy writing software and that’s okay.

        It is my profession, and I am thankful for the opportunities, privilege, and freedom it gives me. I do enjoy keeping up with my colleagues on sites like lobsters to stay relevant, and I even enjoy writing about software. That said, I find myself rarely coding for fun.

        That plucky boy who is always coding hasn’t been me for a while.

        1. 2

          Do you have a non-coding-hobby that takes up your free time?

          1. 2

            The vast majority of my time is consumed by work and spending time with my partner. What little time I have leftover I spend reading and playing video games. On commutes I listen to podcasts (never technology related). On Wednesdays I have a remote D&D group that I DM for. That’s kind of my whole life. 🙂

            1. 2

              Sounds alot like my life too, the reason I asked was because I couldn’t tell from your first message if you were burnt out from your day job or if you just had different interests. (I’ve been in both scenarios.)

              1. 2

                Oh it’s definitely a bit of column a, bit of column b. 🙂

        2. 4

          Just if the real world problem domain is compelling.

          • If I’m writing some bogus web service for some bogus business goal => unhappy.
          • If I’m writing something (anything!) that I know will make people’s lives actually measurably better => happy.

          Code style/language/libraries/development process is a minor factor added or subtracted from that.

          1. 2

            How have you moved away from writing silly web services to (hopefully) writing software that makes other people’s lives better for a living?

            1. 1

              I haven’t, at least not consistently. I am not happy.

              I don’t think there are very many pure software jobs that accomplish this, so I am trying to balance a desire to start my career more or less from scratch with a need to continue supporting my family through the transition.

            2. 1

              What about a bogus web service for a semi-bogus business goal (i.e. you don’t fault anyone for the goal existing) that reduces the number of annoyances in the life of the person doing the manual part of the work on the same goal?

              1. 1

                I guess there is a spectrum there, but generally I would desire more impact than this.

            3. 4

              While writing (as opposed to “having written”) software, I think my favorite experiences share these characteristics:

              • I can use my existing fluent toolset — I don’t have to poke around the framework of the month or some new API.
              • I have spent enough time thinking through the problem to have a detailed sketch of how to solve it (or even a prototype) that seems plausible.
              • It’s easy to write tests for the solution, so I always know I’m making progress.
              • Each component I implement makes an almost audible click as it fits perfectly into the system where it belongs.
              • I can tell when version 1 is complete, and even better, it actually does something like what was intended. :)
              1. 2

                For me it comes down to this - do the abstractions the language I’m working in fit the problem domain? Or do I find myself thinking “God why am I re-writing this string parsing routine - probably BADLY, when it should be included in the standard library?”

                1. 2

                  Like others, the problem solving and constant learning was what drew me, but now having had a few years of experience, what makes me happy and eager to work is when I am allowed to do the best I can instead of compromising quality in the name of shipping. I know nothing I do will persist, but making my best effort is what enables me to continue to hone my skills, and feel some sense of personal development.

                  1. 1

                    It is enjoyable when the limiting factor is actually developing an algorithm or a good model for some problem. And preferably in the context where the language and circumstances allow me to represent whatever my model of a solution is, without translating it into a different ontology by hand (Common Lisp is nice, Julia is nice — but constantly changing, POSIX Shell is often nice for some tasks that fit).

                    1. 1

                      The problem solving is what originally brought me to programming, the idea of fixing a puzzle or a bunch of little puzzles and coming up with a solution that will help other people.

                      These days I also take a lot of enjoyment out of type theory and it’s application in everyday programming.