Tag: humour

What’s your website’s D&D alignment?

This is the impression – often the first impression – that users of the website get of the organisation.

Cookies and Dungeons and Dragons – a hypothesis

Recent privacy legislation has led organisations to have to adopt ways of allowing their users to register their cookie preference in ways which expose the underlying motivations of the org. I have a related theory, and it goes like this: these different registration options allow you to map organisations to one of the 9 Dungeons and Dragons character alignments.

This may seem like a bit of a leap, but stick with me. First, here’s a a little bit of background for those readers who’ve never dabbled in (or got addicted to -there’s little room between the two extremes) the world of Dungeons and Dragons (or “D&D”). There are two axes used to describe a character: Lawful-Neutral-Chaotic and Good-Neutral-Evil. Each character has a position across each of these axes, so you could have someone who’s Lawful-Good, one who’s Chaotic Neutral or one who’s Neutral-Good, for instance (a “Neutral-Neutral” character is described as “True Neutral”). A Lawful character follows the law – or a strong moral code, whereas a Chaotic one just can’t be bothered. A Neutral character tends to do so when it suits them. The Good-Neutral-Evil axis should be pretty clear.

Second bit of background: I never just accept cookies on a website. I always go through the preferences registration options, and almost always remove permissions for all cookie tracking beyond the “minimum required for functionality”. I know I’m in a tiny minority in this, but I like to pretend that I can safeguard at least some of my private data, so I do it anyway (and so should you). I’ve noticed, over the past few months, that there are a variety of ways that cookie choices are presented to you, and I reckon that we can map several of these to these D&D alignments, giving us a chance to get a glimpse into the underlying motivation of the organisation whose website we’re visiting.

I’ve attempted to map the basic approaches I’ve seen into this table.

Lawful GoodNeutral GoodChaotic Good
Functional cookies only by default.No cookies, and a link to a long and confusing explanation about how the organisation doesn’t believe in them.No cookies at all, no explanation.
Lawful NeutralTrue Neutral Chaotic Neutral
Functional and tracking cookies by default, clear what tracking cookies are; all easy to turn off.Functional and tracking cookies by default, completely unclear what the cookies do.Random selection of cookies, and it’s unclear what they do, but you can at least turn them off.
Lawful EvilNeutral EvilChaotic Evil
All cookies by default: functional, tracking and legitimate uses.  Easy to remove with “reject all” or “object all”.All cookies by default.  “Legitimate uses” need to be deselected individually.All cookies by default, with 100s listed.  You have to deselect them by hand (there’s no “reject all” or “object all”), and there’s a 2 to 5 minute process to complete the registration, which finishes on 100% but never completes.
D&D alignments and website cookie preference approaches

Clearly, this is a tongue-in-cheek post, but there’s an important point here, I think: even if this glimpse isn’t a true representation of the organisation, it’s the impression – often the first impression – that users of the website get. My view of an organisation is formed partly through my interaction with its website, and while design, layout and content are all important, of course, the view that is presented about how much (if at all) the organisation cares about my experience, my data and my privacy should be something that organisations really care about. If they don’t respect me, then why should I respect them?

If I’m trying to attract someone to work for me, partner with me or buy from me, then my marketing department should be aware of the impression that visitors to my website glean from all interactions. At the moment, this seems to be missing, and while it’s not difficult to address, it seems to have escaped the notice of most organisations up to this point.

The 9 development stages for software (and kids)

We can draw parallels in the stages through which software projects and children tend to progress.

This week, one of my kids turned 18, and is therefore an adult – at least in the eyes of law in the UK, where we live. This is scary. For me, and probably for the rest of the UK.

It also got me thinking about how there are similarities between the development lifecycle for software and kids, and that we can probably draw some parallels in the stages through which they tend to progress. Here are the ones that occurred to me.

1. Creation

Creating a new software project is very easy, and a relatively quick process, though sometimes you have a huge number of false starts and things don’t go as planned. The same, it turns out, applies when creating children. Another similarity is that many software projects are created by people who don’t really know what they’re doing, and shouldn’t be allowed anywhere near the process at all. Equally useless at the process are people who have only a theoretical understanding of how it should work, having studied it at school, college or university, but who feel that they are perfectly qualified.

The people who are best qualified – those who have done it before – are either rather blasé about it and go about creating new ones all over the place, or are so damaged by it all that they swear they’ll never do it again. Beware: there are also numerous incidents of people starting software processes at very young ages, or when they had no intention of doing so.

2. Naming

Naming a software project – or a baby – is an important step, as it’s notoriously difficult to change once you’ve assigned a name. While there’s always a temptation to create a “clever” or “funny” name for your project, or come up with an alternative spelling of a well-known word, you creation will suffer if you allow yourself to be so tempted. Use of non-ASCII characters will either be considered silly, or, for non-Anglophone names, lead to complications when your project (or child) is exposed to other cultures.

3. Ownership

When you create a software project, you need to be careful that your employer (or educational establishment) doesn’t lay claim to it. This is rarely a problem for human progeny (if it is, you really need to check your employment contract), but issues can arise when two contributors are involved and wish to go their separate ways, or if other contributors – e.g. mothers-in-law – feel that their input should have more recognition, and expect more of their commits to be merged into main.

4. Language choice

The choice of language may be constrained by the main contributors’ expertise, but support for multiple languages can be very beneficial to a project or child. Be aware that confusion can occur, particularly at early stages, and it is generally worthwhile trying to avoid contributors attempting to use languages in which they are not fluent.

5. Documentation

While it is always worthwhile being aware of the available documentation, there are many self-proclaimed “experts” out there, and much conflicting advice. Some classic texts, e.g. The C Programming Language by Brian Kernighan and Dennis Ritchie or Baby and Child Care by Dr Benjamin Spock, are generally considered outdated in some circles, while yet others may lead to theological arguments. Some older non-core contributors (see, for example, “mothers-in-law”, above), may have particular attachments to approaches which are not considered “safe” in modern software or child development.

6. Maintenance

While the initial creation step is generally considered the most enjoyable in both software and child development processes, the vast majority of the development lifecycle revolves around maintenance. Keeping your project or child secure, resilient and operational or enabling them to scale outside the confines of the originally expected environment, where they come into contact with other projects, can quickly become a full-time job. Many contributors, at this point, will consider outside help to manage these complexities.

7. Scope creep

Software projects don’t always go in the direction you intend (or would like), discovering a mind of their own as they come into contact with external forces and interacting in contexts which are not considered appropriate by the original creators. Once a project reaches this stage, however, there is little that can be done, and community popularity – considered by most contributors as a positive attribute at earlier stages of lifecycle – can lead to some unexpected and possibly negative impacts on the focus of the project as competing interests vie to influence the project’s direction. Careful management of resources (see below) is the traditionally approach to dealing with this issue, but can backfire (withdrawal of privileges can have unexpected side effects in both software and human contexts).

8. Resource management

Any software project always expands to available resources. The same goes for children. In both cases, in fact, there will always appear to be insufficient resources to meet the “needs” of the project/child. Be strong. Don’t give in. Consider your other projects and how they could flourish if provided with sufficient resources. Not to mention your relationships with other contributors. And your own health/sanity.

9. Hand-over

At some point, it becomes time to hand over your project. Whether this is to new lead maintainer (or multiple maintainers – we should be open-minded), to an academic, government or commercial institution, letting go can be difficult. But you have to let go. Software projects – and children – can rarely grow and fulfil their potential under the control of the initial creators. When you do manage to let go, it can be a liberating experience for you and your creation. Just don’t expect that you’ll be entirely free of them: for some reason, as the initial creator, you may well be expected to arrange continued resources well past the time you were expecting. Be generous, and enjoy the nostalgia, but you’re not in charge, so don’t expect the resources to be applied as you might prefer.

Conclusion

I’m aware that there are times when children – and even software projects – can actually cause pain and hurt, and I don’t want to minimise the negative impact that the inability to have children, their illness, injury or loss can have on individuals and families. Please accept this light-hearted offering in the spirit it is meant, and if you are negatively affected by this article, please consider accessing help and external support.

8 tips to rekindle Linux nostalgia (and pain)

Give us back our uber-geek status: make Linux hard again.

I bought a new machine the other day, and decided to put Fedora 35 on it. I’ve been a Fedora user since joining Red Hat in August 2016, and decided to continue using it when I left to (co-)found Profian in mid 2021, having gone through several Linux distros over the years (Red Hat Enterprise Linux before it was called that, Slackware, Debian, SuSE, Ubuntu, and probably some more I tried for a while and never adopted). As a side note, I like Fedora: it gives a good balance of stability, newish packages and the ability to mess at lower levels if you feel like it, and the move to Gnome Shell extensions to deliver UI widgets is an easy way to deliver more functionality on the desktop.

Anyway, the point of this article is that installing Linux on my most recent machines has become easy. Far too easy. When I started using Linux in around 1997, it was hard. Properly hard. You had to know what hardware might work, what things you might do which could completely brick your machine what was going on, have detailed understanding of obscure kernel flags, and generally have to do everything yourself. There was a cachet to using Linux, because only very skilled[1] experts could build a Linux machine and run it successfully as their main desktop. Servers weren’t too difficult, but desktops? They required someone special[2].

I yearn for those days, and I’m sure that many of my readers do, too. What I thought I’d do in the rest of this article is to suggest ways that Linux distributions could allow those of us who enjoy pain and to recapture the feeling of “specialness” which used to come with running Linux desktops. Much of the work they will need to do is to remove options from installers. Installers these days take away all of the fun. They’re graphical, guide you through various (sensible) options and just get on with things. I mean: what’s the point? Distributions: please rework the installers, and much of the joy will come back into my Linux distribution life.

1. Keyboards

I don’t want the installer to guess what keyboard I’m using, and, from there, also make intelligent suggestions about what the default language of the system should be. I’d much prefer an obscure list of keyboards, listing the number of keys (which I’ll have to count several times to be sure), layouts and types. Preferably by manufacturer, and preferably listing several which haven’t been available for retail sale for at least 15 years. As an added bonus, I want to have to plug my keyboard into a special dongle so that it will fit into the back of the motherboard, which will have several colour-coded plastic ports which disappear into the case if you push them too hard. USB? It’s for wimps.

2. Networking

Networking: where do I start? To begin with, if we’re going to have wifi support, I want to set it up by hand, because the card I’ve managed to find is so obscure that it’s not listed anywhere online, and the Access Point to which I’m connecting doesn’t actually support any standard protocol versions. Alternatively, it does, but the specific protocol it supports is so bleeding edge that I need to download a new firmware version to the card. This should be packaged for Windows (CE or ME, preferably), and only work if I disable all of the new features that the AP has introduced.

I’d frankly much prefer Ethernet only support. And to have to track down the actual chipset of the (off-board) network card in order to find the right drivers.

In fact, best of all would be to have to configure a modem. I used to love modems. The noises they made. The lights they flashed. The configuration options they provided.

Token ring enthusiasts are on their own.

3. Monitors

Monitors were interesting. It wasn’t usually too hard to get one working without X (that’s the windowing system we used to use – well, was it a windowing system? And why was the display the Xserver, and the well, server the Xclient? Nobody ever really knew), but get X working? That was difficult and scary. Difficult because there was a set of three different variables you had to work with for at least three different components: X resolution, Y resolution and refresh rate, each with different levels of support by your monitor, your graphics card and your machine (which had to be powerful enough actually to drive the graphics card). Scary because there were frequent warnings that if you chose an unsupported mode, you could permanently damage your monitor

Now, I should be clear that I never managed to damage a monitor by choosing an unsupported mode, and have never, to my knowledge, met anyone else who did, either, but the people who wrote the (generally impenetrable) documentation for configuring your XServer (or was it XClient…?) had put in some very explicit and concerning warnings which meant that every time you changed the smallest setting in your config file, you crossed your fingers as you moved from terminal to GUI.

Oh – for extra fun, you needed to configure your mouse in the same config file, and that never worked properly either. We should go back to that, too.

4. Disks

Ah, disks. These days, you buy a disk, you put it into your machine, and it works. In fact, it may not actually be a physical disk: it’s as likely to be a Solid State Device, with no moving parts at all. What a con. Back in the day, disks didn’t just work, and, like networking, seemed to be full of clever “new” features that the manufacturers used to con us into buying them, but which wouldn’t be supported by Linux for at least 7 months, and which were therefore completely irrelevant to us. Sometimes, if I recall correctly, a manufacturer would release a new disk which would be found to work with Linux, only for latter iterations of the same model to cease working because they used subtly different components.

5. Filesystems

Once you’d got a disk spinning up (and yes, I mean that literally), you then needed to put a filesystem on it. There were a variety of these supported, most of which were irrelevant to all but a couple of dozen enthusiasts running 20 year old DEC or IBM mini-computers. And how were you supposed to choose which filesystem type to use? What about journalling? Did you need it? What did it do? Did you want to be able to read the filesystem from Windows? Write it from Windows? Boot Windows from it? What about Mac? Did you plan to mount it remotely over a network? Which type of network? Was it SCSI? (Of course it wasn’t SCSI, unless you’d managed to blag an old drive enclosure + card from your employer, who was throwing out an old 640Kb drive which was already, frankly on its last legs).

Assuming you’d got all that sorted out, you needed to work out how to partition it. Anyone who was anyone managed to create too small a swap partition to allow your machine to run without falling over regularly, or managed to initialise so small a boot partition that you were unable to update your kernel when the next one came out. Do you need a separate home partition? What about /usr/lib? /usr/src? /opt? /var? All those decisions. So much complexity. Fantastic. And then you have to decide if you’re going to encrypt it. And at what level. There’s a whole other article right there.

6. Email

Assuming that you’ve got X up and running,that your keyboard types the right characters (most of the time), that your mouse can move at least to each edge of the screen, and that the desktop is appearing with the top at the top of the screen, rather than the bottom, or even the right or left, you’re probably ready to try doing something useful with your machine. Assuming also that you’ve managed to set up networking, then one task you might try is email.

First, you’ll need an email provider. There is no Google, not Hotmail. You’ll probably get email from your ISP, and if you’re lucky, they sent you printed instructions for setting up email at the same time they sent you details for the modem settings. You’d think that these could be applied directly to your email client, but they’re actually intended for Windows or Mac users, and your Linux mail client (Pine or Mutt if you’re hardcore, emacs if you’re frankly insane) will need completely different information set up[3]. What ports? IMAP or POP? Is it POP3? What type of autehntication? If you’re feelnig really brave, you might set up your own sendmail instance. Now, that’s real pain.

7. Gaming

Who does gaming on Linux? I mean, apart from Doom and Quake 3D Arena, all you really need is TuxRacer and a poorly configured wine installation which just about runs Minesweeper. Let’s get rid of all the other stuff. Steam? Machines should be steam-powered, not running games via Steam. Huh. *me tuts*

8. Kernels

Linux distros have always had a difficult line to tread: they want to support as many machine configurations as possible. This makes for a large, potentially slow default kernel. Newer distributions tune this automatically, to make a nice, slimline version which suits your particular set-up. This approach is heresy.

The way it should work is that you download the latest kernel source (over your 56k6 modem – this didn’t take as long as you might think, as the source was much smaller: only 45 minutes or so, assuming nobody tried to make a phone call on the line during the download process), read the latest change log in the hopes that the new piece of kit you’d purchased for your machine was now at least in experimental release state, find patches from a random website when you discovered it wasn’t, apply the patches, edit your config file by hand, cutting down the options to a bare minimum, run menuconfig (I know, I know: this isn’t as hardcore as it might be, but it’s probably already 11pm by now, and you’ve been at this since 6pm), deal with clashes and missing pieces, start compiling a kernel, go to get some food, come back, compress the kernel, save it to /boot (assuming you made the partition large enough – see above), reboot, and then swear when you get a kernel panic.

That’s the way it should be. I mean, I still compile my own kernels from time to time, but the joy’s gone from it. I don’t need to, and taking the time to strip it down to essentials takes so long it’s hardly worth it, particularly when I can compile it in what seems like milliseconds.

The good news

There is good news. Some things still don’t work easily on Linux. Some games manufacturers don’t bother with us (and Steam can’t run every game (yet?)). Fingerprint readers seem particularly resistant to Linuxification. And video-conferencing still fails to work properly on a number of platforms (I’m looking at you, Teams, and you, Zoom, at least where sharing is concerned).

Getting audio to work for high-end set-ups seems complex, too, but I’m led to believe that this is no different on Windows systems. Macs are so over-engineered that you can probably run a full professional recording studio without having to install any new software, but they don’t count.

Hopefully, someone will read this article and take pity on those of us who took pride in the pain we inflicted on ourselves. Give us back our uber-geek status: make Linux hard again.

1 – my wife prefers the words “sad”, “tragic” and “obsessed”.

2 – this is a a word which my wife does apply to me, but possibly with a different usage to the one I’m employing.

3 – I should be honest: I still enjoy setting these up by hand, mainly because I can.

7 tips for how not to design a self-driving car

Consider how a self-driving car should behave if you want it to seem like a(n inexperienced) human driver

About a month ago, one of my children started learning to drive. Much to our (mutual) surprise, it turns out that I’m the favoured parent to be sitting in the passenger seat, which means that I’ve spent quite a few hours watching a (human) driver learning how to operate a car safely. Most of the time, at least.

As a result, I consider myself an expert in general stuff about driving, automotive safety and the rest, and I’ve decided that this extends to the subject of self-driving cars. I’m not such an expert that I feel qualified to tell you how to you should design such a car, but I do feel that I can give some pretty useful pointers as to what not to do, along the lines of such august previous articles as:

What we’re looking to do here is consider how a self-driving car should behave if you want it to seem like a(n inexperienced) human driver. Here are some tips.

1. Teach it to stall

This is a key part of learning to drive in the UK, where most drivers (until recently, at least) have learned on cars with manual (that is “non-automatic”) gearboxes. As a result, learning to stall at inopportune moments is a key skill that the self-driving car needs to master. Alongside this is the ability to judder and “bunny hop” when trying to move off having recovered from the stall. Key places to do so are junctions, roundabouts, and traffic lights. If you can get your automatic gearbox-equipped vehicle to stall, you get extra points: impressive.

2. One thing at a time

Single-threaded programming is much, much simpler than multi-threading. This is a stroke of luck, because new drivers can only concentrate on one thing at a time. They can steer, change gear watch your speed (more on this below), observe roadsigns or avoid other road-users, but you shouldn’t expect them to do all at one time. The same should go for the vehicle that you’re designing. Use a random number generator to decide which one of these to prioritise, and then ignore the others until you’re done

3. Full beam all the way

When you’re driving in the dark, you need to be able to see what you’re doing. The best way to do this is to ensure that your headlights are on full beam. All of the time. Some self-driving cars don’t rely on visible light to negotiate the road, but headlights are also important for letting other road-users know you’re there. And the best way to do this is not only to put them on full beam when you set off, but also not to dip them when other vehicles approach. That way, everyone will know you’re there. They may not be happy, but they’ll know you’re there.

4. (Very) Slow is good

Exactly how fast you go shouldn’t be easily guessable – that would make life too simple for other road-users. It’s important to have some sort of algorithm for this, so let me suggest one: 

speed = limit/5 * rand (limit/2)

This is a good start, but there are times when you want to add extra surprise: at random intervals, the car should accelerate to about 10% over the speed limit. For added realism, you should be careful to avoid this happening at obvious times such as at the beginning or end of a reduced speed limit – somewhere in the middle is perfect.

5. Fear birds

We live in a rural village, which means that there are lots of birds sitting in the middle of the road most of the time. Favourites are pheasants, partridges, magpies and wood pigeons. Nobody wants feathers (and worse) in their front grill, so it’s important to avoid them. The best way to do this is to make sure that you don’t get too close to them, but this is difficult if they’re everywhere. Fear them. Slow down wherever you can, and not just where you see birds, but where you suspect there might be some – but make sure that other road-users don’t have too much notice. For this, see our next point below.

6. Manoeuvre, signal, mirror (or something like that)

New drivers are taught that there are three important things you need to do every time you do anything like turn off the road, come to a stop or avoid a obstruction (such as birds – see above). These should allegedly be done in a particular order, but real human learner drivers don’t stick to this order, so it’s important to bring a little randomness into the equation. Obviously, self-driving cars don’t need to use mirrors, so in lieu of this, add a little swerve here or there – which is something that learner drivers do when they use their mirrors, so should serve instead.

7. Have a “tutting” passenger

One of the key parts of getting used to driving, as any learner will tell you, is having a passenger next to you, making disapproving noises at (for you) unexpected moments. You’ll need to ensure that there’s some mechanism in the self-driving vehicle to deliver such sound effects. For added realism, you can add panicked cries of “slow, slower, SLOWER, STOP, STOP NOW!” Followed by “Right. We were very lucky there. Get out of the driver’s seat: I’m taking over.” Once you get there, you know that you’ve really succeeded.

  1. I should point out that to make any extrapolations from this article to the actual driving of the child mentioned above would be grossly unfair.

Title image by Colin on Flickr.

5 signs that you may be a Rust programmer

I’m an enthusiastic evangelist. I’m also not a very good Rustacean.

I’m a fairly recent convert to Rust, which I started to learn around the end of April 2020 (when we assumed there would only be the one lockdown, and that Covid-19 would be “over by Christmas” – oh, the youthful folly). But, like many converts, I’m an enthusiastic evangelist. I’m also not a very good Rustacean, truth be told, in that my coding style isn’t great, and I don’t write particularly idiomatic Rust. This is partly, I suspect, because I never really finished learning Rust before diving in and writing quite a lot of code (some of which is coming back to haunt me) and partly because I’m just not that good a programmer.

But I love Rust, and so should you. It’s friendly – well, more friendly than C or C++ – it’s ready for low-level systems tasks – more so than Python – it’s well-structured – more than Perl – and, best of all, it’s completely open source, from the design level up – much more than Java, for instance. Despite my lack of expertise, I noticed a few things which I suspect are common to many Rust enthusiasts and programmers, the first of which was sparked by some exciting recent news.

The word Foundation excites you

For Rust programmers, the word “Foundation” will no longer be associated first and foremost with Isaac Asimov, but with the newly formed Rust Foundation. Microsoft, Huawei, Google, AWS and Mozilla are providing the directors (and presumably most of the initial funding) for the foundation, which will look after all aspects of the language, “heralding Rust’s arrival as an enterprise production-ready technology”, according to the  Interim Executive Director, Ashley Williams (on a side note, it’s great to see a woman heading up such a major industry initiative).

The Foundation seems committed to safe-guarding the philosophy of Rust and ensuring that everybody has the opportunity to get involved. Rust is, in many ways, a poster-child example of an open source project. Not that it’s perfect (either the language or the community!), but in that there seem to be sufficient enthusiasts who are dedicated to preserving the high-involvement, low-bar approach to community which I think of as core to the much of open source. I strongly welcome the move, which I think can only help to promote Rust adoption and maturity over the coming years and months.

You get frustrated by news feed references to Rust (the game)

There’s another computer-related thing out there which goes by the name “Rust”, and it’s a “multi-player only survival video game”. It’s newer than Rust the language (having been announced only in 2013 and released in 2018), but I was once searching for Rust-related swag and, coming across it, made the mistake of searching for it. The Interwebs being what they are (thanks, Facebook, Google et al.), this meant that my news feed is now infected with this alternative Rust beast and I now get random updates from their fandom and PR folks. Thisis low-key annoying, but I’m pretty sure that I’m not alone in the Rust (language) community. I strongly suggest that if you do want to find out more about this upstart in the computing world, you use a privacy-improving (I refuse to say “privacy-preserving”) browser such as DuckDuckGo or even Tor to do your research.

The word “unsafe” makes you recoil in horror

Rust (the language, again) does a really good job of helping you do the Right Thing[TM]. Certainly in terms of memory safety, which is a major concern within C and C++ (not because it’s impossible, but because it’s really hard to get right consistently). Dave Herman wrote a post in 2016 on why safety is such a positive attribute of the Rust language: Safety is Rust’s Fireflower. Safety (memory, type safety) may not be sexy, but it’s something that you become used to, and grateful for, as you write more Rust – particularly if you’re involved in any systems programming, which is where Rust often excels.

Now, Rust doesn’t stop you from doing the Wrong Thing[TM], but it does make you make a conscious decision when you wish to go outside the bounds of safety, by making you use the unsafe keyword. This is good not only for you, as it will (hopefully) make you think really, really carefully about what you’re putting in any code block which uses it, but also for anyone reading your code: it’s a trigger word which makes any half-sane Rustacean shiver at least slightly, sit upright in their chair and think: “hmm, what’s going on here? I need to pay special attention”. If you’re lucky, that person person reading your code may be able to think of ways of rewriting your code in such a way that it does make use of Rust’s safety features, or at least reduces the amount of unsafe code that gets committed and released.

You wonder why there’s no emoji for ?; or {:?} or ::<>

Everybody loves (to hate) the turbofish (::<>), but there are other semantic constructs that you see regularly in Rust code, in particular {:?} (for string formatting) and ?; (? is a way of propagating errors up the calling stack, and ; ends the line/block, so you often see them together). They’re so common in Rust code that you just learn to parse them as you go, and they’re also so useful that I sometimes wonder why they’ve not made it into normal conversation, at least as emojis. There are probably others, too: what would be your suggestions? (Please, please no answers from Lisp adherents.)

Clippy is your friend (and not an animated paperclip)

Clippy, the Microsoft animated paperclip, was a “feature” that Office users learned very quickly to hate, and which has become the starting point for many memes. cargo clippy, on the other hand, is one of those amazing cargo commands that should become part of every Rust programmer’s toolkit. Clippy is a language linter and helps improve your code to make it cleaner, tidier, more legible, more idiomatic and generally less embarrassing when you share it with your colleagues or the rest of the world. Cargo has arguably rehabilitated the name “Clippy”, and although it’s not something I’d choose to name one of my kids, I don’t feel a sense of unease whenever I come across the term on the web anymore.

7 steps to a (bad) tech demo

Give the demo, look condescending, go home.

I’m currently involved with putting together a demo to show off the amazing progress we’ve made with Enarx recently. I’ve watched – and given – quite a few demos in my time, and I considered writing a guide to presenting a good demo. But then I thought: why? Demos should be about showing how clever we are, not about the audience – that’s pretty clear from most of the ones I’ve seen – so I decided to write a guide to a what many audiences would consider a bad demo, in other words, the type that most of us in IT are most practised at. Follow this guide, and you can be pretty certain that you will join the ranks of know-it-all, disdainful techies who are better than their audiences and have no interest in engaging with lower, less intelligent beings such as colleagues, user groups or potential customers. If you’re in marketing, sales, documentation or another function, you can still learn from this guide, and use it as part of your journey as you strive to achieve the arrogant sanctimoniousness which we techies cultivate and for which we are (in)famous. Luckily, many demos already exist which exhibit these characteristics, so you shouldn’t need to look far to find examples.

1. Assume your audience is you

You only need one demo, because everybody who matters will come from the same background as you: ultra-technical. You will, of course, be using a terminal, which means text commands to drive the demo. Don’t pander to lesser mortals by expanding parameters, for instance: why use df --all --human-readable --portability /home/mbursell/ when df -ahT ~/ is available and will save you space and time. If you really must provide graphical output (sometimes even hard-core techies have to work with GUIs, to their intense annoyance and disappointment), ensure that you’re using non-standard colours and icons. Why not use a smiley-face emoji for the “irretrievable delete” function or a thumbs-up icon for “cancel”? And you get extra points if you use a browser which still supports the <blink> tag: everybody’s favourite from the mid-90s.

Your audience shouldn’t need any context before the demo, either: if they’ve come to hear you speak, all you’re doing is giving them an update on exactly how far you have come – in other words, how clever you are. Find ways to exhibit that, and they’ll be impressed by your expertise and intelligence, which is what demos are for in the first place.

2. Don’t check it works

Your demo will, of course, work perfectly. Every time. Which means that there’s no need to check it just before delivering it. In fact, you might as well make a few last tweaks just beforehand – preferably without saving the “last good state”. Everyone will be amused if anything goes wrong – and if it does, it absolutely won’t be your fault. Here’s a list of useful things/people to blame if anything does happen:

  • the conference wifi (more difficult if you’re presenting virtually)
  • the VPN (no need to specify what VPN, or even if you’re using one)
  • other developers (who you can accuse of making last minute changes)
  • the Cloud Service Provider (again, no need to specify which one, or even if you’re using one)
  • DNS
  • certificate expiry
  • neutrinos
  • the marketing department.

3. Use small fonts and icons

Assume that everyone watching your demo:

  1. has perfect eyesight
  2. has perfect colour perception
  3. is sufficiently close to the projected image to see it (physical demo)
  4. is viewing on a screen as large as yours (online)
  5. is viewing on a screen at equal resolution to yours (online)
  6. has sufficient bandwidth that everything displays quickly and clearly enough for them to be able to see (online)
  7. can read and decipher unfamiliar text, commands, icons, obscure diagrams and dread sigils at least as quickly as you can display – and then hide – them.

4. Don’t explain

As noted above, anybody who is worthy of viewing the demo that you have put together should be immediately able to understand any context that is relevant, including any assumptions that you have made when creating the demo. “Obviously, I’ve created this WebAssembly binary directly from the Rust source file with the release flag, which means that we get good portability and type safety but decent on-the-wire speed and encryption time” is more than enough detail. You should probably have gone with something shorter like: “here’s an ls -al of the .wasm file. It’s cross-platform, safe and quick. Compiled with cargo +nightly build --release --wasm32-wasi, obviously.” Who needs a long and boring-to-deliver explanation of why you chose WebAssembly to allow users to run their applications on multiple different types of system, and the design and build decisions you made to reduce loading time over the network? No-one you care about, certainly.

5. Be very quick or very slow

This important point is related to several of the ones before. If you’ve been paying attention, you’ll know that there’s no good reason to worry about your audience and whether they’re following along, because if they’re the right type of audience (basically, they’re you), then they will already understand what’s going on. You can therefore speak as fast as you like, and whether you’re speaking their first language or not, they should pick up enough to appreciate the brilliance of the demo (in other words, your brilliance).

There is an alternative, of course, which is to speak really slowly. This should never be because you’re allowing your audience to pay attention and catch up however, but instead because you’re going into extreme detail about every single aspect of your demo, from the choice of your compilation options (see above) to the font family you use in your (many) terminals. This isn’t boring: it’s about you and your choices, so it’s interesting (to anyone who matters – see above).

6. Don’t record the demo

Your demo will work first time (unless you’re hit by problems caused by someone or something else – see 2 above), so there’s no need to record it, is there? What is more, anyone who is sufficiently interested in you, your project and your demo will attend in real-time, so there’s no need to record it for late-comers or for people to watch later. You’ll have made lots of changes within the next couple of weeks anyway, so what’s the point?

7. Don’t answer questions

Demos are for you to tell people about your project, and about you. They are not excuses for postulants to ask their questions of you. Questions generally fall into three types, none of which are of any interest to you:

  1. Stupid questions which betray how little an audience member understands about your demo. This is their fault, as they not clever enough to get what you’re doing. Ignore.
  2. Annoying questions which would be clear if people paid enough attention. These may be questions which are relevant to the demo, but which should be obvious to anyone who has done sufficient research into your work. Why should you clarify your work for lazy people? Ignore.
  3. Dangerous questions which point out possible mistakes or “improvements” to what you’ve done. You know best – you’re not showing a demo to get suggestions, but in order to expose your expertise. Ignore.

Conclusion

You are brilliant. Your demo is brilliant. Anybody who doesn’t see that is at fault, and it’s not your job to make their lives easier. Give the demo, look condescending, go home.

7 tips on how not to write a book

If you’re in the unenviable position of having to write a book: read this.

Just before Christmas – about 6 months ago, it feels like – I published a blog post to announce that I’d finished writing my book: Trust in Computing and the Cloud. I’ve spent much of the time since then in shock that I managed it – and feeling smug that I delivered the text to Wiley some 4-5 months before my deadline. As well as the core text of the book, I’ve created diagrams (which I expect to be redrawn by someone with actual skills), compiled a bibliography, put together an introduction, written a dedication and rustled up a set of acknowledgements. I even added a playlist of some of the tracks to which I’ve listened while writing it all. The final piece of text that the publisher is expecting is, I believe, a biography – I’m waiting to hear what they’d like it to look like.

All that said, I’m aware that the process is far from over: there is going to be lots of editing to be done, from checking my writing to correcting glaring technical errors. There’s an index to be created (thankfully this is not my job – it’s a surprisingly complex task best carried out those with skill and experience in the task), renaming of some chapters and sections, decisions on design issues like cover design (I hope to have some input, but don’t expect to be the final arbiter – I know my limits[1]). And then there’s the actual production process – in which I don’t expect to be particularly involved – followed by publicity and, well, selling copies. After which comes the inevitable fame, fortune and beach house in Malibu[2]. So, there’s lots more to do: I also expect to create a website to go with the book – I’ll work with my publisher on this closer to the time.

Having spent over a year writing a book (and having written a few fiction works which nobody seemed that interested in taking up), I’m still not entirely sure how I managed it, so instead of doing the obvious “how to write a book” article, I thought I’d provide an alternative, which I feel fairly well qualified to produce: how not to write a book. I’m going to assume that, for whatever reason, you are expected to write a book, but that you want to make sure that you avoid doing so, or, if you have to do it, that you’ll make the worst fist of it possible: a worthy goal. If you’re in the unenviable position of having to write a book: read this.

1. Avoid passion

If you don’t care about your subject, you’re on good ground. You’ll have little incentive to get your head into the right space for writing, because well, meh. If you’re not passionate about the subject, then actually buckling down and writing the text of the book probably won’t happen, and if, somehow, a book does get written, then it’s likely that any readers who pick it up will fast realise that the turgid, disinterested style[3] you have adopted reflects your ennui with the topic and won’t get much further than the first few pages. Your publisher won’t ask you to produce a second edition: you’re safe.

2. Don’t tell your family

I mean, they’ll probably notice anyway, but don’t tell them before you start, and certainly don’t attempt to get their support and understanding. Failing to write a book is going to be much easier if your nearest and dearest barge into your workspace demanding that you perform tasks like washing up, tidying, checking their homework, going shopping, fixing the Internet or “speaking to the children about their behaviour because I’ve had enough of the little darlings and if you don’t come out of your office right now and take over some of the childcare so that I can have that gin I’ve been promising myself, then I’m not going to be responsible for my actions, so help me.”[4]

3. Assume you know everything already

There’s a good chance that the book you’re writing is on a topic about which you know a fair amount. If this is the case, and you’re a bit of an expert, then there’s a danger that you’ll realise that you don’t know everything about the subject: there’s a famous theory[5] that those who are inexpert think they know more than they do, whereas those who are expert may actually believe they are less expert than they are. Going by this theory, if you don’t realise that you’re inexpert, then you’re sorted, and won’t try to find more information, but if you’re in the unhappy position of actually knowing what you’re up to, you will need to make an effort to avoid referencing other material, reading around the subject or similar. Just put down what you think about the issue, and assume that your aura of authority and the fact that your words are actually in print will be enough to convince your readers (should you get any).

4. Backups are for wimps

I usually find that when I forget to make a backup of a work and it gets lost through my incompetence, power cuts, cat keyboard interventions and the like, it comes out better when I rewrite it. For this reason, it’s best to avoid taking backups of your book as you produce it. My book came to almost exactly 125,000 words, and if I type at around 80wpm, that’s only 1,500[6] or 60(ish) days of writing. And it’ll be better second time around (see above!), so everybody wins.

5. Write for everyone

Your book is going to be a work of amazing scholarship, but accessible to humanities (arts) and science graduates, school children, liberals, conservatives, an easy read of great gravitas. Even if you’re not passionate about the subject (see 1), then your publisher is keen enough on it to have agreed to publish your book, so there must be a market – and the wider the market, the more they can sell! For that reason, you clearly want to ensure that you don’t try to write for particular audience (lectience?), but change your style chapter by chapter – or, even better, section by section or paragraph by paragraph.

6. Ignore deadlines

Douglas Adams said it best: “I love deadlines. I love the whooshing noise they make as they go by.” Your publisher has deadlines to keep themselves happy, not you. Write when you feel like it – your work is so good (see 5) that it’ll stay relevant whenever it finally gets published. Don’t give in to the tyranny of deadlines – even if you agreed to them previously. You’ll end up missing them anyway as you rewrite the entirety of the book when you lose the text and have no backup (see 4).

7. Expect no further involvement after completion

Once you’re written the book, you’re done, right? You might tell a couple of friends or colleagues, but if you do any publicity for your publisher, or post anything on social media, you’re in danger of it becoming a success and having to produce a second edition (see 1). In fact, you need to put your foot down before you even get to that stage. Once you’ve sent your final text to the publisher, avoid further contact. Your editor will only want you to “revise” or “check” material. This is a waste of your time: you know that what you produced was perfect first time round, so why bother with anything further? Your job was authoring, not editing, revising or checking.

(I should apologise to everyone at Wiley for this post, and in particular the team with whom I’ve been working. You can rest assured that none[7] of these apply to me – or you.)

1 – my wife and family would dispute this. How about “I know some of my limits”?

2 – maybe not, if only because I associate Malibu with a certain rum-based liqueur and ill-advised attempts to appear sophisticated at parties in my youth.

3 – this is not to suggest that authors who are interested in their book’s subject don’t sometimes write in a turgid, disinterested style. I just hope that I’ve managed to avoid it.

4- disclaimer: getting their support doesn’t mean that you won’t have to perform any of these tasks, just that there may be a little more scope for negotiation. For the couple of weeks or so, at least.

5 – I say it’s famous, but I can’t be bothered to look it up or reference it, because I assume that I know enough about the topic already. See? It’s easy when you know.

6 – it’s also worth avoiding accurate figures in technical work: just round in whichever direction you prefer.

7 – well, probably none. Or not all of them, anyway.

8 tips on how to do open source (badly)

Generally, a “build successful” or “build failed” message should be sufficient.

A while ago, I published my wildly popular[1] article How not to make a cup of tea. Casting around for something to write this week, it occurred to me that I might write about something that I believe is almost as important as to world peace, the forward march of progress and brotherly/sisterly love: open source projects. There are so many guides out there around how to create an open source project that it’s become almost too easy to start a new, successful, community-supported one. I think it’s time to redress the balance, and give you some clues about how not to do it.

Throw it over the wall

You know how it is: you’re a large corporation, you’ve had a team of developers working on a project for several years now, and you’re very happy with it. It’s quite expensive to maintain and improve the code, but luckily, it’s occurred to you that other people might want to use it – or bits of it. And recently, some of your customers have complained that it’s difficult to get improvements and new features, and partners complain that your APIs are obscure, ill-defined and subject to undocumented change.

Then you hit on a brilliant idea: why not open source it and tell them their worries are over? All you need to do is take the existing code, create a GitHub or GitLab[2] project (preferably under a Game of Thrones-themed username that happens to belong to one of your developers), make a public repository, upload all of the code, and put out a press release announcing: a) the availability of your project; and b) what a great open source citizen you are.

People will be falling over themselves to contribute to your project, and you’ll suddenly have hundreds of developers basically working for you for free, providing new features and bug fixes!

Keep a tight grip on the project

There’s a danger, however, when you make your project open source, that other people will think that they have a right to make changes to it. The way it’s supposed to work is that your product manager comes up with a bunch of new features that need implementing, and posts them as issues on the repository. Your lucky new contributors then get to write code to satisfy the new features, you get to test them, and then, if they’re OK, you can accept them into the project! Free development! Sometimes, if you’re lucky, customers or partners (the only two parties of any importance in this process, apart from you) will raise issues on the project repository, which, when appropriately subjected to your standard waterfall development process and vetted by the appropriate product managers, can be accepted as “approved” issues and earmarked for inclusion into the project.

There’s a danger that, as you’ve made the project code open source, some people might see this as an excuse to write irrelevant features and fixes for bugs that none of your customers have noticed (and therefore, you can safely assume, don’t care about). Clearly, in this case, you should reject close any issues related to such features or fixes, and reject (or just ignore) any related patched.

Worse yet, you’ll sometimes find developers[2] complaining about how you run the project. They may “fork” the project, making their own version. If they do this, beware setting your legal department on them. There’s a possibility that as your project is open source, they might be able to argue that they have a right to create a new version. Much better is to set your PR department on them, rubbishing the new project, launching ad hominem[4] attacks on them and showing everybody that you hold the moral high ground.

Embrace diversity (in licensing)

There may be some in your organisation who say that an open source project doesn’t need a licence[5]. Do not listen to their siren song: they are wrong. What your open source project needs is lots of licences! Let your developers choose their favourite for each file they touch, or, even better, let the project manager choose. The OSI maintains a useful list, but consider this just a starting point: why not liberally sprinkle different licences through your project? Diversity, we keep hearing, is good, so why not apply it to your open source project code?

Avoid documentation

Some people suggest that documentation can be useful for open source projects, and they are right. What few of them seem to understand is that their expectations for the type of documentation are likely to be skewed by their previous experience. You, on the other hand, have a wealth of internal project documentation and external product marketing material that you accrued before deciding to make your project open source: this is great news. All you need to do is to create a “docs” folder and copy all of the PDF files there. Don’t forget to update them whenever you do a new product version!

Avoid tooling

All you need is code (and docs – see above). Your internal developers have carefully constructed and maintained build environments, and they should therefore have no problems building and testing any parts of the project. Much of this tooling, being internal, could be considered proprietary, and the details must therefore be kept confidential. Any truly useful contributors will be able to work out everything they need for themselves, and shouldn’t need any help, so providing any information about how actually to build the code in the repository is basically redundant: don’t bother.

An alternative, for more “expert” organisations, is to provide build environments which allow contributors to batch builds to see if they compile or not (whilst avoiding giving them access to the tooling themselves, obviously). While this can work, beware providing too much in the way of output for the developer/tester, as this might expose confidential information. Generally, a “build successful” or “build failed” message should be sufficient.

Avoid diagrams

Despite what some people think, diagrams are dangerous. They can give away too much information about your underlying assumptions for the project (and, therefore, the product you’re selling which is based on it), and serious developers should be able to divine all they need from the 1,500 source files that you’ve deposited in the repository anyway.

A few “marketiture” diagrams from earlier iterations of the project may be acceptable, but only if they are somewhat outdated and don’t provide any real insight into the existing structure of the code.

Keep quiet

Sometimes, contributors – or those hoping to become contributors, should you smile upon their requests – will ask questions. In the old days, these questions tended to be sent to email lists[6], where they could be safely ignored (unless they were from an important customer). More recently, there are other channels that developers expect to use to contact members of the project team, such as issues or chat.

It’s important that you remember that you have no responsibility or duty to these external contributors: they are supposed to be helping you. What’s more, your internal developers will be too busy writing code to answer the sort of uninformed queries that are likely to be raised (and as for so-called “vulnerability disclosures“, you can just fix those in your internal version of the product, or at least reassure your customers that you have). Given that most open source projects will come with an issue database, and possibly even a chat channel, what should you do?

The answer is simple: fall back to email. Insist that the only channel which is guaranteed attention[7] is email. Don’t make the mistake of failing to create an email address to which people can send queries: contributors are much more likely to forget that they’re expecting an answer to an email if they get generic auto-response (“Thanks for your email: a member of the team should get back to you shortly”) than if they receive a bounce message. Oh, and close any issues that people create without your permission for “failing to follow project process”[8].

Post huge commits

Nobody[9] wants to have to keep track of lots of tiny changes to code (or, worse, documentation – see above), or have contributors picking holes in it. There’s a useful way to avoid much of this, however, which is to train your developers only to post large commits to the open source project. You need to ensure that your internal developers understand that code should only be posted to the external repository when the project team (or, more specifically, the product team) deems it ready. Don’t be tempted to use the open source repository as your version control system: you should have perfectly good processes internally, and, with a bit of automation, you can set them up to copy batches of updates to the external repository on a regular basis[10].

1 – well, lots of you read it, so I’m assuming you like it.

2 – other public repositories may be available, but you won’t have heard of them, so why should you care?

3 – the canonical term for such people is “whingers”: they are invariably “experts”. According to them (and their 20 years of security experience, etc., etc.).

4 – or ad mulierem – please don’t be sexist in your attacks.

5 – or license, depending on your spelling choice.

6 – where they existed – a wise organisation could carefully avoid creating them.

7 – “attention” can include a “delete all” filter.

8 – you don’t actually need to define what the process is anywhere, obviously.

9 – in your product organisation, at least.

10 – note that “regular” does not equate to “frequent”. Aim for a cadence of once every month or two.

5 security tips from Santa

Have you been naughty or nice this year?

If you’re reading this in 2019, it’s less than a month to Christmas (as celebrated according to the Western Christian calendar), or Christmas has just passed.  Let’s assume that it’s the former, and that, like all children and IT professionals, it’s time to write your letter to Santa/St Nick/Father Christmas.  Don’t forget, those who have been good get nice presents, and those who don’t get coal.  Coal is not a clean-burning fuel these days, and with climate change well and truly upon us[1], you don’t want to be going for the latter option.

Think back to all of the good security practices you’ve adopted over the past 11 or so months.  And then think back to all the bad security practices you’ve adopted when you should have been doing the right thing.  Oh, dear.  It’s not looking good for you, is it?

Here’s the good news, though: unless you’re reading this very, very close to Christmas itself[2], then there’s time to make amends.  Here’s a list of useful security tips and practices that Santa follows, and which are therefore bound to put you on his “good” side.

Use a password manager

Santa is very careful with his passwords.  Here’s a little secret: from time to time, rather than have his elves handcraft every little present, he sources his gifts from other parties.  I’m not suggesting that he pays market rates (he’s ordering in bulk, and he has a very, very good credit rating), but he uses lots of different suppliers, and he’s aware that not all of them take security as seriously as he does.  He doesn’t want all of his account logins to be leaked if one of his suppliers is hacked, so he uses separate passwords for each account.  Now, Santa, being Santa, could remember all of these details if he wanted to, and even generate passwords that meet all the relevant complexity requirements for each site, but he uses an open source password manager for safety, and for succession planning[3].

Manage personal information properly

You may work for a large company, organisation or government, and you may think that you have lots of customers and associated data, but consider Santa.  He manages, or has managed, names, dates of birth, addresses, hobby, shoe sizes, colour preferences and other personal data for literally every person on Earth.  That’s an awful lot of sensitive data, and it needs to be protected.  When people grow too old for presents from Santa[4], he needs to delete their data securely.  Santa may well have been the archetypal GDPR Data Controller, and he needs to be very careful who and what can access the data that he holds.  Of course, he encrypts all the data, and is very careful about key management.  He’s also very aware of the dangers associated with Cold Boot Attacks (given the average temperature around his relevance), so he ensures that data is properly wiped before shutdown.

Measure and mitigate risk

Santa knows all about risk.  He has complex systems for ordering, fulfilment, travel planning, logistics and delivery that are the envy of most of the world.  He understands what impact failure in any particular part of the supply chain can have on his customers: mainly children and IT professionals.  He quantifies risk, recalculating on a regular basis to ensure that he is up to date with possible vulnerabilities, and ready with mitigations.

Patch frequently, but carefully

Santa absolutely cannot afford for his systems to go down, particularly around his most busy period.  He has established processes to ensure that the concerns of security are balanced with the needs of the business[5].  He knows that sometimes, business continuity must take priority, and that on other occasions, the impact of a security breach would be so major that patches just have to be applied.  He tells people what he wants, and listens to their views, taking them into account where he can. In other words, he embraces open management, delegating decisions, where possible, to the sets of people who are best positioned to make the call, and only intervenes when asked for an executive decision, or when exceptions arise.  Santa is a very enlightened manager.

Embrace diversity

One of the useful benefits of running a global operation is that Santa values diversity.  Old or young (at heart), male, female or gender-neutral, neuro-typical or neuro-diverse, of whatever culture, sexuality, race, ability, creed or nose-colour, Santa takes into account his stakeholders and their views on what might go wrong.  What a fantastic set of viewpoints Santa has available to him.  And, for an Aging White Guy, he’s surprisingly hip to the opportunities for security practices that a wide and diverse set of opinions and experiences can bring[6].

Summary

Here’s my advice.  Be like Santa, and adopt at least some of his security practices yourself.  You’ll have a much better opportunity of getting onto his good side, and that’s going to go down well not just with Santa, but also your employer, who is just certain to give you a nice bonus, right?  And if not, well, it’s not too late to write that letter directly to Santa himself.

1 – if you have a problem with this statement, then either you need to find another blog, or you’re reading this in the far future, where all our climate problems have been solved. I hope.

2 – or you dwell in one of those cultures where Santa visits quite early in December.

3 – a high-flying goose in the face can do terrible damage to a fast-moving reindeer, and if the sleigh were to crash, what then…?

4 – not me!

5 – Santa doesn’t refer to it as a “business”, but he’s happy for us to call it that so that we can model our own experience on his.  He’s nice like that.

6 – though Santa would never use the phrase “hip to the opportunities”.  He’s way too cool for that.

How not to make a cup of tea

This is an emotive topic.

A few weeks ago, I wrote an article entitled “My 7 rules for remote-work sanity“. This was wildly successful, caused at least one email storm on our company servers, and caused a number of readers to ask me to tackle the question of how to make a cup of tea. Because that isn’t contentious at all.

I’ve resisted that, partly because this is (supposed to be) mainly a security blog, and partly because it would be too easy. Instead, I’ve written this article, which is full of advice and guidance about how not to make a cup of tea or, more accurately, how to make a bad cup of tea. This isn’t hugely related to security either, but as I’ve been writing it, it’s reminded me of how strong the idea of “anti-patterns” is, particularly in security. Sometimes it’s hard to explain to people how they should apply security controls to system, and it’s easier to explain what not to do, so that people can learn from that. This is my (very tenuous) link to security in this article. I hope it (and the rest of the article) serve you well.

I am British, but I travel quite frequently to the United States and to Canada. During my travels, I have been privileged to witness many, many attempts to make tea which have been catastrophic failures. This article is an attempt to celebrate these failures so that people, like me, who have learned over many years how to make tea properly, can celebrate the multitude of incorrect ways in which tea can be ruined.

This is an emotive topic. There are shades of opinion across many issues (upon some of which we will touch during this article), across class lines, geographical lines and even moral lines (I’m thinking here in particular of the question of whether to use cow’s milk – an ethical point for vegans). And, so you understand that I’m not overstating the divides that can occur over this important skill, I’d point out that an entire war was started solely over the belief of a certain group of people who believed that the correct way to make tea was to dump an entire shipment of leaves into a salt-water harbour[1] in a small settlement named after a town in Lincolnshire[2].

Without further ado, let us launch into our set of instructions for how not to make tea (by which I mean “hot black tea” in this context), but with a brief (yet important) digression.

De minimis

There are certain activities associated with the making of tea which I am going to declare “de minimis” – in other words, of minimal importance to the aim of creating a decent cup of tea. These may be areas of conflict within the tea drinking community, but I would argue that the majority of Real Tea Drinkers[tm] would accept that a cup of tea would not be ruined by following any of the options for any of the practices noted below. As this article aims to provide a beginner’s guide to how not to make tea, I contend that your choice of any of the options below will not (at least on its own) cause you to be making not-Tea.

  • Milk, not milk or lemon: I drink my tea with milk. Some drink it without, and some with lemon. Tea can be tea in any of these states.
  • Sugar or not sugar: I used to drink my tea with sugar, but now do not. Tea can be tea with or without sugar.
  • Cup or mug: I prefer a mug for most tea drinking opportunities, but a cup (with saucer) can make a nice change.
  • Bag or loose leaf: we’re getting into contentious territory here. I have recently moved to a strong preference for loose leaf, partly because it tends to be higher quality than bags, but if bags are what you’ve got, then you can make a decent cup of tea with them.
  • In the pot or in the mug: if you’re using loose leaf tea, then it’s in the pot. If it’s in a mug, then it’s a bag. You can, however, make tea in a pot with a bag.
  • Milk first or afterwards: there’s evidence to suggest that putting the milk in first means that it won’t scald, but I’m with George Orwell[3] on this: if you put the tea in first, you can add milk slowly to ensure the perfect strength.
  • Warming the pot: you only need to warm the pot if you’re using bone china. End of.

You might think that I’ve just covered all the important issues of contention above, and that there’s not much point in continuing with this article, but please remember: this article is not aimed at those who wish to make an acceptable cup of tea, but to those who do not wish to make the same. Those who wish to make a cup of non-tea will not be swayed by the points above, and neither should they be. If you belong in this group: whether (for example) a person of North American descent looking to cement your inability to make a cup of tea, or (again, for example) a person of British descent looking for guidance in how to be accepted into North American society by creating a representative cup of non-tea, then, dear reader, please read on.

Instructions

Tea (actual)

The easiest way to fail to make a cup of tea is to choose something which isn’t tea. I’m going to admit to a strong preference to black tea here, and this article is based on how to make a cup of black tea, but I admit to the existence of various other tea types (yellow, white, green, oolong). All of them, however, come from the tea plant, Camellia sinensis. If it doesn’t, then it isn’t tea. Retailers and manufacturers can label it “herbal tea”[4]. Anything which doesn’t come from from the tea plant is an infusion or a tisane.

To be clear, I absolutely include Rooibos or “Red Bush” tea. I tried this once, under the mistaken belief that it was actual tea. The experience did not end well. I’m sure there’s a place for it, but not in my mug (or cup), and it’s not tea. I mean: really.

There are some teas which are made from the tea plant, and have flavourings added. I’m thinking in particular of Earl Grey tea, which has oil of bergamot added to it. I’m not a fan, but that’s partly due to a very bad experience one morning after the imbibing of a significant amount of beverages which definitely weren’t ever pretending to be tea, the results of which also lead to my not drinking gin and tonic anymore[5].

To clarify, then:

  • tea: yes, tea.
  • Earl Grey: yes, tea.
  • rooibos: not tea.
  • fruit tea: not tea.
  • lemon tea: not tea.
  • rhubarb and orange tea: not tea
  • raspberry and old sticks tea: not tea.
  • vanilla tea: not tea.
  • etc., etc.

The very easiest way not to make tea, then, is to choose something which isn’t derived directly from the Camellia sinensis plant. If you’re looking for more adventurous or expert ways not to make tea, however, carry on.

Use non-boiling water

Beyond the obvious “not actually using tea” covered above, the easiest way to fail to make a cup of tea is to use water which is not sufficiently hot. And by “sufficiently hot”, I mean “has just come off the boil”. There’s actual science[6] showing that lots of the important tea-making processes cannot take place at temperatures below 90°C (194°F). To be sure that you’re going to make a cup of bad tea, just be sure not to go with boiling water.

I’ve recently visited a number of establishments in the USA where they offered to make tea with water designed for coffee-making at temperatures of 175°F and 183°F. That’s 79.4°C and 83.9°C. A member of staff at one of these establishments explained that it would be “dangerous” to use water at a higher temperature. I kid you not. They knew that they didn’t need to aim for just off the boil: well under 99°C should do nicely for something almost but not quite like a cup of tea. A warning: many (but not all) outlets of Peet’s Coffee do provide water which is hot enough (often 211-212°F) , if you ask them. You are in significant danger of getting a proper cup of tea if you’re not very careful. This, in my experience, is entirely unique for a coffee chain anywhere in the USA.

Many US hotels will offer to make you a cup of tea in the morning, if you ask nicely enough and sound (passive-aggressively) British enough. You might think that you would be guaranteed a proper cup, but worry not: they will almost certainly use really bad tea, the water will be insufficiently hot and they will definitely not bother to pour it directly over the tea-bag anyway. Hotels are great places to find a really bad cup of tea in the USA.

As a minor corollary of this, another way to fail to make a cup of tea is to boil the water at altitude (e.g. up a mountain) or in an airplane. Because air pressure is reduced in both cases, the boiling point of water is reduced, and so you’re not likely to be able to get the water hot enough, so that’s another great option.

Boil the water incorrectly

What: you didn’t know that you could boil water incorrectly? Oh, but you can. Proper tea is made from water boiled once in a kettle, because if you boil it more than once, something happens: you’ve removed oxygen that was originally dissolved in the water, and this turns out to make it taste bad.

Use the wrong type(s) of milk

The easy way out is to use 2% (semi-skimmed) or 4% (whole fat) cow’s milk, but you don’t want to do that: that’ll give you proper tea. In order not to make tea properly, try UHT milk, almond milk, soy milk or similar. I haven’t tried ewe’s or goat’s milk, but I’m sure it’s easy to mess up a good cup of tea with those.

Condensed milk is an interesting option. I’ve had this in India – where I think they add it instead of sugar – and, well, it didn’t taste like tea to me.

Let it go cold

I’m not even talking about so called “iced tea” here. I’m just talking about tea which has been brewed, then poured, then left to go cold. Yuck.

Brew for too long

Quite apart from the fact that it may go cold, it’s possible to make tea just too strong. There’s a range that most people will accept as proper tea, but you can leave most tea too long, and it will be too strong when you pour it. How long that is will depend partly on preference, and partly on the type of tea you’re using. If you want to ensure you make a bad cup of tea, tune these carefully.

Don’t brew for long enough

Again, it’s easy to get this wrong. Some types of tea brew very quickly, and you’re in danger, for these types, of pouring a decent cup despite your best interests. Use this technique with care, and preferably in conjunction with others of the approaches listed.

Use a little strainer

It is possible to make a decent cuppa with one of those little strainers into which you place your tea leaves, but it’s difficult. The problem seems to be that in order to make a properly strong cup of tea, you’re going to need to put quite a lot of tea leaves into the strainer. This means that the water won’t be able to interact with most of them, as they’ll be stuffed in, and not able to circulate properly. You can try swishing it around a bit, but by the time you’ve got to this, the water will probably be too cold (see above).

Microwave

Microwave your water. This is wrong on so many levels (do a search online).

Use bad tea

Mainly, I think, because most US citizens have no idea how to make a cup of tea properly, they are willing to accept the stuff that passes for “tea bags” in the US as actual tea. There are exceptions, but the standard fare that you’ll find on supermarket shelves isn’t anything like actual tea, so it’s very simple to make a bad cup even if you’ve done everything else right.

My preferred cup of tea

After all of the above, you may be wondering what my preferred cup of tea looks like. Here’s a brief algorithm, which I’m happy to open source:

  1. freshly drawn water in the kettle
  2. kettle boiled
  3. a teaspoon of tea into a small pot (how heaped depends on the type), current favourites include:
  4. pour the boiling water into pot (I tend to use pots with built-in strainers)
  5. allow to brew (how long depends on the type of tea)
  6. pour from the pot into a large mug (not too large, or the tea will get too cold to drink before you get to the bottom)
  7. add semi-skimmed (2%) milk (not UHT)
  8. drink as soon as its cooled enough not to blister the inside of the mouth
  9. leave the bottom few millimetres to avoid ingesting any leaves which may have made their way into the mug.

So there you have it. That’s how I make a cup of tea.

1 – yes, that’s how to spell it.

2 – I’m assuming this was the sole reason. I’m a little hazy on the details, but it all seems to have turned out OK for both sides.

3 – who, given that he wrote both the books Animal Farm and 1984, knew a thing or two about how not to do things.

4 – yes, there’s an “h”, yes it’s aspirated. “‘erbal?” Not unless dropping aitches is part of your general dialect and accent, in which case, fine.

5 – I still drink gin, only not with tonic. It’s the tonic water that I’ve managed to convince my taste buds was the cause of the resulting … problem.

6 – Really, look!