Meta-Metaphors

Today’s XKCD reminded me of an idea I thought of the other day. I’m sure most of my readers have encountered triangles before. X, Y, Z: pick two. Probably the best known is good/fast/cheap, but there’s the CAP Theorem, Zooko’s Triangle, even a few I’ve devised. So here’s my meta-triangle, of properties a triangle itself (especially in the customary equilateral presentation) might have.

  • Easy to understand.
  • Useful or insightful.
  • Accurately reflects reality.

Pick two. In particular, pick which two properties that triangle itself has, and which one it lacks. Ouch, now my brain hurts.

How To Ruin a Project

This is a bit of a riff on Jerry Weinberg’s ten commandments of egoless programming (via the also-excellent Jeff Atwood). I’ve found that many engineers, perhaps even a majority, respond more to aversion than to encouragement, so a “how not to” that can be inverted in one’s head sometimes works better than a “how to” taken straight. So here are the ways to turn a promising and fun project into a soul-sucking wreck. Take it from an expert.

  • Miss the point. Never try to figure out what the project’s really about, or what it will be used for. Add features that have nothing to do with any valid use, removing or breaking other essential features in the process. Develop and test on a totally inappropriate platform. Confuse scalability with performance, or test the wrong kind of performance and then complain about the results.
  • Claim authority you haven’t earned. Assume that your reputation or barely-relevant experience entitles you to sit at the head of the table before you’ve made any significant contribution. Push aside those who started the project, who have contributed/invested more, or are more affected by its outcome.
  • Focus on the trivial. Spend all of your time – and everyone else’s – on issues like coding style, source-control processes, and mailing-list etiquette. Carefully avoid any task that involves a more than superficial knowledge of the code. Make others do the heavy lifting, then take half credit because you added some final polish.
  • Be self-important. Make sure everyone knows this is the least important of your many projects. Insist that every work flow and library choice conform with your habits on those other projects so that your life will be easier, even (especially) if it’s to the detriment of those doing more work.
  • Be dismissive. Clearly, your specialty is the one requiring the greatest technical prowess. If you’re a kernel/C programmer, look down your nose at web/Ruby punks. If you’re a web/Ruby programmer, look down your nose at enterprise/Java drones. If you’re an enterprise/Java programmer, look down your nose at kernel/C neanderthals. If you’re the world’s greatest maintenance programmer, specializing in minor tweaks to twenty-year-old programs representing many person-years of prior work , criticize the “immaturity” of new code that does new things. Above all, treat the specialty most crucial to your project as the exclusive domain of novices and children, with you as the “adult supervision” to bring it up to snuff in the areas that experts really care about.
  • Argue from authority, not facts. If anybody provides empirical evidence to support their choice of a technique, algorithm, or style choice, ignore or reject it. Never provide any such evidence to support your own choices. Make sure everyone knows that your own personal experience trumps any such evidence, even if that experience is less (or less relevant) than others’.
  • Lecture. Use every interaction as an opportunity to “educate” others about the reasons (rationalizations) for your personal preferences. Bonus points if you deliver a lecture on a subject that the recipient actually knows better than you, without ever pausing to determine whether that’s the case.
  • Be persistent. If any decision ever goes against you, resist it forever. Treat every bug from then on, no matter how unrelated or trivial, as an excuse to beat the dead horse some more. If you’re at a company, use company time to pursue your approach instead of the approved one, and drag colleagues with you. If you’re working on open source, threaten to leave/fork.
  • Be a hypocrite. Take some valid principle – portability, scalability, loose coupling – and use it to demand invasive change from others, then make your own changes that violate the same principle. Demand code reviews for every checkin, aggressively review others’ patches, then check in your own changes unilaterally. Bonus points if your unilateral changes were clearly never tested and cause grievous breakage.
  • Be the martyr. After all doing all of these other things, your colleagues might not be keen to work with you again. Make sure everyone knows you were just trying to help, that you tried ever so hard to make them better engineers, and that the lack of gratitude reflects on them instead of you.

Many thanks to the people I’ve worked with who have inspired this. Without you, the list would be much less comprehensive. I hope its inverse will help others participate in projects that are more successful and fulfilling for all involved as a result.