A couple of friends and I recently decided to write a mailing list server in Haskell. We’ve taken some derision for this1, with people telling us that there are plenty of them out there already, but we also have a couple of fairly powerful forces motivating us to do this. One is, of course, to learn Haskell better, and nobody can really argue with that. But another is that there are certain features missing from other mailing list managers that I feel are important.
久しぶり (“hisashiburi”) in Japanese means, more or less, “Long time no see.” And it’s been more than eight months since my last post; so much for the promised next one on DSLs!
As it turns out, the pressures of programming full time, running a business on top of that, and making a little non-computer time for myself leave little time for my “mostly for fun” computer-related activities, such as mailing lists, TSAC, and of course this blog. I will admit I’ve been spending a noticable amount of perhaps less-productive time posting to the TLUG mailing list; I’m thinking I should try to redirect a bit of that here.
As we improve our programming skills, we learn in different ways, and from different sources. Drawing my my experience and current state, my theory de jour is that your level of learning and the technologies and methods you use fall into four different stages.
Recently on Worse Than Failure, Alex Papadimoulis posted an article entitled Avoiding Development Disasters.
The article certainly gives good advice: make your software maintainable, generalize when necessary, have a change-friendly environment. But it doesn’t give much help when it comes to the specifics how one might implement these rather general concepts.
Here’s my hint on the matter: I suggest, when you’re sitting down to develop a feature, you design and write the code and the system around it with not only the intent of making it perform the function you need now, but also with the intent of being rewritten later.
Despite the amount of time we here at Starling seem to spend on sales, business administration, accounting, systems administration, and all of the myriad other things that go along with running a small business, we still find a reasonable amount of time to spend on actual development. Development, besides being our most enjoyable activity, is after all the whole point of the company.
We sit between a couple of computers and a whiteboard, and though we’re often writing code, we’re constantly switching back and forth between typing, talking, and drawing. Much of the work we do during this would be considered “design” or “architecture” work in many shops, and would be done in meetings separate from the time you spend in front of your computer coding. That’s why we prefer to call what we do during these times, “development” rather than “programming.”