Irreal

As long time readers know, I am always looking for ways to make my work flow more nearly frictionless. This mainly involves adapting my existing tools (especially Emacs) and adopting new tools. I recently came across a couple of posts that address these. Since they seem generally useful, I thought they were worth sharing.

The first, 10 Tools, Tips,and Tricks to Hack Your Workflow, by Dann Berg looks at 10 tools that he uses to make his day more efficient. These range from Credit Karma—used to track your credit rating—to the excellent (Mac OS X based) Quicksilver. I already use a couple of tools from his list and am planning to check out a couple of others. This is a reasonably short post that gives reasons for his recommendations. The post is well worth a look; you may find something you’ll find useful.

The second post, 9 Enhancements to Shell and Vim Productivity, by Daniel Miessler addresses ways of adapting tools you may already have or replacing one tool with a similar, superior one. Obviously Miessler is a Vim user so the righteous will skip over those tips (although Vim users are apt to find them useful) but he has some good ideas. Again, this post is worth a read

Matthew Beale has a really interesting post over at madhatted.com that concerns lessons we can learn from Motown. The “we” in question is the software development community. The post is interesting on its own terms but what really struck me was the story of how Motown worked. Those of us of a certain age are very aware of Motown. They were the record label for groups such as the Supremes, The Four Tops, The Jackson 5, and many, many others. Motown had the highest hits to released singles ratio in history. They had 30 #1 hits during the 1960’s.

For most people that’s ancient history yet as Beale notes they have something to tell us. Here’s how Motown managed to crank out all those hits:

• Each writing/producing team was required to write 5 new songs a day.
• At the end of the week, each team presented their 5 best songs to the other teams.
• Each team got to record their 2 best songs of the week.
• Each recorded tune was mixed, usually about 15 times by different people.
• Each mix was turned into a record.
• The quality control department listened to each record and picked the “A” side that was released and promoted.

This process was so efficient that The Four Tops hit It’s the Same Old Song took just 24 hours to go from writing to release to DJs. That’s really astounding. When was the last time you were able to get anything through the pipeline in 24 hours?

Be sure to read Beale’s post to find out more about the Motown process and what it can tell us about our own processes. Even if you’re not a software developer, you’ll enjoy learning about how Motown managed to turn itself into a hit machine.

Informit has a nice interview with Brian Kernighan about C and programming today. There is, it seems to me, a tendency to disparage C as an old and no longer useful technology. This is, I think, profoundly wrong, something that Kernighan seems to agree with. I’ve said before that I’m happy to be able to focus on Lisp these days but I’ve spent a lot of time with C and agree with Kernighan that if you can program in C you can, in principal, build any other environment. Programmers who don’t bother learning C because it’s “old” are, in my opinion, doing themselves a great disservice.

Kernighan also talks about publishing and software development as it’s practiced today. This is a good interview and worth your time if you’re serious about your craft. Recommended.