Boring Inside — the 'bee log

I’m burning down some podcast backlog as I wait (and wait and wait) for a plane that’s been delayed (and delayed and delayed) when I hit part of a Hanselminutes episode featuring Jeff Atwood on the topic of building your own PC. At one point, he observes that it’s kind of nice to know what’s going on under the hood of your workstation and that knowing something about the internals of your hardware can make you a better developer.

I couldn’t care less about hardware. I care about my experience — keyboard, mouse, video walls – but the internals — Intel, AMD, pico-hampsters running on pico-hampster-wheels – make absolutely no difference to me.

To me infrastructure is a dial tone. It needs to be there, respond to my request, and let me get to the stuff I care about with minimum hassle. I care about understanding a problem or opportunity and finding its most direct and elegant solution in software. Of course my workstation needs to be fast and usable. Of course it needs to be reliable. And, oh yeah, if it could look pretty, that’d be an extra bonus.

The developer uses tools to build tools. Software solutions, when delivered into the hands of the end user, are a tool. I build or acquire tools that help me build another tool. There’s a lot to figure out and grok. Throw in our industries frenetic rate of change and there’s plenty to keep me busy for several lifetimes.

Okay. That’s kind of a who’s on first way of saying the craft of developing software is generative: tools produce tools produce tools. Wouldn’t my time be better spent learning and mastering other elements of pure thought stuff? New languages, frameworks, patterns, techniques, and (you guessed it) tools?

I crave the form and trust the details. Knowledge of hardware internals might possibly inform your craft, but an examination of history, art, architecture, city planning, philosophy, or psychology might inform in a more creative, less pseudo-comparative way.

And before I hit publish, some disclaimers:

I would care about hardware if it were part of the problem domain I was making software, e.g. embedded systems, network monitoring, device drivers. As soon as I moved on, I’d stop caring.
I am very thankful that there are people that do care about hardware. Good network design/engineering/support (for example) is its own craft with its own horizon!

Tagged as: cloud, infrastructure

Ken

Yes ! I agree with Jeff. Having a bit of basic knowledge helps you a lot in your work and also other ancillary duties. But only basics. I have seen some people trying to go deep into all the things that they touch. This is surely a waste of time. Nevertheless, my experience says that having basic knowledge helps and in fact generates interest in that field, and also gives you a chance to boss around less knowledgeable people and you become more likely to be promoted as a 'manager'.

Dave

@Evan - Sure those items all belong in my enumeration. You're a scary individual by the way. Can I review your first book? :)

@David, @Ben - Yeah, yeah. I mean I have a basic level of competency. It's wise to know the layer beneath you (OS) and to have some basic troubleshooting ability. I'm not suggesting developers should treat their workstation as a total black box and I certainly buy into self-reliance as a general way of life. I just can't see the hardware modding lifestyle as giving you any kind of competitive advantage.

@Jeff - For the most part I agree. My point boils down to: I'd invest more in acquiring knowledge in a number of other areas before becoming a pc modder. A battlefield service competency and appreciation for quality/performance sure are desirable. I think, though, at a certain point interest in infrastructure becomes a tangential hobby for the professional developer.

Jeff Atwood

> I care about my experience — keyboard, mouse, video walls – but the internals — Intel, AMD, pico-hampsters running on pico-hampster-wheels – make absolutely no difference to me.

I find the outside largely reflects what's on the inside, in anything I build-- whether it's software or hardware.

I'm not saying you need to spend the rest of your life doing it, but building a little basic competency in something that so fundamentally affects your work is a wise idea.

I'd expect pianists to care about how their pianos work for the same reason. Not that they need to be full time piano tuners, mind you-- but they'll know when it's out of tune and what to do about it.

Ben Scheirman

I disagree. Knowing the ins and outs of hardware can really help you with being a better overall computer user.

As a developer, you are expected to be a power user of the computer.

If your PC is running slowly, can you pinpoint the bottleneck? Granted, IT people should be doing this for you, but how often does that really happen? Often times it is software configuration that is the problem, but sometimes it isn't.

If visual studio is flickering or repainting too slowly when you scroll, then you probably need a graphics card with some decent memory on it (not like the Intel embedded video crap they usually give you).

It's incredibly hard to keep up with computer hardware because it changes so fast, but knowing a bit about it can really help you understand how to get the most out of your machine.

The minutes we spend a day waiting for Visual Studio to build, or for unit tests to run, is time wasted. Keeping a tip-top machine is a time and money saver all around.

David Douglass

I'd agree with you if hardware always worked or the infrastructure people took care of everything ASAP. But I've seen too many situations where developers are sitting around like a bunch of helpless babies because they don't want to get down to the hardware level.

Also, to really fine tune your software you need to understand your hardware environment.

Evan

Paradigms, baby, paradigms. Forget learning a new programming language or the latest in-fad tool. Learning a new thought paradigm is where it's at. They are harder to learn than a new language, but there are a lot less of them.

A few good ones:
Procedural (many languages)
Object-Orientation (many languages)
Messaging (many languages)
Functional (erlang, haskell, etc)
Metaobject Protocol (ruby, lisp CLOS, etc)Dynamic Typing
Static Typing
Event Driven

Languages are just the grammer of thought.

And you are right, without infrastructure architects (and all the others), we application architects would be way less effective (and have way less fun).

Areas of Interest

Elsewhere

Yesterday’s Weather