Everyone’s Favorite Programmer

Saturday 22 November 2008 - Filed under Code

You know who I mean – the guy who contributes negatively to your project. Here’s some tips for being that guy, largely courtesy of our "favorite programmer’s" fine example (name suppressed to protect the guilty):

1. Replace another programmer’s succinct, working code with a ten-times-larger mess that doesn’t do the right thing. Bonus points for manually screwing up the endianness of numbers. More bonus points if you actually get that wrong too.
2. Insist on a broken locking version control system, such as SourceSafe. Host it on the slowest machine you can find, on a slow network. Since accessing the system is so horrendous, now keep critical files checked out on your own workstation indefinitely. Change shared code in those files sporadically, so everyone else’s code breaks whenever you *do* check in.
3. When building an application over an intricate custom communications protocol, insist on having the wire-level representations of all the packets you could possibly want. Ignore the existing library that handles every detail of the protocol. Be suitably incensed when the protocol changes to include a hard-to-read encoding, encryption, sequence numbers, and/or checksums.
4. Eschew the idea of helper functions to do straightforward things like memory copying, clearing, number-to-string conversions, etc. Manually inline messy code at each use. Bonus points for hand-unrolling the loops, too. When quizzed about why you’re not using itoa(), memcpy(), etc, feign ignorance, and then proceed to reformat the so-called "expert’"s code, ideally breaking it subtly in the process.
5. Attend one-day training seminars on "C Programming Best Practices," and then rigorously enforce everything you’ve been taught on the rest of the team. Nevermind they’ve been programming C for half their lives – you’ve been taught the way to do it!

2008-11-22  »  admin