Why Software Artisans Should Manage Their Influence

Just read an insightful post from Seth Godin. If you don’t already know who Seth is, and follow him, I suggest you get to know him a bit. He’s a thought leader in the field of permission marketing–the founder of the movement, perhaps. He’s spoken at TED conferences numerous times. Every one of his books that I’ve read is worthy of pondering.

Although Godin isn’t speaking specifically about software craftsmen, I see direct application of his thinking to our field. Since so much of what we do requires buy-in, coordination and shared mental models, we have to be savvy about how we communicate, advocate, and train. Assuming equal technical competence, the difference between effective and ineffective technical leaders largely depends on the mastery of this skill.

Have you considered how to grow your influence? Do you have a plan?

Influence doesn’t always work the way we expect. :-) Image credit: xkcd

Book Review: Universal Principles of Design

A few months back, my friend Trev recommended this book to me. I’ve been digesting it one topic at a time, on my lunch breaks.

It is profound and fascinating reading.

This is not another software pattern book. In fact, it is not really software-centric at all. It describes truths about the way human beings perceive, reason, generalize, and communicate. Many of them have obvious application to UX, UI design, and to software in general. On the scale of profundity, it gets a 9 out of 10; I suspect that I’ll be blogging about insights from the book for months to come.

I think it’s important to look at familiar problems from new angles; many profound breakthroughs in science are attributable to cross-disciplinary insight. Though time spent in this book won’t directly hone your coding skills, it will help you see recurring problems and solutions with new eyes, and it will suggest tried-and-true criteria for evaluating design alternatives.

As a teaser, some of my favorite design principles in the book include: Interference Effects, Contour Bias, Horror Vacui, Uncanny Valley, Recognition Over Recall, Wabi Sabi, Satisficing, and Propositional Density.

For now, I’ll omit any definition of what these intriguing terms mean, and leave discovery as an exercise for the reader. :-)

Interrupting my interruptions

Tonight I was just settling down for a ponder on some personal stuff when I noticed an email from my brilliant brother-in-law (hi, Stephen!), recommending an article about the cost of interrupting programmers. Half an hour later, I’m blogging about it. Yes, I see the irony in the read, the blog, and the shout-out, but I just can’t help it.

I’ve heard lots of estimates of the cost of interrupting, but the research in this article seems particularly clear. I think the article oversimplifies by assuming that the problem and solution derive purely from memory, but there’s enough insight and clever thinking in the article to make it worth a read…

We’ve all known that interruption = bad. We’ve nodded our heads at this wisdom for years. Occasionally we give lip service to it. We try to clump meetings in one portion of the day, leaving blocks of time for serious thinking and work. We advise our teams to use “lighter” interruptions (“ask your question by chat/email instead of in person; it’s less disruptive…”). We decline non-essential meetings and urge others to keep their invite lists small. We buy “cones of silence” and “Do Not Disturb” signs and set them up outside the cube of the guy who’s trying to finish urgent work for an impending release.

And then we fall off the bandwagon.

At least, I do.

Hi. My name is Daniel, and I’m addicted to interruptions. :-)

time_management

Image Credit: xkcd

Symptoms

You would see my addiction if you walked past my desk and looked at the tabs in my browser: two for email (work, personal), two or three for calendaring, some chat sessions, a task list, several programming topics, a man page, a python reference, an interesting blog post or two, three wikipedia pages, a ticket I looked up before I ran to my last meeting, a wiki page I’m in the middle of editing, a competitor’s product portfolio, a LinkedIn discussion forum on cloud computing, a Google spreadsheet, the PDF of a resume I’m supposed have read before I do an interview in an hour, half a dozen random sites that I visit during the day as I check gossip on a competitor or read the Dilbert cartoon someone emailed me…

How am I supposed to think Deep Thoughts when I’ve got that much noise?

Continue reading

All I Really Need To Know I Didn’t Learn In Compugarten

I’m glad newly minted software engineers are exposed to data structures, compilers, concurrency, graph theory, assembly language, and the other goodies that constitute a computer science curriculum. All that stuff is important.

But it’s not enough.

Not all classroom material for CS folks should be technical. Photo credit: uniinnsbruck (Flickr).

Since I’m half way to curmudgeon-hood, I frequently find myself lamenting educational blindspots in the young. I’ve even toyed with the idea of teaching at the nearest university, some day when I Have More Time™. If academia would take me, my lesson plans might cover some of the following topics:

// Comments on Comments

/*

We spend little or no time teaching programmers how to write good comments.

This is surprising, when you consider how often “total lack of comments” or “poor comments” are cited as evidence that certain modules (or the programmer who wrote them) are the worst thing that ever happened to the technoverse.

Comments shouldn’t leave you–or anybody else–mystified. :-) Image credit: xkcd

I happen to think that there are much yuckier tech things than poor or missing comments in code. But I still think our general level of comment proficiency is lower than it should be.

Here is my attempt to raise the bar a little.

Why We Comment

Sooner or later, most interesting programming problems require a sophisticated mental model of a problem. Building these models is hard work, and once we have them, we are paid to share with our team (or our future selves).

The best way to share mental models with other engineers is Continue reading