Everyone always wants to say worthy things about the qualities that make a good programmer. But I occasionally think that "a sense of humour" isn't given enough credit.

In programming, you're constantly making mistakes, and being told you're wrong (by code reviewers, bug reporters, and the computer itself). If you let that get you down, you'll quickly find another career.

When I realise I've made a mistake, my reaction is often to find it amusing – smile a bit, maybe laugh out loud, share it with a friend if it's funny enough.

I can't remember how I got that attitude in the first place. Perhaps just luck. But I sometimes think it's the main reason I stuck with what would otherwise be a frustrating profession!

@simontatham The ability to turn mistakes into funny comments is a bonus, too!
@simontatham I think IT in general is a profession that tends to attract masochistic characters that like/need to be frustrated.

@steckschwein_6502 you could see it that way, but I honestly don't experience the feeling I mean as frustration. It is actual _amusement_, like when you get a joke. The combination of understanding why something seemed sensible to me at the time, and also why it's totally wrong, often has (for me) that same contrast and unexpectedness that makes jokes funny.

I do feel frustration (of course), but more often when I'm failing to come up with a good idea at all, rather than when I do something and it doesn't work.

@simontatham I understand what you mean. It's fun to finally catch that bug. I think there lies a lot of frustration in the underappreciation of the IT profession. Like when your work only becomes visible when something breaks. And then you are viewed as the culprit, not the bug solving hero. That's when humour comes in handy.
@steckschwein_6502 @simontatham "The most common language used in programming is profanity." - unknown
@simontatham I find it's a really useful habit, or talent perhaps, in playing games too. In person or on computers. If something goes absolutely disastrously horribly wrong I'm almost guaranteed to find it hilariously funny.

@lnr when I was at school, we had a guy come to give us a talk, and he started by saying "I'm going to teach you how to juggle". In fact he discussed the mechanics of juggling not at all – what he taught was a technique for transforming frustration into amusement during the initial phase of learning when you're doing nothing but drop the balls and pick them up again, on the theory that that's why most people give up before succeeding.

His suggestion was: every time you drop a ball, tell yourself a joke, and bend down to pick the ball up just as you get to the punchline, so that you learn to associate picking up balls from the floor with amusement.

(And then he went on from that starting point to apply the same ideas to exam revision, which was the main point of his talk.)

Sadly, I'd already learned to juggle when I heard this talk, so I couldn't test whether the idea worked!

@simontatham @lnr I remember one juggling teacher who started with "throw the ball up in the air and let it fall to the ground on purpose, several times. That way you won't always associate it with failure when it happens by mistake, which it will a lot."
@diffrentcolours @lnr I think the well-known 'Klutz' guide gives similar advice, but if I remember rightly, their rationale is different: you're going to be doing this a lot, so better get in some practice :-)
@[email protected] My most recent bug fix was some spurious dollar signs in a Python regex matching a time/date when parsing a log file. I remarked that I must have been doing too many shell scripts at the same time I wrote that code and a colleague made a quip along the lines of "time is money".

@simontatham And the best way to think about your code is that it's disposable, but your skills are not.

Hence, in a code review worry about learning what you can improve, not your precious words laid end to end.

@simontatham @genehack Pretty sure I've told this story here before, but I was once responsible for a team that managed daily log file analysis. For various reasons sometimes some of the necessary log files might be missing when the scheduled job ran, so I built a tool admins could use to rerun the daily analysis after trying to fetch the missing logs. In certain circumstances that tool could restart itself, leading to a subtle bug related to an open filehandle.

I (eventually) found and fixed the bug, and added a Bart Simpson style comment below the bug fix:

#I will always close my filehandles.
#I will always close my filehandles.
#I will always ...

Months after I left that job, I got a text from somebody still at the company, containing just that code comment. He'd gotten a big laugh out of it.
@fedward @genehack I actually hadn't predicted that this toot would cause people to share their funniest bugs/fixes, but I'm completely happy with that unforeseen consequence :-)

@fedward @simontatham I have a friend and former coworker who is currently maintaining a stack of bioinformatics/sequence analysis stuff originally developed by ...let's be kind and say, "non-coders", that I completely rewrote during a period of pretty high stress, and he periodically toots out comments that I left behind. It's amusing.

(As a sample, the first line of the project's README.md was "Lasciate ogne speranza, voi ch'intrate"...)

@genehack @fedward I suspect that's a fairly common opening line of terrifying comments, along with variations on 'here be dragons'!

One of my favourite comments I ever wrote occurred when I found an incomprehensible source file, spent an afternoon making sense of it, and since there wasn't an explanation already, wrote up what I'd found in a big comment at the top, with the opening paragraph

"This module is totally incomprehensible without hours of drawing small diagrams and swearing, so I'm going to write a comment for the benefit of the next poor sucker."

The reason I liked this so much was that, ten years later, it turned out that the next poor sucker was Future Me, who was very grateful to Past Me!

@simontatham Good programmers are able to continually improve their software by writing self-deprecating code.
@simontatham you may also have a history of jobs where you could feel safe generally. The first thing we all need is to normalize mistakes and feel like they're ok and part of learning. Laughing at what we've done can't happen when we're afraid for our jobs. Glad you're in a tolerably healthy place, however you got there tho!

@ren totally agree – a workplace that puts you under constant pressure to never make a mistake is utterly toxic. _Especially_ if you feel under that pressure from day 1 when you're still learning your way around, because it's even more obvious that people will make mistakes while learning than that they'll carry on making mistakes once they're up to speed (though both are true).

Not only that, but a workplace of that kind isn't even serving its _own_ interests, because if it's trying to incentivise employees to never make a mistake, what it's really doing is incentivising them to never _look_ as if they make a mistake. So the mistakes get covered up and the company never finds out about all the problems.

@simontatham @rationaldoge

There are very few professions where the day you start a new project, you know you’re going to fail 1,000 times. It’s psychologically taxing.

You have to get the rush from success. Otherwise you’ll never make it in technology.