Because, as the article clearly mentions, there's a difference between making something work and making something work right.

I disagree that it's important unless you're the person designing the solution. If you're not (and in many/most teams you won't be) it's far less important.

I guess the key is how often are we just handed a spec and asked to code it up. In my roles, I've never worked like that, I've nearly always had some impact on design - but hey, that's just my experiences.

I would agree with your original point though, that domain knowledge can be learned quickly by a good hacker. Which leads to a more interesting question; what techniques can we use to learn a new domain?

I agree that domain knowledge can be learned by decent hacker quickly up the degree necessary to write good code for that domain.

Sure, if the problem is solved, then you probably don't need to know anything. But implementing other people's solutions is only satisfying for so long.

I don't disagree with that, but there are plenty of people that make a career out of it. In the case of ex-colleagues who find a corner at a big multinational and get told what to do, someone else translates domain knowledge for them, and they come up with tech solutions to the presented requirements.

And then there are people like me who get called in because we're good at picking up large, existing, broken codebases quickly and somebody's in the sort of trouble that's best summed up as "Oh $&%£ we've got three months to deliver, the product's less than half-done and it's full of weird intermittent bugs". I'm finding it satisfying enough for now :)

I should add that I'm not claiming 'shit-hot coder' status as mentioned in my original post there. I like to think I'm pretty good, but blowing ones own trumpet is more than a little gauche :)