Programming satisfaction

The satisfaction quotient is very high with Go. This post isn’t so much about Go, per se, except that I’ve been getting a high amount of satisfaction with my Go programs.

I moved into management last year, and I don’t have much time for coding any more.  I work more managing than I did programming; most of my week is spent in meetings, which means that to get any of my tasks done, I have to put in more hours than the standard 40.  This is a temporary situation; right now I just have very few options for delegation – my team is large, but is mostly offshore, and I had been having difficulty finding good people to hire for the open positions on the team.  However, I’ve always heard that long hours is a side-effect of lower-middle management, so it’s not unexpected.

A couple of weeks ago, one of the problems we had with my project became a critical path issue; there was a technical solution and I thought I knew what the problem was, but none of my team had the bandwidth to address it… so I promised the person who was having the problem that I’d fix an application for him to address the issue.  It was a week later than I had hoped, but I finished it this weekend (the only time I could find to write it), and I have to admit: there is a visceral satisfaction to finishing a piece of code.

Unlike management, in writing software you can complete a job.  The best you can get in management is to finish tasks, and somehow they never seem to be truly finished. You always have to follow up, double-check, cross Ts, and dot Is. Most of my job is recurring activities, and while I automate as much as I can, it’s still a never ending struggle to drive the project forward. While I enjoy doing it, it lacks the joy of completion.

Granted, most software development also lacks the joy of completion, especially in maintaining legacy systems.  Most of the time you’re fixing bugs or implementing minor feature enhancements, or refactoring old bad or mutated code; the types of projects where you can stamp the software as “done,” even for broad definitions of “done,” are few and far between. That’s why I was happy to get into management; all of my jobs for the past decade had lacked that primary satisfaction I derived from programming, and nothing kills love quite so completely than having it become a chore.

For whatever reason, I have yet to run into aspects of Go that annoy me.  I have hints of where I might encounter such annoyances in the future, and I’m sure they exist; to deny them would be to assert that Go is perfect, and I’m not that foolish.  However, I can churn out decent code that works correctly with minimal post-compilation debugging, and that’s a pretty rare thing.  Ruby satisfied the “churn out” part, but failed miserably on the post-deployment debugging aspect.  Haskell was highly effective at facilitating applications which, once they compiled, ran with minimal need for debugging, but just getting the application written was a chore.  Go has a nice balance, and very little boiler-plate, and I’m always amazed at how much I can write with so few 3rd-party dependencies.

It is a rare pleasure to write a piece of software that does a job, and does it right.  That’s the beauty of small systems; it’s the elegance of the Unix philosophy.  It’s intensely gratifying. are pleasure to write a piece of software that does a job, and does it right.  That’s the beauty of small systems; it’s the elegance of the Unix philosophy.  It’s intensely gratifying.