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!

16 ways in which security folks are(n’t) like puppies

Following the phenomenal[1] success of my ground-breaking[2] article 16 ways in which users are(n’t) like kittens, I’ve decided to follow up with a yet more inciteful[3] article on security folks. I’m using the word “folks” to encompass all of the different types of security people who “normal”[4] people think of “those annoying people who are always going on about that security stuff, and always say ‘no’ when we want to do anything interesting, important, urgent or business-critical”. I think you’ll agree that “folks” is a more accessible shorthand term, and now that I’ve made it clear who we’re talking about, we can move away from that awkwardness to the important[5] issue at hand.

As with my previous article on cats, I’d like my readers to pretend that this is a carefully researched article, and not one that I hastily threw together at short notice because I got up a bit late today.

Note 1: in an attempt to make security folks seem a little bit useful and positive, I’ve sorted the answers so that the ones where security folks turn out actually to share some properties with puppies appear at the end. But I know that I’m not really fooling anyone.

Note 2: the picture (credit: Miriam Bursell) at the top of this article is of my lovely basset hound Sherlock, who’s well past being a puppy. But any excuse to post a picture of him is fair game in my book. Or on my blog.

Research findings

Hastily compiled table

Property Security folks Puppies
Completely understand and share your priorities
No No
Everybody likes them
No Yes
Generally fun to be around No Yes
Generally lovable No Yes
Feel just like a member of the family No Yes
Always seem very happy to see you No Yes
Are exactly who you want to see at the end of a long day No Yes
Get in the way a lot when you’re in a hurry
Yes Yes
Make a lot of noise about things you don’t care about Yes Yes
Don’t seem to do much most of the time
Yes Yes
Constantly need cleaning up after
Yes Yes
Forget what you told them just 10 minutes ago Yes Yes
Seem to spend much of their waking hours eating or drinking Yes Yes
Wake you up at night to deal with imaginary attackers Yes Yes
Can turn bitey and aggressive for no obvious reason
Yes Yes
Have tickly tummies Yes[6] Yes

1 – relatively.

2 – no, you’re right: this is just hype.

3 – this is almost impossible to prove, given quite how uninciteful the previous one was.

4 – i.e., non-security.

5 – well, let’s pretend.

6 – well, I know I do.

6 reasons to go (and not go) to a security conference

…the parties – don’t forget the many, many parties.

I’m at the annual RSA Conference this week in San Francisco. There are a number of RSA Conferences around the world, but this is the big one. There will be thousands – in fact, tens of thousands – of people attending, probably hundreds of exhibitors, and I’ve just pored through the many, many sessions available just on the first day to identify the ones I want to attend.

RSA – as other conferences – comes under fire for just being an opportunity for security vendors to pitch their wares, rather than a conference about security, and there is some truth in that. To be fair, though, they’re the ones sponsoring the show[1], and making it all work, and many of them will pay, as part of that sponsorship, to have sessions where they will pitch their products. And people attend these talks[3] – it’s really not my thing (and I’ve written about it in the past), but I’ve noticed that this year, there are clues in the session title that a particular talk will be sponsor-led, so more opportunities to avoid them if you’re not interested.

There are, however, lots and lots of talks that aren’t just product pitches. These range from the uber-technical academic cryptography talks[4] to “how we managed to deal with this problem in my company”, “what we’ve learned over 5/10/20/100 years of X” and innumerable talks on DevSecOps, Agile, security for/within/outside/above the Cloud by vendors, airlines, software companies, banks, insurance companies and very few start-ups.

I’ve been a little harsh in the previous paragraph, but I reckon there’s actually going to be something (probably many things – choosing between the multiple sessions scheduled at the same time can be challenging) for everybody. I always get a little annoyed that there’s not enough talk about systems security and complexity, but there actually seems to be a little more of that this year – though I’m willing to bet that the expo hall will be somewhat light on the same, with the usual SIEM, email security, storage, authentication, authorisation, logging and network tools being very much in evidence, alongside big consultancies and some a few small companies, not-for-profits and educational institutions.

6 reasons to attend a security conference

What, then, are some good reasons to attend a security conference? Here are my top 6 – in no particular order:

  1. sessions which will teach you something new – or help you see something from somebody else’s perspective;
  2. catching up with colleagues who you don’t otherwise get to see;
  3. the hallway track – meeting people between sessions, at meals or parties, in the lift[5] at your hotel and striking up a conversation;
  4. being able to check out vendors at their booths in the expo, and get demos of their products;
  5. swag and give-aways[6];
  6. the parties.

6 reasons not to attend a security conference

It only seems fair to provide the flipside, so here we go, this time in a particular order:

  1. sessions which won’t teach you anything new – or which show you something from the perspective of a speaker who you suspect has never worked in the real world, or is a complete idiot;
  2. catching up with colleagues who you’ve managed to avoid for the past 12 months, but who realise that you’re going to be at the show, and who you can’t politely put off meeting;
  3. the hallway track – being accosted by people between sessions who’ve seen your badge, have heard of your company, and have a particular feature that they really, really want you to implement, despite the fact that a) you’re not on the product team and b) they only buy one licence/subscription from your company a year;
  4. being subjected to demos by vendors at their booths in the expo because you didn’t move away fast enough, despite the fact that you only moved close to find out what their swag was;
  5. swag and give-aways – too many t-shirts (never enough in womens’ sizes, I’m told), and realisation that you’ve got so many that you’re going to have to check in extra hold luggage on the way back home to get it back to your children, who will have no interest in it, anyway;
  6. the parties – in particular the standard of the wine (poor) and beer (either so hoppy it makes your teeth retract into your gums or so gassy that you swell up to the size of a beachball) – and how you feel after them.

So, make your choices, and decide whether to go or not. I’ll keep an eye out for you in the lift at the hotel…


1 – and the parties – don’t forget the many, many parties[2].

2 – painkillers and heartburn medication are must-pack items for any serious attendees.

3 – not always on purpose – there are times when you’ll see an early exodus of people as they realise what they turned up to.

4 – all credit if you manage to get past the first slide of mathematics.

5 – I don’t care if it’s in the US, I’m not calling it an escalator.

6 – I reckon that the standard of swag at a conference is directly proportional to the strength of the market in that the sector 6 months ago – there’s a delay in marketing budgets.

Merry “sorting out relatives’ IT problems” Day

Today’s the day – or the season – when your mother-in-law asks you to fix her five year old laptop, unclog the wifi (it’s usually her husband, “stealing it all”) or explain why her mouse mat is actually easily large enough – she just needs to lift the mouse up and place it back in the middle if she can’t get the cursor to go any further right.

Lucky me: I didn’t even have to wait till Christmas Day this year: my m-in-law called us at home a couple of days ago to complain that “the email thingy isn’t working on my tablet and the Chrome has gone”. After establishing that her Chrome Book (upstairs) was fine, and she just couldn’t be bothered to ascend the stairs to use it for the two days before we came to visit and I could debug her tablet problem in person, I proceeded to debug the problem over the crackly wireless DECT phone they keep attached to their land line, instead[1].

Despite the difficulty in making out approximately 25% of the words down the line, I became more and more convinced that even if her tablet was having problems, then a reboot of her router was probably due.

Me: so you know which one the router is?

Her: umm…

Me: it’s the little box where the Internet comes in.

Her: is it in the hall?

Me, to the wife, who’s smirking, since she managed to offload this call to me: could it be in the hall?

Wife: yes, it’s in the hall.

Me: yes, it’s in the hall.

Mother-in-law: OK.

Me: there should be a power button on the front or the back, or you can just pull the power lead out if that’s easiest.

Her, clearly bending over to look at it: shall I just turn it off at the wall? That might be simplest?

Me: well, OK.

Her: Right, I’m doing that n… BEEEEEEEEEEEEEEP.

It turns out that her DECT phone hub is plugged into the same socket. Of course. This is my life. This is OUR life.

Merry Christmas, and a Happy New Year to you all.


1 – this, folks, is how to stay married for 23 and a half years[2].

2 – and counting.

The Twelve Days of Work-Life Balance

12 tips for working at home over the holidays

Disclaimer: the author refuses to take any blame for any resulting disciplinary or legal action taken against readers who follow any of the suggestions in this article.

There’s a good chance that things slow down for the holiday season at your organisation or company[1], and as they do, there’s a corresponding[2] chance that you may end up not going into the office for some of the upcoming days.  Some workplaces expect you to turn up to work in the office unless you’re officially on holiday, while others allow or encourage workers to be based at home and perform their duties there for all or some of the period.  It’s those people who will be spending time at home who are targeted by this article.

Working from home is an opportunity to bunk off and is a complete wheeze a privilege and responsibility to be taken seriously.  There are, however, some important techniques that you should take on board to ensure not only that you continue to be productive but, even more important, that you continue to be seen to be productive.  I’ve split my tips up into helpful headings for your ease of use.

Video calls

Tip 1 (for those who shave): you don’t need to.  Yes, the resolution on webcams has increased significantly, but who’s going to care if it looks like you’ve just rolled out of bed?  The fact that you’ve even bothered shows your commitment to the meeting you’re attending.

Tip 2 (for those who wear make-up): far be it from me to dictate whether you wear make-up or not to meetings.  But if you choose to, there’s no need to refresh last night’s make-up in the morning.  If you’ve staggered home late, you may not have got round to removing your party lipstick and mascara, and it may even have smudged or run a bit: don’t worry.  It’ll look “festive” in the morning, and will encourage a relaxed atmosphere at the meeting.

Tip 3 (for coffee drinkers): you may need an extra cup of coffee in the afternoon, to get you through the day.  Who’s going to know if you add a shot to it?  It’ll keep you warm, and possibly upright.  My wife swears by Baileys.  Or Irish Whiskey.  Or gin.  Pretty much anything, in fact.

Tip 4 (for non-coffee drinkers): cocktails are a no-no for video conferences, unless approved by management (sorry).  However, there are a number of other options to explore.  A Long Island Iced Tea looks like, well, an iced tea.  Whisky (or whiskey) can look like normal tea, and my personal favourite, cherry brandy, looks like a child’s fruit cordial that you didn’t dilute sufficiently.  And tastes fairly similar.

Tip 5 (for clothes wearers): few organisations (of which I’m aware, anyway) have adopted a non-clothing policy for video-calls.  Clothes are required.  My favourite option is to wear a festive jumper, but this is only fun if it has woven-in flashing lights which can distract your fellow participants[3].  Coordinating the periodicity of the flashing with colleagues gets you bonus points.

Tip 6 (also for clothes wearers): wear something on your bottom half.  I know you think you may not be getting up during the call, but when a small child vomits in the background, the postal worker arrives at the door, or you just need another cup of coffee or “beverage” (see tips 3 & 4) to get you through the next two hours, you’ll be grateful for this advice.

Teleconferences (non-video)

Tip 7: use a chat channel to have a side conversation with your peers. You can have hilarious discussions about the intellectual capacity and likely parentage of your management, or even better, play a game of meeting bingo.

Tip 8: the mute button is for cowards.  Yes, wind can be a problem after an over-indulgence at the pub, club or party the night before, and microphones can be quite sensitive these days, but who’s to know it’s you[4]?

Emails

Tip 9: the best time to respond to an email is when you receive it, right?  This will show everybody how devoted you are to your job.  So if it arrives after you’ve already partaken of a brew or two down the pub, or sampled the herbal opportunities recently decriminalised in your state in your bedroom, then replying immediately will almost certainly be considered responsible and professional.  And auto-correct will almost certainly act in your favour: after all, your boss really is a complete duck, yes?

Tip 10: pepper your emails with poor festive puns[5].  It’s just what you do.

Family

Tip 11: you may have agreed to “work” over this period as an excuse to avoid spending too much time with the family[6], but there’s always the chance that they will barge into your office, throw up in the hall (see tip 6), or just fall asleep on your keyboard[7].  Invest in a lock on your office door, or work somewhere out of range[8].  Your work is important, and you must guard against unwanted interruptions, such as being awoken from an important doze.

Productivity

Tip 12: it’s your responsibility, when working from home, to ensure that you maintain your productivity.  But breaks are important.  There’s a tricky balance here between protecting your time from the family (you don’t want them to notice that you’re not online 100% of the time) and taking sensible amounts of breaks.  Assuming that you’ve taken my advice about locking your office door, then placing an XBox or similar gaming console on your desk next to your work computer is a great way of allowing yourself some downtime without risking the wrath of your family (assuming careful monitor placement and controller handling).

Tip 12a (extra tip!): if you’re not careful, too much time hidden away from the family will get you in trouble.  My piece of advice here is to offer to help.  But on your own terms.  Rushing out of your office[9], looking harried and then announcing “I’ve got ten minutes until my next call, and I’m feeling guilty: is there anything I can do?” can gain you useful credit without the risk of your having to do anything too taxing.

Summary[10]

You can maintain a productive and professional workplace at home if called to do so by your organisation.  It is your responsibility to balance the needs of work with your needs and, of course, the needs of your family.

Have a Merry Christmas (or other festival) and a Happy New Year (whenever it falls for you)!


1 – this is generally a Judaeo-Christian set of holidays, but I hope that this article is relevant to most holidays: religious, national, regional or secular.

2 – and possibly correlateable, though check out one of my favourite XKCD comics: https://xkcd.com/552/.

3 – owners of luxuriant beards or heads of hair may prefer to weave flashing fairy lights into their hair for a similar effect.

4 – except for the small matter of the little indicator against each participant’s name which shows who’s “talking”.

5 – “Your presents is requested.”  “But wait—there’s myrrh.” You get the idea.

6 – “Sorry, darling, I know your parents are here, but a really critical bug came in, and I’m the only one who can look at it in time…”

7 – mainly a problem for owners of cats or teenagers.

8 – try searching for “Where’s a pub near me that’s open now?”.

9 – don’t forget to lock it again, in case a child notices and purloins that gaming console.

10 – in the Southern Hemisphere, at least.  Sorry: see [5].