display | more...
This is equal parts an attitude and a style. It is typically encountered among systems programmers as opposed to application programmers, but that is far from a descriptive condition. It can be described most concisely by admitting that the programmer knows he is on some level writing code for other programmers, and therefore has the irresistable opportunity to pass the buck.

Almost all programmers start out having the buck passed to them. This is somewhat similar to a fraternity hazing ritual. If you have ever had to write bug workaround kluges for Netscape or DirectX or Flash or some obscure version of libc, you have had the buck passed to you. From then on, like a child of abusive parents, you must struggle not to pass on the abuse yourself.

That can be hard - it often means standing up to your manager and demanding that 3-5 months of QA that was originally in your schedule, until it was "prioritized out." It can mean a bunch of extra long nights thinking about obscure ramifications of interactions between absurdly complex systems which you've designed your program to interact with. More important than anything else in breaking the cycle, however, is the fundament: you must properly and thoroughly document everything you do, in your code, in the man pages, on your website, and wherever anyone is likely to look for answers... like, say... your error messages.

Like veteran airline pilots, good programmers are valuable for that crucial 15 seconds of their career where they may have the opportunity to pass the buck. Most of the time, your job is to "make it work" - and that means, in the real world, it doesn't matter if Microsoft has passed you enough bucks to pay back the national debt (which, actually, it has) - if it's broken, quit your whining and start writing a workaround. You will ferret out each bug that affects you and - since you are always unable to fix the underlying problem (it's not your code, it's been burned onto millions of CDs, etc) - you are now going to do 2 to 10 times the work it would have taken to fix it in the first place to work around it. And by the way - no matter how many of these little design-destroying landmines you stumble across - don't be late.

Bucks are passed from people who have a moral, economic or intellectual inability to do a good job writing their code to people who have no choice but to do a fucking brilliant job. Just like in the real world, bucks are passed from the inside out - from the rich to the poor, from the planners to the inhabitants... and it is a rare and wonderful thing when the buck-passers have to choke on their own medicine. Usually, though, by the time you even know how badly you've been screwed, they've been safely insulated from your feedback, and they're off to botch another ivory tower standard-setting project, consigning you to the hell of a thousand lying APIs for all eternity.

See: Netscape Navigator, Microsoft Windows, Macromedia Director, etc. etc. etc.

Sometimes, of course, it's like Mr. Option says. But other times, the hallmark of a good programmer is precisely passing the buck.

Programming is, at heart, an engineering discipline. Good code can be used to do other things. And the only way to get code to do several things is to preserve modularity.

The philosophy of modular programming can be summed up as "what I don't know can't hurt me". If I'm writing code with someone, we need to fix an API. Then, all I do (and all they do) is program up to the API. And I don't care what happens on the other side of the API. It's not my business.

Of course it's not really like that. In practice, we can help each other, talk to see the interface between us is in the correct place, and look for other components we could abstract and share. (Sometimes the person on the other side of the API is me again!)

But to do my job right, I have to ignore all that. The moment I do stuff on my side of the API that has any relevance to what goes on on the other side of the API, I break modularity and produce lower-quality code. Good code performs up to the spec, but also not beyond it.


Passing the buck on bugs is, of course, a very different matter.

Log in or register to write something here or to contact authors.