Details, details

We like to think that software is infinitely malleable. I’ve been reflecting over the past couple of weeks on why what we software engineers do is particularly hard. After all, what does a software geek do every day? If you’re lucky, you come into work and read and type all day, maybe go to a few meetings, and talk with people. It’s not like heavy lifting or making big rocks into smaller ones, it’s not back-breaking labor. But it’s not necessarily easy.

This week has been all about the nitty, gritty details. I’ve been doing work at the machine instruction level, and it’s been exhausting and exhilarating, and I’ve done some neat stuff. This is, I think, what neophytes are missing when they learn Java as their very first programming language. Consing up objects is never free, it’s never going to be free, and there will always be a need for folks who understand what’s going on in the depths, even if they never write a language runtime. Details like this can make or break products, they matter.

Details like, how many instructions does it take to allocate an 8 byte hunk of memory? How many common code sequences are there in an application? Will a particular structure layout perform better if the cache organization changes? Can I add a particular feature without breaking Joe’s work? Is Joe going to clobber my work and make forward progress impossible until we get the wreck untangled and back on the tracks?

I don’t see these necessary details disappearing from the industry any time soon. Maybe in fifty years.

It’s amazing anything works. I don’t mean this perjoratively; it’s simply amazing that so much stuff can come together and fly in tight formation well enough to be, say, a working cell phone or even a lowly television remote. Taken in isolation, with only a few exceptions what we do is not all that hard. Taken as a whole, it’s a wonder that things don’t crash and burn more often than they do.

This entry was posted in Uncategorized. Bookmark the permalink.