Coding Horror

We're currently undertaking some painting projects at home. Which means I'll be following the instructions on the paint can.

But what would happen if I didn't follow the instructions on the paint can? Here's a list of common interior painting mistakes:

The single most common mistake in any project is failure to read and follow manufacturer's instructions for tools and materials being used. In regard to painting, the most common mistakes are:

• Not preparing a clean, sanded, and primed (if needed) surface.
• Failure to mix the paints properly.
• Applying too much paint to the applicator.
• Using water-logged applicators.
• Not solving dampness problems in the walls or ceilings.
• Not roughing up enamel paint before painting over it.

What I find particularly interesting is that none of the mistakes on this checklist have anything to do with my skill as a painter. My technical proficiency (or lack thereof) as a painter doesn't even register! To guarantee a reasonable level of quality, you don't have to spend weeks practicing your painting skills. You don't even have to be a good painter. All you have to do is follow the instructions on the paint can!

Sure, it seems like common sense. But take a close look at the houses on the streets you drive by. Each street has that one house where the owners, for whatever reason, chose not to follow the instructions on the paint can.*

For years, software development was an entire subdivision of badly painted houses. But the field of software development is now mature enough that we have a number of paint cans to refer to. Here's one such checklist from Joel Spolsky, circa 2000:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The type of paint can you choose – and the instructions you follow – are highly debatable, of course. But make sure, at the very least, you're following the instructions on the paint can for your software development project.

* oddball color choices notwithstanding

Rajesh Setty has some unusual advice for IT professionals: stop wasting time in the technology skill-set rat race, and start building your personal brand:

Jack meets Janet and they start talking. Jack explains who he is and what he does for a living and Janet does the same. While Jack is speaking, Janet is very busy trying to "box" Jack.

She's looking for some tag – "software engineer", "technical architect", "project manager" – something that will make it easy for her to remember. Of course, Jack is doing the same thing. It's a "boxing" contest.

There's nothing wrong with this approach. We all do it. Here's why: When Janet finishes her meeting with Jack and later meets an old friend Paul, Janet needs an easy way to explain who she met. She'll say, "I met Jack for coffee and he's a software engineer" rather than repeating the whole spiel she just heard from Jack.

There is hope, though. If Jack made a compelling introduction, something memorable and remarkable, Janet would be compelled to say a few more words about Jack. Jack won the "boxing" game.

This requires more than communication skills. You need to be working on something that is remarkable or be remarkable yourself. In other words, you need to be working on your "personal brand."

Mere competence in a technical discipline is not enough. That's the minimum required to keep your head above water. To have a personal brand, you must do something remarkable:

• lead a user group
• create a popular open-source project
• write a blog
• publish a book
• publish articles
• speak at conferences

Do whatever you like. Pick one, pick them all, or pick something that's not on this list.* As long as it's public, and it advances your skills, you're creating a personal brand. And that will help your career far more than technical chops ever will.

Prior to reading this article, I often joked with coworkers that I had a personal branding strategy. The Wumpus is my power animal, which I've placed, well, all over the place:

front license plate

polo shirts

stickers

Now I'm not so sure if it's a joke – or an actual branding strategy.

* This is, of course, a tiny subset of all the remarkable things you could possibly do. Rajesh maintains a Distinguish Yourself manifesto which has lots of additional ideas.

Very few software engineers use UML symbols to design software, but electrical engineers regularly use circuit symbols to design electronics:

Circuit symbols are constructed into circuit diagrams-- the the visual language of electricity:

If circuit diagrams are a standard, universally understood way to talk about electronics, why doesn't UML enjoy the same currency for software development?

Well, one obvious difference is that software, unlike electricity, isn't subject to God's laws.* And God didn't invent x86. Software development is far less amenable to formal diagrams because, well, it's something we just made up. And we keep changing the rules all the time. As Brooks points out in The Mythical Man-Month, software developers are essentially playing the role of God:

Why is programming fun? What delights may its practioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctiveness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this tractability has its own problems.)

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

Software developers do not have a monopoly on creativity. A clever circuit is no less imaginative than a clever algorithm. But software development is a "tractable medium." If we decide the speed of light is not to our liking, we just change it. Imagine the difficulty an electrical engineer would have working on your circuit diagram if, on that diagram, you had changed something fundamental, like the conductivity of copper.

But even with the helpful constraint of God's rules, circuit diagrams are still idealized representations of the final product. You need a printed circuit board to implement the circuit diagram-- and the translation from circuit digram into PCB typically invoves a lot of real-world compromises.

This is not to say that formal software diagramming systems like UML aren't useful in software engineering. They can be. But they'll never be as useful as circuit diagrams are to electrical engineers.

* Or the deity of your choice.

Jason Scott, of textfiles.com and BBS: The Documentary, presented a talk on the failure of Wikipedia at Notacon 3 this weekend. I highly recommend listening to his talk. It's fascinating-- full of insights into what makes Wikipedia work so well, but specifically highlighting some of the social problems they've run into as they grow.

Although my experiences with Wikipedia have been almost uniformly positive, I was taken aback when I noticed that there appears to be a Wikipedia entry for every single comic book character ever created. Surely Superman and Batman are worthy of inclusion in Wikipedia-- but what about Monica Rambeau and Jubilee?

Jason's talk provides a name for this conundrum: inclusionists versus deletionists.

The inclusionist versus deletionist debate [within Wikipedia] is as firm and strong as the abortion debate, gun control debate, or the death penalty debate.

Inclusionism says, Wikipedia, because it is a virtual encyclopedia, is capable of carrying the sum of human knowledge-- coincidentally, the theme of Wikipedia. Because of the fact that you can sort things, and you can work things out, you're able to actually keep the sum of all human knowledge on a place, keep it changed, and use the power of the computer. F**k yeah!

The deletionists take the attitude [that] Wikipedia is not a junkyard. An area for the cruft of all aspects of humanity that ever existed, turning into an untenable, Katamari Damacy-like ball of s**t that rolls through the internet. We should clean up stuff that is not important, not interesting, and we should just get that s**t out of there. Who cares about what the names of every character in Serenity is? Who cares? So the idea is, delete that.

Although I tend to side with the deletionists, there's no rational way to decide what's "notable". So the inclusionists-- and the ever-spiraling increase of storage, bandwidth, and CPU power-- will win by default. I'm not sure this is a bad thing. The long tail of micro-content doesn't need to appear in any massive table of contents; it's only a few search keywords away.

Virtual machine images typically don't need much security, so the login prompt is more of a formality than anything else. Plus, if you're planning to share the VM image with others, you need to communicate the login information along with the image. It's a pain.

I've seen tips on how to force the login background to be an image containing the username and password which appears directly above the login dialog.

But there's an even easier solution. Tweak UI, one of the official Microsoft PowerToys, allows you to enable a default login, with no typing at all. It calls this feature "autologon":

I don't know why you would bother with the "bitmap login background" method, as the autologin method is so much cleaner.