This duck is clearly concerned about the quality of his work.

On Mediocrity

This is an updated copy of an email that I wrote after coming back from a couple of academic conferences that were both inspiring and profoundly depressing for exactly the same reasons. (I had a good idea of exactly what I had to do, and I had a good idea of exactly what I had to do...)

I was lucky enough to get lots of helpful replies from people who seemed to recognize the effect that I was talking about, and I have incorporated their comments here.

Incidentally, I thought the material here might be applicable to people in all fields that encourage perfectionism, but I'm told that a lot of this is quite domain specific. For example, in anything performance-based like music or sport, you can't really use the "diamond-like jewel" technique, since after practising yourself silly, you can still perform so badly that it makes you cringe for ever more. I suppose that software and science are actually quite forgiving fields in that respect.

As befits the sentiments here, this is just a draft until it somehow becomes less shit.

Occasionally one reads a paper that immediately makes coherent some idea that you'd never been able to articulate, or just quantifies something that you always suspected must be true. The example of this that I most often cite is the wonderful "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" It's definitely worth reading if you haven't already, although most people will recognize the effect from the title alone. A friend of mine who works in the civil service remarked that it is "among the most professionally relevant pieces of academic analysis I have seen in a long time." Otherwise inexplicable bits of behaviour in work environments suddenly become clear (and less irritating) when you realize that it's quite possible that a given person may have very little idea that they're incompetent.

The problem I've been thinking about recently, however, is really the converse of that: with a reasonable level of competence comes the ability to appreciate approximately how good or worthwhile a given bit of your work is, and if you think about this too much it can become a crippling impediment to:

(a) presenting it publically

(b) taking pleasure in your work

... or in serious cases:

(c) doing anything at all

I've mentioned this problem to many people I know, and I'm staggered at the huge proportion who have said that this more or less sums up their feelings about what they do. I'm worryingly close to concluding that the most important challenge in my working life is dealing with this feeling that everything I do is just mediocre. 6

If you don't recognize this feeling, then the rest of this is probably of no use to you. (There are any number of reasons that this might be true: e.g. you're genuinely exceptionally good, you're incompetent, you're competent but realistic and secure, you're having enough fun that you just don't care, etc. etc.)

So, in no particular order, here are some of my ideas about how to deal with this. I'm not trying to pretend that I've managed to follow my own advice here, incidentally. It's still a huge problem for me, but having thought about it a bit, these are the things I'm going to try to remember:

Learn to cope with positive feedback for mediocre work

This is quite tough. People fairly often tell me that a bit of work that I regard as mediocre (or just very slight) is great, and I find it profoundly depressing. Sometimes that's because I imagine that they have simply calibrated my capabilities according to some recent period of indolence, or sometimes it's because I worry that the whole world just has maladjusted standards. However, this is obviously nonsense. The world might well be broken, and you probably don't live up to your own standards, but if someone likes your work and compliments it then it's important to (a) be graceful about it (b) make an attempt to find out exactly what about your work the person finds particularly valuable - this is very surprising, and it can lead you in the direction of more quick hacks that people really like.

"Diamond-like jewels" 7

Every now and then you should pick some (ideally small) bits of work that you've done and very deliberately try to polish them until you can actually be proud of them. For these cases it really helps to get the input of other people. In the case of programming in particular, other people can help with writing things in a style that's better suited to the language you're using, spotting classes of security holes that you were unaware of, etc. Picking helpful people and talented people to talk to is not necessarily easy, of course.

I should do this more often, anyway.

Remember that the actual work involved in a given project isn't where we imagine it is

It's instructive to try to scrupulously document where all the time goes on a project, at some point. Conceptually trivial things can take a long, long time to get right. I'm not convinced, in fact, that this is really all that comforting, but it's worth bearing in mind when considering the difference between someone who's actually done something and someone who tells you that it would be easy to do. 8

Alistair adds: “I think this is a good point. Even if you actually are doing something remarkable, in order to do it you will have to spend a long time doing things that are merely competent. Although the remarkable thing is key, it will be pointless unless the rest is competent. In the majority of the work, therefore, absence of flaws beats presence of gems. If you can produce consistently mediocre work you are actually doing very well. See also the distinction between session musicians (who have high low-points) and stars (who have high high-points). I might be heading off down the wrong line here.”

Be very careful about taking on jobs where you're expected to be brilliant in some ill-defined sense

Maybe this is an unusual situation, but it's one that I've found myself in several times. There are few things more certain to make you feel that your work is worthless than doing what you think is good work, but being told that in some sense it's not impressive in the way that your manager is expecting. Beware of people who don't appreciate the value of solutions that are simple and elegant on the basis that they don't also use XML to cure cancer.

Do the simplest thing that could possibly work first

This is something of an "Extreme Programming" sentiment; it's much easier to make the simplest approach really good quality, and it's surprising how often that's good enough.

Not living up to your own standards

If you have the right kind of ambition, and you're above the "competence floor" suggested above then you're never going to live up to your own standards, and that's as it should be.

I've been told repeatedly, though, that one of the biggest problems that people have when doing a PhD is thinking that their thesis has to be a work of genius from beginning to end, which ends up being merely obstructive. So, it seems there's this balance you have to try to find between ambition (good) and being constantly unsatisfied and unhappy (bad).


At least use comments in your code to indicate that you know when something's useless. This is really helpful for people reading your code as well.

Pete added: “Related to this is 'document the deliberate failings in your work'. My page on the upside-down-ternet garned criticism [...] because of its horribly ineffecient implementation, it didn't cope with referrers correctly etc. etc. etc. However, had I done it to that level of perfection I'd probably never have been arsed. As it was the best part of two million people looked at it, and some thousands publically commented that they thought it was great.

Yes, the implementation sucked *but that didn't matter*.

I find now, that the first thing to do on embarking on any project is to write down the things that you aren't going to do, so that when you discover later that your work is crap because it doesn't do X, you can refer to your original notes and realise that not only did you not intend to to X, you explicity stated that you weren't going to do X, and not having done X is a success.

Don't be an arsehole about other people's work

Spotting mediocrity in other people's work is a pretty easy game, since everyone has similar pressures to those on yourself - not enough time, the pragmatic need to just get something working, etc. etc. 12

A sometimes difficult problem is when you spot a whole class of mediocrities of a similar type in someone's work, and you know that ultimately it will be valuable if you explain to them what they are. You need to be really sensitive to bring this to people's attention in a way that's helpful and doesn't make them feel crap. (Classic examples of this are writing code that uses the filesystem instead of an RDBMS, not being aware of SQL injection attacks and how to spot them, etc.)

It surprises me that among the genuinely brilliant people one occasionally meets there seems to be a sharp division between those who are utterly dismissive of everyone that they don't regard as being in their class, and those who are encouraging and generally behave like gentlemen. Perhaps the former category have never even experienced the mediocrity problem...

Literature surveys shouldn't stop you doing stuff

I'm incredibly bad at doing proper surveys of what has already been done in a given field. That's partly because I just like doing stuff, and when I do literature surveys the end result is mostly that I decide it's not worth doing the things I intended to do. The problem is that this conclusion is often premature, since (a) many methods suggested in the literature simply won't work as described when you implement them yourself and (b) the process of actually trying to implement them is *so* much more instructive than just reading a paper about them that it's worth doing anyway.

Presentation Issues

It's relatively easy to put to one side the fear of mediocrity when you're working in isolation, 11 but when you present your work to other people, either by publishing it on the web or presenting at a conference, you really have to face the limitations of your work. In these matters, I think the core principles are:

Never pretend...

... that your work does something it doesn't, or that it's more significant than you honestly believe it is.

Don't take other people's work at face value

When you compare what you're working on to similar systems then it's very easy to be discouraged. Firstly, would any impressive (pejoratively "flashy") presentational elements be easy for you to implement? They probably would. Secondly, under exactly what terms could you make use of the competing software? If it's commercial software, then someone will need to rewrite it anyway, as Richard Stallman would say. (I've written enough code that's now effectively useless due to licensing or contractual restrictions that I'm convinced that it's not worth writing non-free software any more. 10 No one in the intended audience of this piece is going to have a problem making enough money to live on even with this consideration, I imagine.)

Be *very* careful about where you present your work and how it will look alongside everything else there

I think that more or less speaks for itself. Even if you understand a comparison of your work and competing work, it's not clear that the audience will, even if you point this out as clearly as you can.

The other aspect of this is to be very careful about demonstrating software. In presentations (as opposed to demonstrations) you should always lean towards playing a video of using the software rather than trying to use it live. 9 Apart from the considerations of all the random effects that might ruin your demonstration, it's hard to talk coherently to an audience while interacting with software, particularly in the difficult conditions that tend to get imposed on you when you're giving public talks, like having to use your anatomy as a mousing surface.

General Considerations:

Pick things to do which you're going to have fun doing

If you're genuinely having fun, then who gives a shit if the end product isn't a diamond-like jewel? Dafydd mentioned that this reminded him of the well-presented advice here.

Working is scarily addictive, but less important than Other Things

If I'm inspired about what I'm working on and making progress writing code, there's almost nothing that I'll stop for - particularly not food or sleep. It's useful to have this trait in some respects, but you have to be very careful of it on two particular counts:

Other Comments

These are some of the other helpful comments people made in reply to my email - thank-you for all of these. (There are some that seemed to be either intended to be private, or were difficult to include, so if yours aren't here then that's not because I wasn't very glad to have them. :))

Dafydd also added:

I do identify with the feelings of mediocrity you mention. I think this especially common in software, because you're often working with people who are better than you. And as the link I posted says, this is a good idea, because it's a sure way to improve.

In addition to that, from time to time you hear of people who are doing mind-bendingly amazing things. Fabrice Bellard comes to mind, e.g.

For me, one thing that goes a long way to making up for these self-doubts is when I get a sense of genuine admiration from others I'm working with, especially if it's with regard to something I didn't think much of at the time I was doing it.

Pete also added:

I build lots of web applications. An important [realisation] is that I suck at design. Fortunately I've worked with a talented designer before and whilst it feels wrong the best thing I can do is to hand over all design to him. There was once an excellent car advert that summed it up - the character in the advert had taped over his wedding video with the clunking sounds of a car door shutting and tuning it to sound right. I, and most people I know would never reject a car on the basis that the door clunked in a badly tuned fashion. However, we might decide that the car is crap because of an unsatisfying clunk. Consequently I've realised that not only can I not do web design, but I can't articulate the faults in others design either. I just have a vague sense of crap and not crap, and I know I don't know how to get from one to the other.

It's still incredibly satisfying to have a project you've worked on made beautiful by someone else though. You really want to get help from people with complementary skills to yourself since they'll fix the things you don't really care about or don't notice, and at the end you'll come out with something much better than you'll have managed yourself.

Alistair also added:

I often find myself telling somebody about something that I've done in a rather shy, apologetic style because I know that they do things every day that I would find extremely difficult, only to find them treating me in exactly the same way. I think people have a tendency to undervalue the things they find easy.

Reuben added:

Two other strategies for bolstering one's ego (not necessarily the thing you're trying to do directly, but I find it's a handy hack):

  1. USP: if you have your own unique selling point, you can avoid despondency by being incommensurable with others.
  2. The Leonard Bernstein Method: arguably a variant on USP, Bernstein used to say that among conductors he said he was a composer and among composers he said he was a conductor.

The latter of these is something that's very easy to do for people in cross-disciplinary fields, such as all of those funded by the PhD programme that I'm on. I tend to regard these as quite cheap points, but people tell me that this is undervaluing the contribution of applying techniques from one field to another. (The Edinburgh Neuroinformatics DTC is wonderful, incidentally, and I don't plug it enough...)

Matthijs commented:

[...] and somewhere I'm beginning to suspect that it may be that this issue really only comes up when you're not doing something you enjoy doing (such that satisfaction has to come from indirect sources, such as feedback from people). Now that doesn't mean it's any less important or that it's not worth exploring ways of dealing with it... I guess I'm just looking for this kind of problem to have a place in the greater scheme of things. Who cares if I'm mediocre? In what kind of framework/under what assumptions does this actually become an issue?

That's a good point, but I don't think I have any good ideas about the more general problem. If I do, I'll probably rewrite this so that it's less fragmented and better written. ;)

Digressive footnotes below:

1 A nice example of a social pattern that's often suggestive of incompetence is when you see people pick up technical jargon from context in conversation and immediately reuse it in situations where their lack of understanding of the terms will be completely apparent. I've sat in meetings where non-technical bosses have repeatedly done this, without apparently realizing that by doing so they will appear as a charlatan to everyone else in the room. 2 3

Of course, the urge to pretend to know more than you actually do in any situation is horribly, horribly tempting, but fortunately most competent people have this largely beaten out of them by the time they're adults by a succession of public embarrassments - more often than not this comes up when you try to give a public talk on material you don't properly understand. It's impossible not to cringe when looking back on these occasions, but I think you have to acknowledge that overall they improve your life by sharpening up your intellectual honesty.

The misuse of terms most frequently comes up when people are trying to sell something to another party, which is knuckle-chewingly frustrating if you have an accurate picture of what the system in question does and believe it will stand up on its own merits. The misleading hyperbole employed by people with the sales mentality never sells anything to anyone competent, and I wish they'd just fucking stop it.

2 This rapid absorption and recycling of language is beautifully done in the The Big Lebowski where the vocabulary used by the Dude (and Walter) is densely packed with expressions they picked up earlier in the film.

3 Email me for a wonderful example of this in action, which I can't really distribute here. On the same topic, I like the imaginary "Modern Jackass" magazine suggested by This American Life in A Little Bit of Knowledge.

4 The Dilbert Principle has a surprisingly good analysis of these effects, IIRC.

6 Something I'm not going to talk about here is the problem that most people have a body of work that they did when they were much younger and less competent; reading back through your old email or writing from 10 years ago is similarly very dificult to cope with.

7 If you don't know this expression, it's from Lisp: Good News, Bad News, How To Win Big.

8 This is one of my favourite Social Patterns in software engineering, in fact. I used to have a boss who would ask you (the person who was going to do a bit of work) how long you thought it would take. Then he would go around asking other people (who certainly wouldn't be doing that bit of work) how long it would take. Naturally they would estimate unrealistically short amounts of time, since they get to look good for no cost by doing that. The classic trap, of course, is to then promise to do the work in an unrealistic amount of time so you get that instant "great, so we can use it tomorrow!" reponse and self-esteem kick, as well as avoiding looking crap compared to your co-workers. My assumption is that you actually look and feel better by meeting a realistic deadline, but I fear that may actually be untrue unless your manager or client is exceptionally good...

9 Programs like istanbul or the various VNC recorders are useful for this. It's nonetheless incredibly frustrating trying to get screencasts right. If you have lots of disk space available, my favoured method is to record to raw video and encode later so that you don't take away CPU from the demo itself. So, in a 16 bit colour 1024x768 screen mode, do something like this:

   # Record the raw video:

   ffmpeg -vcodec rawvideo -f x11grab -s 1024x768 -r 10 -i :0.0 test.yuv

   # Encode the recorded video using settings suggested in the
   # ffmpeg FAQ:

   ffmpeg -pix_fmt rgb565 -s 1024x768 -r 10 -vcodec mpeg4 -mbd rd -flags +4mv+trell+aic -cmp 2 -subcmp 2 -g 300 -pass 1/2 -i test.yuv -r 10 test.avi

A few caveats: you may need to recompile ffmpeg to include x11grab; you might want to use different codecs so that it plays easily on Windows and you might need to fiddle with the pixel format options.

10 There are a number of bits of software on my web page where source code isn't available; this is mostly because I wrote them some time ago with a dependency on some non-free component, and I haven't had time to go back and rewrite those bits. :(

11 Interestingly, a couple of people have told me that they find the exact opposite to be true.

12 The weblog "Worse Than Failure" (which used to be "The Daily WTF") is devoted to finding examples of bad code and publicizing them. The examples they find are generally very bad (except for the occasional time when they, for example, don't recognize standard C idioms), but the tenor of comments on each post is just awful, as well as frequently misinformed. I'm not sure if they are worse than YouTube comments, for example, but they're more disappointing to me.