I like to glue things together

Over the holidays, I ran into a blog post Whatever happened to programming? from 2010 by Mike Taylor. In it, Mike argues that development has lost its appeal to him because it’s so much of putting together pieces other people made and less about creating things from the scratch. He has also written a follow-up based on the comments the original post received.

Is that programming?  Really?  Yes, it takes taste and discernment and experience to do well; but it doesn’t require brilliance and it doesn’t excite.  It’s not what we dreamed of as fourteen-year-olds and trained for as eighteen-year-olds.  It doesn’t get the juices flowing.  It’s not making.

He also quotes Donald Knuth from the book Coders at Work:

“The problem is that coding isn’t fun if all you can do is call things out of a library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career?” (page 581)

Now, I’m not gonna argue what other people should or should not enjoy. But it was a good piece that got me thinking about my relationship with software development so here we are.

When I want to build something (usually happens on Saturday evenings as I’m not a professional developer but mostly a hobbyist), I’m very happy I don’t have to build the building blocks but I get to install the frameworks and libraries I enjoy and get a running start.

With a quick django-admin startproject I get to run with a good bunch of tooling and boilerplate written by people much smarter than me. I don’t have to think about how to build templating engines or ORMs and migrations. I get to write code that is specific to my current needs.

In his follow-up post, he remarks:

Here’s a rule of thumb (which, like all such rules, is often broken and should not be taken too seriously): beware of anything that calls itself a Framework. Anything that, instead of providing stuff that you can call, takes over the wheel and tells you what code to provide for it to call.  Not always, but often, that marks the line where this stops being fun.

I’m bit 50/50 when it comes to frameworks but with good ones I do enjoy that someone’s put thought into figuring out some subset of good practices on how to connect pieces. I actually like the fact that frameworks guide you to write certain type of code because it makes it easier for others to understand, modify and extend when it follows the style and conventions.

One part of the Ruby on Rails’s The Rails Doctrine I like is Convention over Configuration.

Not only does the transfer of configuration to convention free us from deliberation, it also provides a lush field to grow deeper abstractions. If we can depend on a Person class mapping to people table, we can use that same inflection to map an association declared as has_many :people to look for a Person class. The power of good conventions is that they pay dividends across a wide spectrum of use.

I do empathise with Mike’s overall viewpoint though. Even I don’t enjoy writing endless enterprise CRUD forms and reports. And I occasionally enjoy writing tools from the first principles. But I’m definitely more of the type of developer who cares about the outcome than if I built all the pieces to get there.