Pragmatic (don’t be dumb) Programming

Since I have no formal degree in programming, I have been extremely fortunate to work on teams of very talented, smart and diligent coders. Wherever I have worked, the bar has been high, the code has been challenging, and the expectation is that everyone on the team will do their best work every time. The terminology used among these various teams has varied, but the general sentiment is always “Don’t do something you’re going to regret later.” Don’t tie the data to the code, don’t make it hard to extend the program, don’t tie code together unless you have to, don’t make assumptions about what people will do with the application… in short, don’t be dumb. When we were working on the REST interface for Socialtext it was one of the best projects, because decoupling the data from the functions was useful and fun and it just *felt right.* The words used to describe these concepts were general terms like abstraction, pluggability, configurability.

Coming to Applied Minds, I find myself awash in new vocabulary words and frequently find myself scurrying to look up a term that’s been thrown my way. Fortunately, once I do that it generally turns out that yes, I do that, whatever it is. For instance, Data Driven Design falls under abstraction, configurability, and “Don’t be dumb.” But I didn’t know that.

I have to learn a couple of new languages next week in order to create a demo application for us to play with, so I headed off to Borders to pick up a book or two. While I was there, I also picked up the “Pragmatic Programmer” book which I heard referred to so frequently by my cohorts at Socialtext. Yesterday and today I read through it and discovered that it is all full of “Don’t be dumb.” Things I have observed and internalized, but couldn’t articulate quite yet.

The book is an excellent discussion of the way a good programmer behaves, the things they do and don’t do, and how to incorporate them into your workflow. Many of the sections are likely to add more overhead to your project up front – test harnesses, contracts, decoupling, abstraction of metadata. But the return on investment is huge. *Not* doing these things, paying attention only to the here and now and neglecting the future, is where almost everybody gets caught.

I have a strong tendency to want to get to the finish line as quickly as possible, and am frequently stung by not doing these things. Here, I’m starting a new project. It’s not a rush (well, the demo wants to be created in two weeks, but that will be a true “throwaway” prototype for the purposes of playing with the UI elements). So I’m pledging to myself that I’ll keep the discipline necessary to do things right, take the extra time to think abstractly and control the interfaces between the moving parts.

It’s a good book. If you are a programmer and you haven’t read it, you probably should.