The importance of background knowledge

Programming well requires skill. We’re always taking the product somewhere it’s never been before, and there is no recipe that can tell you exactly what code to write. As developers, our days are full of hundreds of judgment calls. We’re always having to weigh one alternative’s benefits, drawbacks, and risks against another’s, and there are times when the choice is not overwhelmingly clear but a best-judgment decision must be made. We draw on our experience, but we’re also always looking to apply better new techniques we’ve been reading about. Other good developers are always writing about how they solved problems they were facing – is it not prudent to learn from their experiences to avoid making the same mistakes?Someone might say, “How do you know what is good advice and what is bad?” There is no simple rule – this requires good judgment. (Programming is not like being a line worker on an assembly line, where you screw on your piece and pass it to the next person…)

If you can only think of one way to solve each problem, that’s certainly better than not being able to think of any way to solve it. But there may be better approaches you’re missing — for instance, approaches that require less code, are more flexible, more maintainable, more amenable to testing, etc. An approach you don’t know about, you won’t use. Now, no single less-than-optimal decision will take the company down… but to remain competitive long-term as a company, these day-to-day individual decisions need to be made well.

Another aspect: In general, you don’t know what you’ll need to know beforehand – if you did, you could just do a targeted study on that item of knowledge, or take a training class. Sometimes that is the case. But most often, we just can’t know up front all the bits of knowledge that will turn out to have been helpful to know. If we don’t already have a concept stored away in the recesses of our minds when the time comes, we’ll simply miss the opportunity to make use of that concept or better approach without realizing it. That’s not good for anybody!

Don’t Learn

We seem to have a culture in Development right now — am I off the mark here? — where it is unusual, not the norm, for developers to read widely and experiment with different techniques locally to keep their skills sharp.

It has to be the individual developer’s responsibility to keep up on these things. Management can help, though, by conveying an attitude of supportiveness for this type of thing. It feels like the “normal” thing is to make up all our solutions out of our own heads. If we do that, we have to independently discover all the dead ends and good ways of doing things, all ourselves. That’s one approach, but surely not the most efficient!

Do That On Your Own Time
“Ok, great,” you say, “as long as they do that on their own time. I don’t want to see people sitting around reading.” Whoa, wait a minute! If we’re thinking this way, we show that we really don’t believe in the importance to the company of developers’ continued learning — the things in the first three paragraphs. On the other hand, if we do believe this is important and necessary, how can we ask developers to do this on their own time? We place people in a bind when we do that: doing their best work is then at the expense of time with their families. My guess is that this leads many developers to forgo the learning since it seems to be frowned upon.

Those who are strong enough to overcome this either do what they need to do during the day anyway or put in extra after hours. For those who put in extra after hours because that seems the only option available, it’s hard to remain excited and happy at a company that seems to offer such little support or have understanding of the importance of these things the developer feels in his heart are important.

But What If…?
The question will inevitably come up, “What about the guy that takes this as license and reads all the time and doesn’t get his work done?” Briefly, I would say the issue in a case like this is not the reading per se, but the developer not taking responsibility for his work. If there’s someone who can’t handle their responsibilities, let’s deal with that. But let’s encourage the rest to do what they need to to keep learning — that’s how our solutions will stay competitive in the industry (and the developers will feel like they’re growing personally, to boot!)


2 thoughts on “The importance of background knowledge

  1. The key difference is that developers are Knowledge Workers. This is a significantly different kind of worker than a factory worker. Unfortunately, many people at the company developed (and continue to develop) their management skills assuming that the factory worker is a good analogy to a developer, and this assumption is flawed.

    I ran into this term reading Peter Drucker’s The Effective Executive. Actually, the Wikipedia page seems to be a fairly good summer of some of the points: Particularly, the section on Management of knowledge workers” is relevant.

    I am sure that those in positions of authority view themselves as knowledge workers and thus believe they have a great deal of latitude in making decisions regarding their time, however, they do not believe that developers are knowledge workers and extend the same freedoms.

    I think some of the discussion around being a “top performer” essentially boils down to being treated as a Knowledge Worker instead of as a factory worker.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s