Personal productive the UNIX way
January 30, 2008
A lot of people read Lifehacker, and if you don’t I’d recommend putting it on your RSS feed. I often find a good tip, tool, or technique that just makes my world that little easier.
Anyway, I discovered a nice post the other day about applying UNIX philosophy to personal productivity. Before I get into the post, if you are into personal productivity you really should be reading JD Meier’s blog – the guy is just packed with productivity, leadership, and management ideas and it’s either that he’s super organized (with the focus of a laser beam) or I’m just woefully behind
So, the original UNIX programming philosophy tenets (if you don’t know them, or can’t be bothered to click through) are…
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
- Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
They’ve been modified, extended, changed over time, resulting in a series of “rules” that form the structure of the Lifehacker article, but the basic principals are still there. I try to program to these and the main ones for me are to “try (test) early and often” – it’s best to get something working and out there then improve, “fail fast” – if something is not working, stop, but give enough feedback to understand why, and “build as simply as possible” – there’s less chance of defects, and more chance you’ll understand it when you come back to it!
I guess I’ve not really thought about these in terms of personal “programming”, but these principals seem to make sense in that field as well.

Posted in

