1. 17
  1. 12

    I think there’s a distinction to be made between the process of programming and actually shipping the artifact of this process in a usable state, as there’s a distinction between designing bridges and building them. The first one is an iterative and creative process of understanding the problem domain, writing code, refactoring it, and so on. The second is an unnatural act which involves a ton of tedious tasks that take a lot of time and little creativity, which I think is why most software written in one’s own time ends up unfinished.

    1. 2

      You’re on to something there. I am reminded of the various artists who love to create but hate the “business” end of things: meeting patrons, marketing, shows, interviews, etc.

      Every piece of art is in some fashion cost-free. You can now build bridges in CGI and they’ll look as real as if they were built in real life. It’s when it meets the real world that it blooms. The only difference that I can see here is the order. For expensive things, the money leads the art. People decide on economic value and that decision drives the art to be created. For ephemeral things, the art leads the money. You can write code all you want in your office without there being any value at all, only to find one day that what you’ve written is worth a lot of money (perhaps)

      I think this essay is perhaps forcing a dichotomy where one doesn’t exist. (I enjoyed it, though)

    2. 5

      I read both essays again. I feel both are too pompous. In some ways I feel Zed Shaw captures the essence of programming better in this essay.

      Computers enable interactive art i.e games, moving visuals so on. I don’t think its sensible to classify widgets and databases as “art” but as “craft”. UI / UX are far more artsy than databases and type systems. Art is emotional and insightful and craft can be beautiful and purposeful. Good code has more in common with literature than paintings or architecture.

      PG is however onto something in suggesting that programmers should adopt more maker like habits than “engineer” habits. I find that adopting a writers mindset - drafts / revisions fits the way I work.