employment – Dan Q

I Wrote the Same Code Six Times!

I was updating my CV earlier this week in anticipation of applying for a handful of interesting-looking roles¹ and I was considering quite how many different tech stacks I claim significant experience in, nowadays.

There are languages I’ve been writing in every single week for the last 15+ years, of course, like PHP, Ruby, and JavaScript. And my underlying fundamentals are solid.

But is it really fair for me to be able to claim that I can code in Java, Go, or Python: languages that I’ve not used commercially within the last 5-10 years?

Obviously, I couldn’t just let that question lie². Let’s find out!

The Test

I fished around on Glassdoor for a bit to find a medium-sized single-sitting tech test, and found a couple of different briefs that I mashed together to create this:

In an object-oriented manner, implement an LRU (Least-Recently Used) cache:

The size of the cache is specified at instantiation.

Arbitrary objects can be put into the cache, along with a retrieval key in the form of a string. Using the same string, you can get the objects back.

If a put operation would increase the number of objects in the cache beyond the size limit, the cached object that was least-recently accessed (by either a put or get operation) is removed to make room for it.

putting a duplicate key into the cache should update the associated object (and make this item most-recently accessed).

Both the get and put operations should resolve within constant (O(1)) time.

Add automated tests to support the functionality.

My plan was to implement a solution to this challenge, in as many of the languages mentioned on my CV as possible in a single sitting.

But first, a little Data Structures & Algorithms theory:

The Theory

Simple case with O(n) complexity

The simplest way to implement such a cache might be as follows:

Use a linear data structure like an array or linked list to store cached items.
On get, iterate through the list to try to find the matching item.
- If found: move it to the head of the list, then return it.
On put, first check if it already exists in the list as with get:
- If it already exists, update it and move it to the head of the list.
- Otherwise, insert it as a new item at the head of the list.
  - If this would increase the size of the list beyond the permitted limit, pop and discard the item at the tail of the list.

Illustration of a simple Cache class with a linked list data structure containing three items, referenced from the class by its head item. It has 'get' and 'put' methods. — It’s simple, elegant and totally the kind of thing I’d accept if I were recruiting for a junior or graduate developer. But we can do better.

The problem with this approach is that it fails the requirement that the methods “should resolve within constant (O(1)) time”³.

Of particular concern is the fact that any operation which might need to re-sort the list to put the just-accessed item at the top ⁴. Let’s try another design:

Achieving O(1) time complexity

Here’s another way to implement the cache:

Retain cache items in a doubly-linked list, with a pointer to both the head and tail
Add a hash map (or similar language-specific structure) for fast lookups by cache key
On get, check the hash map to see if the item exists.
- If so, return it and promote it to the head (as described below).
On put, check the hash map to see if the item exists.
- If so, promote it to the head (as described below).
- If not, insert it at the head by:
  - Updating the prev of the current head item and then pointing the head to the new item (which will have the old head item as its next), and
  - Adding it to the hash map.
  - If the number of items in the hash map would exceed the limit, remove the tail item from the hash map, point the tail at the tail item’s prev, and unlink the expired tail item from the new tail item’s next.
To promote an item to the head of the list:
1. Follow the item’s prev and next to find its siblings and link them to one another (removes the item from the list).
2. Point the promoted item’s next to the current head, and the current head‘s prev to the promoted item.
3. Point the head of the list at the promoted item.

Illustration of a more-sophisticated Cache class with a doubly-linked list data structure containing three items, referenced from the class by its head and tail item. It has 'get' and 'put' methods. It also has a separate hash map indexing each cached item by its key. — Looking at a plate of pointer-spaghetti makes me strangely hungry.

It’s important to realise that this alternative implementation isn’t better. It’s just different: the “right” solution depends on the use-case⁵.

The Implementation

That’s enough analysis and design. Time to write some code.

Picking a handful of the more-useful languages on my CV⁶, I opted to implement in:

Ruby (with RSpec for testing and Rubocop for linting)
PHP (with PHPUnit for testing)
TypeScript (running on Node, with Jest for testing)
Java (with JUnit for testing)
Go (which isn’t really an object-oriented language but acts a bit like one, amirite?)
Python (probably my weakest language in this set, but which actually ended up with quite a tidy solution)

Naturally, I open-sourced everything if you’d like to see for yourself. It all works, although if you’re actually in need of such a cache for your project you’ll probably find an alternative that’s at least as good (and more-likely to be maintained!) in a third-party library somewhere!

What did I learn?

This was actually pretty fun! I might continue to expand my repo by doing the same challenge with a few of the other languages I’ve used professionally at some point or another⁷.

And there’s a few takeaways I got from this experience –

Lesson #1: programming more languages can make you better at all of them

As I went along, one language at a time, I ended up realising improvements that I could make to earlier iterations.

For example, when I came to the TypeScript implementation, I decided to use generics so that the developer can specify what kind of objects they want to store in the cache, rather than just a generic Object, and better benefit type-safety. That’s when I remembered that Java supports generics, too, so I went back and used them there as well.

In the same way as speaking multiple (human) languages or studying linguistics can help unlock new ways of thinking about your communication, being able to think in terms of multiple different programming languages helps you spot new opportunities. When in 2020 PHP 8 added nullsafe operators, union types, and named arguments, I remember feeling confident using them from day one because those features were already familiar to me from Ruby⁸, TypeScript⁹, and Python¹⁰, respectively.

Lesson #2: even when I’m rusty, I can rely on my fundamentals

I’ve applied for a handful of jobs now, but if one of them had invited me to a pairing session on a language I’m rusty on (like Java!) I might’ve felt intimidated.

But it turns out I shouldn’t need to be! With my solid fundamentals and a handful of other languages under my belt, I understand when I need to step away from the code editor and hit the API documentation. Turns out, I’m in a good position to demo any of my language skills.

I remember when I was first learning Go, I wanted to make use of a particular language feature that I didn’t know whether it had. But because I’d used that feature in Ruby, I knew what to search for in Go’s documentation to see if it was supported (it wasn’t) and if so, what the syntax was¹¹.

Lesson #3: structural rules are harder to gearshift than syntactic ones

Switching between six different languages while writing the same application was occasionally challenging, but not in the ways I expected.

I’ve had plenty of experience switching programming languages mid-train-of-thought before. Sometimes you just have to flit between the frontend and backend of your application!

But this time around I discovered: changes in structure are apparently harder for my brain than changes in syntax. E.g.:

Switching in and out of Python’s indentation caught me out at least once (might’ve been better if I took the time to install the language’s tools into my text editor first!).
Switching from a language without enforced semicolon line ends (e.g. Ruby, Go) to one with them (e.g. Java, PHP) had me make the compiler sad several times.
This gets even tougher when not writing the language but writing about the language: my first pass at the documentation for the Go version somehow ended up with Ruby/Python-style #-comments instead of Go/Java/TypeScript-style //-comments; whoops!

I’m guessing that the part of my memory that looks after a language’s keywords, how a method header is structured, and which equals sign to use for assignment versus comparison… are stored in a different part of my brain than the bit that keeps track of how a language is laid-out?¹²

Okay, time for a new job

I reckon it’s time I got back into work, so I’m going to have a look around and see if there’s any roles out there that look exciting to me.

If you know anybody who’s looking for a UK-based, remote-first, senior+, full-stack web developer with 25+ years experience and more languages than you can shake a stick at… point them at my CV, would you?

Footnotes

¹ I suspect that when most software engineers look for a new job, they filter to the languages, frameworks, they feel they’re strongest at. I do a little of that, I suppose, but I’m far more-motivated by culture, sector, product and environment than I am by the shape of your stack, and I’m versatile enough that technology specifics can almost come second. So long as you’re not asking me to write VB.NET.

² It’s sort-of a parallel to how I decided to check the other week that my Gutenberg experience was sufficiently strong that I could write standard ReactJS, too.

³ I was pleased to find a tech test that actually called for an understanding of algorithm growth/scaling rates, so I could steal this requirement for my own experiment! I fear that sometimes, in their drive to be pragmatic and representative of “real work”, the value of a comprehension of computer science fundamentals is overlooked by recruiters.

⁴ Even if an algorithm takes the approach of creating a new list with the inserted/modified item at the top, that’s still just a very-specific case of insertion sort when you think about it, right?

⁵ The second design will be slower at writing but faster at reading, and will scale better as the cache gets larger. That sounds great for a read-often/write-rarely cache, but your situation may differ.

⁶ Okay, my language selection was pretty arbitrary. But if I’d have also come up with implementations in Perl, and C#, and Elixir, and whatever else… I’d have been writing code all day!

⁷ So long as I’m willing to be flexible about the “object-oriented” requirement, there are even more options available to me. Probably the language that I last wrote longest ago would be Pascal: I wonder how much of that I remember?

⁸ Ruby’s safe navigation/”lonely” operator did the same thing as PHP’s nullsafe operator since 2015.

⁹ TypeScript got union types back in 2015, and apart from them being more-strictly-enforced they’re basically identical to PHP’s.

¹⁰ Did you know that Python had keyword arguments since its very first public release way back in 1994! How did it take so many other interpreted languages so long to catch up?

¹¹ The feature was the three-way comparison or “spaceship operator”, in case you were wondering.

¹² I wonder if anybody’s ever laid a programmer in an MRI machine while they code? I’d be really interested to see if different bits of the brain light up when coding in functional programming languages than in procedural ones, for example!

Note #26654

I’m applying for a few roles that might be the next step in my career. And to my surprise, updating my CV and tweaking my portfolio is doing a world of good for my feelings of self-worth!

Seriously: looking back over the last ~25 years of my career and enumerating the highlights is giving me a better “big picture” view of everything I’ve achieved than I ever got from the near-focus of daily work. I should do this more often!

Deprecate React

I’m keeping an eye out for my next career move (want to hire me?). Off the back of that I’ve been brushing up on the kinds of skills that I might be asked to showcase in any kind of “tech test”.

Not the kind of stuff I can do with one hand tied behind my back¹, but the things for which I’d enjoy feeling a little more-confident². Stuff that’s on my CV that I’ve done and can do, but where I’d like to check before somebody asks me about it in an interview.

React? Sure, I can do that…

LinkedIn, GlassDoor, and bits of the Fediverse are a gold mine for the kinds of things that people are being asked to demonstrate in tech tests these days. Like this post:

On LinkedIn, Avantika Raj shares a coding question asked during their React Developer interview with Volkswagon Software Solutions. It reads: Create a traffic light component with green, yellow, and red lights. On clicking a button, the light should change. Initially, it should show green. After 2 minutes, it should automatically switch to red for 30 seconds, then yellow for 10 seconds, and repeat this cycle continuously. — I’d describe myself as a “stack-agnostic senior/principal full-stack/backend web developer/security engineer”³, and so this question – which feels like it’s a filter for a junior developer with a React specialisation – isn’t really my wheelhouse. Which makes it a perfect excuse for an hour of playing about with React.

My recent React experience has mostly involved Gutenberg blocks and WordPress theme component. This seemed like an excuse to check that I can wrangle a non-WordPress React stack.

Animated GIF showing traffic lights changing through their phases on-demand or on a toggleable timer. — This isn’t particularly sophisticated. I added customisable durations for each light, but otherwise it’s pretty basic.

Half an hour later, I’d proven to myself that yes, I could throw together a fresh application with React DOM and implement some React components, pass state around and whatnot.

Time to move on to the next thing, right? That’s what a normal person would do.

But that’s not the kind of person I am.

Let’s reimplement this as Web Components

What I found myself thinking was… man, this is chunky. React is… not the right tool for this job.

(Or, increasingly, any job. But I’ll get back to that.)

A minified production build of my new component and its dependencies came in at 202kB (62.3kB compressed). That feels pretty massive for something that does so-little. So as an experiment, I re-implemented my new React component as a vanilla JS Web Component using a custom element. Identical functionality, but no third-party library dependencies. Here’s what I got:

This one’s interactive. Press a button or two!

The Web Component version of this control has no dependency chain and uses no JSX, and so it has no transpilation step: the source version is production-ready. You could minify it, but modern HTTP compression makes the impact of that negligible anyway: the whole thing weighs in at 19.5kB (5.2kB compressed) without minification.

And while I appreciate of course that there’s much more to JavaScript complexity and performance than file sizes… and beyond that I appreciate that there’s a lot more to making great components than the resulting bundle size… it’s hard to argue that delivering the same functionality (and less fragility) in a twelfth of the payload isn’t significant.

But there’s a bigger point here:

React is the new jQuery

I’m alarmed by the fact that I’m still seeing job ads for “React developers”, with little more requirement than an ability to “implement things in React”.

From where I’m sitting, React is the new jQuery. It:

Was originally built to work around missing or underdeveloped JavaScript functionality
- e.g. React’s components prior to Web Components
- e.g. jQuery’s manipulation prior to document.querySelectorAll
Continued to be valuable as a polyfill and as a standard middleware while that functionality become commonplace
- e.g. React before Web Components became more standardised around 2018
- e.g. jQuery’s $.ajax until the Fetch API was a reliable replacement to XMLHttpRequest
No longer provides enough value to be worth using in a new project
- And yet somehow gets added “out of habit” for many years

If you’ve got a legacy codebase with lots of React in it, you’re still going to need React for a while. Just like how you’re likely to continue to need jQuery for a while until you can tidy up all those edge-cases where you’re using it.

(You might even be locked-in to using both React and jQuery for some time, if say you’ve got a plugin architecture that demands backwards-compatibility: I’m looking at you, WordPress!)

But just as you’re already (hopefully) working to slowly extricate your codebases from any now-unnecessary jQuery dependencies they have… you should be working on an exit plan for your React code, too. It’s done its time; it’s served its purpose: now it’s just a redundant dependency making your bundles cumbersome and harder to debug.

Everything React gives you on the client-side – components, state/hooks, routing⁴, etc. – is possible (and easy) in modern JavaScript supported in all major browsers. And if you still really want an abstraction layer, there are plenty of options (and they’re all a lot lighter than React!).

The bottom line is, I suppose…

You shouldn’t be hiring “React developers”!

If you’re building a brand new project, you shouldn’t be using React. It should be considered deprecated.

If you’ve got an existing product that depends on React… you should be thinking about how you’ll phase it out over time. And with that in mind, you want to be hiring versatile developers. They’ll benefit from some experience with React, sure, but unless they can also implement for the modern Web of tomorrow, they’ll just code you deeper into your dependency on React.

It’s time you started recruiting “Front-End Developers (React experience a plus)”. Show some long-term thinking! Or else the Web is going to move on without you, and in 5-10 years you’ll struggle to recruit people to maintain your crumbling stack.

You can download all my code and try it for yourself, if you like. The README has lots more information/spicy rants, and the whole thing’s under a public domain license so you can do whatever you like with it.

Footnotes

¹ Exploiting or patching an injection vulnerability, optimising an SQL query, implementing a WordPress plugin, constructing a CircleCI buildchain, expanding test coverage over a Rubygem, performing an accessibility audit of a web application, extending a set of high-performance PHP-backed REST endpoints, etc. are all – I’d hope! – firmly in the “hold my beer” category of tech test skills I’d ace, for example. But no two tech stacks are exactly alike, so it’s possible that I’ll want to brush up on some of the adjacent technologies that are in the “I can do it, but I might need to hit the docs pages” category.

² It’s actually refreshing to be learning and revising! I’ve long held that I should learn a new programming language or framework every year or two to stay fresh and to keep abreast of what’s going on in world. I can’t keep up with every single new front-end JavaScript framework any more (and I’m not sure I’d want to!)! But in the same way as being multilingual helps unlock pathways to more-creative thought and expression even if you’re only working in your native tongue, learning new programming languages gives you a more-objective appreciation of the strengths and weaknesses of what you use day-to-day. tl;dr: if you haven’t written anything in a “new” (to you) programming language for over a year, you probably should.

³ What do job titles even mean, any more? 😂 A problem I increasingly find is that I don’t know how to describe what I do, because with 25+ years of building stuff for the Web, I can use (and have used!) most of the popular stacks, and could probably learn a new one without too much difficulty. Did I mention I’m thinking about my next role? If you think we might “click”, I’d love to hear from you…

⁴ Though if you’re doing routing only on the client-side, I already hate you. Consider for example the SlimJS documentation which becomes completely unusable if a third-party JavaScript CDN fails: that’s pretty fragile!

Note #26282

“I know that losing your job was hard,” my 8-year-old said to me this evening, “So you can borrow this.” He handed me his newest soft toy.

“It’ll help you feel better when you’re sad. Keep him for the week.”

😭

3Camp 2025

I’m off for a week of full-time volunteering with Three Rings at 3Camp, our annual volunteer hack week: bringing together our distributed team for some intensive in-person time, working to make life better for charities around the world.

And if there’s one good thing to come out of me being suddenly and unexpectedly laid-off two days ago, it’s that I’ve got a shiny new laptop to do my voluntary work on (Automattic have said that I can keep it).

Redundant

Apparently Automattic are laying off around one in six of their workforce. And I’m one of the unlucky ones.

Anybody remote hiring for a UK-based full-stack web developer (in a world that doesn’t seem to believe that full-stack developers exist anymore) with 25+ years professional experience, specialising in PHP, Ruby, JS, HTML, CSS, devops, and about 50% of CMSes you’ve ever heard of (and probably some you haven’t)… with a flair for security, accessibility, standards-compliance, performance, and DexEx?

CV at: https://danq.me/cv

Idea: Meeting Spoofer

Focus time is great

I’m a big fan of blocking out uninterrupted time on your work calendar for focus activities, even if you don’t have a specific focus task to fill them with.

It can be enough to simple know that, for example, you’ve got a 2-hour slot every Friday morning that you can dedicate to whatever focus-demanding task you’ve got that week, whether it’s a deep debugging session, self-guided training and development activities, or finally finishing that paper that’s just slightly lower priority than everything else on your plate.

I appreciate that my colleagues respect that blocked period: I almost never receive meeting requests in that time. That’s probably because most people, particularly because we’re in such a multi-timezone company, use their calendar’s “find a suitable time for everybody” tool to find the best time for everyone and it sees that I’m “busy” and doesn’t suggest it.

If somebody does schedule a meeting that clashes with that block then, well, it’s probably pretty urgent!

But it turns out this strategy doesn’t work for everybody:

My partner recently showed me a portion of her calendar, observing that her scheduled focus time had been overshadowed by four subsequently-created meetings that clashed with it. Four!

Maybe that’s an exception and this particular occasion really did call for a stack of back-to-back urgent meetings. Maybe everything was on fire. But whether or not this particular occasion is representative for my partner, I’ve spoken to other friends who express the same experience: if they block out explicit non-meeting time on their calendar, they get meeting requests for that time anyway. At many employers, “focus time” activities don’t seem to be widely-respected.

Maybe your workplace is the same. The correct solution probably involves a cultural shift: a company-wide declaration in favour of focus time as a valuable productivity tool (which it is), possibly coupled with recommendations about how to schedule them sensitively, e.g. perhaps recommending a couple of periods in which they ought to be scheduled.

But for a moment, let’s consider a different option:

A silly solution?

Does your work culture doesn’t respect scheduled focus time but does respect scheduled meetings? This might seem to be the case in the picture above: note that the meetings that clash with the focus time don’t clash with one another but tessellate nicely. Perhaps you need… fake meetings.

Calendar showing (fake) meetings titled "SN / AFU Project Update", "Team ID107 training session", "Biological Interface Error Scheduling Meeting", and "(Rescheduled) ADIH Planning". — “Wow, what a busy afternoon Dan’s got. I’d better leave him be.”

Of course, creating fake meetings just so you can get some work done is actually creating more work. Wouldn’t it be better if there were some kind of service that could do it for you?

Here’s the idea: a web service that exposes an API endpoint. You start by specifying a few things about the calendar you’d like to fill, for example:

What days/times you’d like to fill with “focus time”?
What industry you work in, to help making convincing (but generic) event names?
Whether you’d like the entire block consistently filled, or occasional small-but-useless gaps of up to 15 minutes inserted between them?

This results in a URL containing those parameters. Accessing that URL yields an iCalendar feed containing those meetings. All you need to do is get your calendar software to subscribe to those events and they’ll appear in your calendar, “filling” your time.

So long as your iCalendar feed subscription refreshes often enough, you could even have an option to enable the events to self-delete e.g. 15 minutes before their start time, so that you don’t panic when your meeting notification pops up right before they “start”!

This is the bit where you’re expecting me to tell you I made a thing

Normally, you’d expect me to pull the covers off some hilarious domain name I’ve chosen and reveal exactly the service I describe, but I’m not doing that today. There’s a few reasons for that:

Firstly, I’ve got ~~enough~~ too many pointless personal/side projects on the go already¹. I don’t need another distraction.
Secondly, it turns out others have already done 90% of the work. This open-source project runs locally and fills calendars with (unnamed, private) blocks of varying lengths. This iOS app does almost exactly what I described, albeit in an ad-hoc rather than fully-automated way. There’s no point me just doing the last 10% just to make a joke work.
And thirdly: while I searched for existing tools I discovered a significant number of people who confess online to creating fake meetings in their calendars! While some of these do so for reasons like those I describe – i.e. to block out time and get more work done in an environment that doesn’t respect them simply blocking-out time – a lot of folks admit to doing it just to “look busy”. That could be either the employee slacking off, or perhaps having to work around a manager with a presenteeism/input-measurement based outlook (which is a terrible way to manage people). But either way: it’s a depressing reason to write software.

Nope

So yeah: I’m not going down that avenue.

But maybe if you’re in a field where you’d benefit from it, try blocking out some focus time in your calendar. I think it’s a fantastic idea, and I love that I’m employed somewhere that I can do so and it works out.

Or if you’ve tried that and discovered that your workplace culture doesn’t respect it – if colleagues routinely book meetings into reserved spaces – maybe you should try fake meetings and see if they’re any better-respected. But I’m afraid I can’t help you with that.

Footnotes

¹ Consider, for example, how I’m trying to take a photo of my dog, with her tongue stuck out, every day of this month.

[Bloganuary] Dream Job

This post is part of my attempt at Bloganuary 2024. Today’s prompt is:

What’s your dream job?

It feels like a bit of a cop-out to say I’m already doing it, but that’s true. Well, mostly (read on and I’ll make a counterpoint!).

Automattic

Dan (wearing a rainbow bandana) waves at the camera; behind him are four work colleagues, and behind that the Colosseum in Rome. — Getting to hang out with my awesome teammates in various locations around the globe is a plus.

I’m incredibly fortunate that my job gets to tick so many of the boxes I’d put on a “dream job wishlist”:

I work on things that really matter. Automattic’s products make Web publishing and eCommerce available to the world without “lock-in” or proprietary bullshit. I genuinely believe that Automattic’s work helps to democratise the Internet and acts, in a small way, as a counterbalance to the dominance of the big social media silos.
I get to make the world a better place by giving away as much intellectual property as possible. Automattic’s internal policy is basically “you don’t have to ask to open source something; give away anything you like so long as it’s not the passwords”.¹ Open Source is one of the most powerful ideas of our generation, and all that.
We work in a distributed, asynchronous way. I work from where I want, when I want. I’m given the autonomy to understand what my ideal working environment is and make the most of it. Some mornings I’m just not feeling that coding flow, so I cycle somewhere different and try working the afternoon in a different location. Some weekends I’m struck by inspiration and fire up my work laptop to make the most of it, because, y’know, I’m working on things that really matter and I care about them.
I work with amazing people who I learn from and inspire me. Automattic’s home to some incredibly talented people and I love that I’ve managed to find a place that actively pushes me to study new things every day.
Automattic’s commitment to diversity & inclusion is very good-to-excellent. As well as getting work work alongside people from a hundred different countries and with amazingly different backgrounds, I love that I get to work in one of the queerest and most queer-affirming environments I’ve ever been paid to be in.

Did I mention that we’re hiring?²

Three Rings

Dan sits at a boardroom table in an airy, bright room. He's wearing an Automattic t-shirt that reads "Let's make the Web a better place." In the background, several other people discuss a pile of post-it notes that have begun to pile up on the table. — I don’t know how I managed to select a photo of my fun-loving kickass volunteers that’s somehow more dry and corporate than the photo of my work colleagues above.

But you know where else ticks all of those boxes? My voluntary work with Three Rings. Let me talk you through that wishlist again:

I work on things that really matter. We produce the longest-running volunteer management system in the world³ We produce it as volunteers ourselves, because we believe that volunteering matters and we want to make it as easy as possible for as many people as possible to do as much good as possible, and this allows us to give it away as cheaply as possible: for free, to the smallest and poorest charities.
I get to make the world a better place by facilitating the work of suicide helplines, citizens advice bureaus, child support services, environmental charities, community libraries and similar enterprises, museums, theatres, charity fundraisers, and so many more good works. Back when I used to to helpline volunteering I might do a three hour shift and help one or two people, and I was… okay at it. Now I get to spend those three hours making tools that facilitate many tens of thousands of volunteers to provide services that benefit an even greater number of people across six countries.
We work in a distributed, asynchronous way. Mostly I work from home; sometimes we get together and do things as a team (like in the photo above). Either way, I’m trusted with the autonomy to produce awesome things in the way that works best for me, backed with the help and support of a team that care with all their hearts about what we do.
I work with amazing people who I learn from and inspire me. I mentioned one of them yesterday. But seriously, I could sing the praises of any one of our two-dozen strong team, whether for their commitment to our goals, their dedication to making the world better, their passion for quality and improvement, their focus when producing things that meet our goals, or their commitment to sticking with us for years or decades, without pay, simply because they know that what we do is important and necessary for so many worthy causes. And my fellow development/devops volunteers continue to introduce me to new things, which scratches my “drive-to-learn” itch.
Three Rings’ commitment to diversity & inclusion is very good, and improving. We skew slightly queer and have moderately-diverse gender mix, but I’m especially impressed with our age range these days: there’s at least 50 years between our oldest and youngest volunteers with a reasonably-even spread throughout, which is super cool (and the kind of thing many voluntary organisations dream of!).

The difference

The biggest difference between these two amazing things I get to work on is… only one of them pays me. It’s hard to disregard that.

Sometimes at Automattic, I have to work on something that’s not my favourite project in the world. Or the company’s priorities clash with my own, and I end up implementing something that my gut tells me isn’t the best use of my time from a “make the world a better place” perspective. Occasionally they take a punt on something that really pisses me off.

That’s all okay, of course, because they pay me, and I have a mortgage to settle. That’s fine. That’s part of the deal.

My voluntary work at Three Rings is more… mine. I’m the founder of the project; I 100% believe in what it’s trying to achieve. Even though I’ve worked to undermine the power of my “founder privilege” by entrusting the organisation to a board and exec that I know will push back and challenge me, I feel safe fully trusting that everything I give to Three Rings will be used in the spirit of the original mission. And even though I might sometimes disagree with others on the best way forward, I accept that whatever decision is made comes from a stronger backing than if I’d acted alone.

Three Rings, of course, doesn’t pay me⁴. That’s why I can only give them a few hours a week of my time. If I could give more, I would, but I have bills to pay so my “day job” is important too: I’m just so incredibly fortunate that that “day job” touches upon many of the same drives that are similarly satisfied by my voluntary work.

If I didn’t have bills to pay, I could happily just volunteer for Three Rings. I’d miss Automattic, of course: there are some amazing folks there whom I love very much, and I love the work. But if they paid me as little as Three Rings did – that is, nothing! – I’d choose Three Rings in a heartbeat.

But man, what a privileged position I’m in that I can be asked what my dream job is and I can answer “well, it’s either this thing that I already do, or this other thing that I already do, depending on whether this hypothetical scenario considers money to be a relevant factor.” I’m a lucky, lucky man.

Footnotes

¹ I’m badly-paraphrasing Matt, but you get the gist.

² Automattic’s not hiring as actively nor voraciously as it has been for the last few years – a recent downtown in the tech sector which you may have seen have heavily affected many tech companies has flooded the market with talent, and we’ve managed to take our fill of them – we’re still always interested to hear from people who believe in what we do and have skills that we can make use of. And because we’re a community with a lot of bloggers, you can find plenty of first-hand experiences of our culture online if you’d like to solicit some opinions before you apply…

³ Disclaimer: Three Rings is the oldest still-running volunteer management system we’re aware of: our nearest surviving “competitor”, which provides similar-but-different features for a price that’s an order of magnitude greater, launched later in the same year we started. But maybe somebody else has been running these last 22 years that we haven’t noticed, yet: you never know!

⁴ Assuming you don’t count a Christmas dinner each January – yes, really! (it turns out to be cheaper to celebrate Christmas in January) – as payment.

Magician Roles

Because I work somewhere hip enough to let people tweak their job titles, mine is “Code Magician”.

LinkedIn isn’t as hip as Automattic, though. That’s why they keep emailing me sector updates… for the “Magician” sector… 😅

Announcers and Automation

Duration 4:24

Podcast Version

This post is also available as a podcast. Listen here, download for later, or subscribe wherever you consume podcasts.

Nowadays if you’re on a railway station and hear an announcement, it’s usually a computer stitching together samples¹. But back in the day, there used to be a human with a Tannoy microphone sitting in the back office, telling you about the platform alternations and destinations.

I had a friend who did it as a summer job, once. For years afterwards, he had a party trick that I always quite enjoyed: you’d say the name of a terminus station on a direct line from Preston, e.g. Edinburgh Waverley, and he’d respond in his announcer-voice: “calling at Lancaster, Oxenholme the Lake District, Penrith, Carlisle, Lockerbie, Haymarket, and Edinburgh Waverley”, listing all of the stops on that route. It was a quirky, beautiful, and unusual talent. Amazingly, when he came to re-apply for his job the next summer he didn’t get it, which I always thought was a shame because he clearly deserved it: he could do the job blindfold!

There was a strange transitional period during which we had machines to do these announcements, but they weren’t that bright. Years later I found myself on Haymarket station waiting for the next train after mine had been cancelled, when a robot voice came on to announce a platform alteration: the train to Glasgow would now be departing from platform 2, rather than platform 1. A crowd of people stood up and shuffled their way over the footbridge to the opposite side of the tracks. A minute or so later, a human announcer apologised for the inconvenience but explained that the train would be leaving from platform 1, and to disregard the previous announcement. Between then and the train’s arrival the computer tried twice more to send everybody to the wrong platform, leading to a back-and-forth argument between the machine and the human somewhat reminiscient of the white zone/red zone scene from Airplane! It was funny perhaps only because I wasn’t among the people whose train was in superposition.

Clearly even by then we’d reached the point where the machine was well-established and it was easier to openly argue with it than to dig out the manual and work out how to turn it off. Nowadays it’s probably even moreso, but hopefully they’re less error-prone.

When people talk about how technological unemployment, they focus on the big changes, like how a tipping point with self-driving vehicles might one day revolutionise the haulage industry… along with the social upheaval that comes along with forcing a career change on millions of drivers.

But in the real world, automation and technological change comes in salami slices. Horses and carts were seen alongside the automobile for decades. And you still find stations with human announcers. Even the most radically-disruptive developments don’t revolutionise the world overnight. Change is inevitable, but with preparation, we can be ready for it.

Footnotes

¹ Like ScotRail’s set, voiced by Alison McKay, which computers can even remix for you over a low-fi hiphop beat if you like.

Automattic Privilege

I’ve been thinking recently about three kinds of geographic privilege I enjoy in my work at Automattic. (See more posts about my experience of working at Automattic.)

1. Timezone Privilege

Take a look at the map below. I’m the pink pin here in Oxfordshire. The green pins are my immediate team – the people I work with on a day-to-day basis – and the blue pins are people outside of my immediate team but in its parent team (Automattic’s org chart is a bit like a fractal).

World map showing the locations of Dan, his immediate team, and its parent team. There's a cluster of nine pins Europe, a few pins further East in Russia and Indonesia, one in Cape Town, two in North America, and one in Central America. — I’m the pink pin; my immediate team are the green pins. People elsewhere in our parent team are the blue pins. Some pins represent multiple people.

Thinking about timezones, there are two big benefits to being where I am:

I’m in the median timezone, which makes times that are suitable-for-everybody pretty convenient for me (I have a lot of lunchtime/early-afternoon meetings where I get to watch the sun rise and set, simultaneously, through my teammates’ windows).
I’m West of the mean timezone, which means that most of my immediate coworkers start their day before me so I’m unlikely to start my day blocked by anything I’m waiting on.

(Of course, this privilege is in itself a side-effect of living close to the meridian, whose arbitrary location owes a lot to British naval and political clout in the 19th century: had France and Latin American countries gotten their way the prime median would have probably cut through the Atlantic or Pacific oceans.)

2. Language Privilege

English is Automattic’s first language (followed perhaps by PHP and Javascript!), not one of the 120 other languages spoken by Automatticians. That’s somewhat a consequence of the first language of its founders and the language in which the keywords of most programming languages occur.

It’s also a side-effect of how widely English is spoken, which in comes from (a) British colonialism and (b) the USA using Hollywood etc. to try to score a cultural victory.

Treemap showing languages spoken by Automatticians: English dominates, followed by Spanish, French, German, Italian, Hindi, Portugese, Mandarin, Russian, Japanese, Polish, Afrikaans, Dutch, Green, Catalan, Cantonese, Romanian, and many others. — Languages self-reportedly spoken by Automatticians, sized proportional to the number of speakers. No interpretation/filtering has been done, so you’ll see multiple dialects of the same root language.

I’ve long been a fan of the concept of an international axillary language but I appreciate that’s an idealistic dream whose war has probably already been lost.

For now, then, I benefit from being able to think, speak, and write in my first language all day, every day, and not have the experience of e.g. my two Indonesian colleagues who routinely speak English to one another rather than their shared tongue, just for the benefit of the rest of us in the room!

3. Passport Privilege

Despite the efforts of my government these last few years to isolate us from the world stage, a British passport holds an incredible amount of power, ranking fifth or sixth in the world depending on whose passport index you follow. Compared to many of my colleagues, I can enjoy visa-free and/or low-effort travel to a wider diversity of destinations.

Normally I might show you a map here, but everything’s a bit screwed by COVID-19, which still bars me from travelling to many places around the globe, but as restrictions start to lift my team have begun talking about our next in-person meetup, something we haven’t done since I first started when I met up with my colleagues in Cape Town and got assaulted by a penguin.

But even looking back to that trip, I recall the difficulties faced by colleagues who e.g. had to travel to a different country in order tom find an embassy just to apply for the visa they’d eventually need to travel to the meetup destination. If you’re not a holder of a privileged passport, international travel can be a lot harder, and I’ve definitely taken that for granted in the past.

I’m going to try to be more conscious of these privileges in my industry.

Automattic Retrospective (days 207 to 334)

Last year, I accepted a job offer with Automattic and I’ve been writing about it every 128 days. I’ve talked about my recruitment, induction, and experience of lockdown (which in turn inspired a post about the future of work). I’ve even helped enthuse other new Automatticians! Since my last post I’ve moved house so my home office has changed shape, but I’m still plodding along as always… and fast-approaching my first “Automattic birthday”! (This post ran a little late; the 128-day block was three weeks ago!)

Dan in his home office (links to an interactive 360° panoramic photo with info points). — If you missed it the first time around, click through to explore an interactive panoramic view of my workspace. It’s slightly more “unpacked” now.

As I approach my first full year as an Automattician, I find myself looking back on everything I’ve learned… but also looking around at all the things I still don’t understand! I’m not learning something new every day any more… but I’m still learning something new most weeks.

This summer I’ve been getting up-close and personal with Gutenberg components. I’d mostly managed to avoid learning the React (eww; JSX, bad documentation, and an elephantine payload…) necessary to hack Gutenberg, but in helping to implement new tools for WooCommerce.com I’ve discovered that it’s… not quite as painful as I’d thought. There are even some bits I quite like. But I don’t expect to fall in love with React any time soon. This autumn I’ve been mostly working on search and personalisation, integrating customer analytics data with our marketplace to help understand what people look for on our sites and using that to guide their future experience (and that of others “like” them). There’s always something new.

My team continues to grow, with two newmatticians this month and a third starting in January. In fact, my team’s planning to fork into two closely-linked subteams; one with a focus on customers and vendors, the other geared towards infrastructure. It’s exciting to see my role grow and change, but I worry about the risk of gradually pigeon-holing myself into an increasingly narrow specialisation. Which wouldn’t suit me: I like to keep a finger in all the pies. Still; my manager’s reassuring that this isn’t likely to be the case and our plans are going in the “right” direction.

On the side of my various project work, I’ve occasionally found the opportunity for more-creative things. Last month, I did some data-mining over the company’s “kudos” history of the last five years and ran it through vis.js to try to find a new angle on understanding how Automattic’s staff, teams, and divisions interact with one another. It lead to some interesting results: panning through time, for example, you can see the separate island of Tumblr staff who joined us during the acquisition gradually become more-interconnected with the rest of the organisation over the course of the last year.

The biggest disappointment of my time at Automattic so far was that I’ve not managed to go to a GM! The 2019 one – which looked awesome – took place only a couple of weeks before my contract started (despite my best efforts to wrangle my contract dates with the Bodleian and Automattic to try to work around that), but people reassured me that it was okay because I’d make it to the next one. Well.. 2020 makes fools of us all, I guess, because of course there’s no in-person GM this year. Maybe, hopefully, if and when the world goes back to normal I’ll get to spend time in-person with my colleagues once in a while… but for now, we’re having to suffice with Internet-based socialisation only, just like the rest of the world.

Future Challenges for Remote Working

When the COVID-19 lockdown forced many offices to close and their staff to work remotely, some of us saw what was unfolding as an… opportunity in disguise. Instead of the slow-but-steady decentralisation of work that’s very slowly become possible (technically, administratively, and politically) over the last 50 years, suddenly a torrent of people were discovering that remote working can work.

Man in sci-fi jumpsuit and futuristic AR goggles. — Unfulfilled promises of the world of tomorrow include flying cars, viable fusion power, accessible space travel, post-scarcity economies, and – until recently – widespread teleworking. Still waiting on my holodeck too.

The Future is Now

As much as I hate to be part of the “where’s my flying car?” brigade, I wrote ten years ago about my dissatisfaction that remote working wasn’t yet commonplace, let alone mainstream. I recalled a book I’d read as a child in the 1980s that promised a then-future 2020 of:

near-universal automation of manual labour as machines become capable of an increasing diversity of human endeavours (we’re getting there, but slowly),
a three- or four-day work week becoming typical as efficiency improvements are reinvested in the interests of humans rather than of corporations (we might have lost sight of that goal along the way, although there’s been some fresh interest in it lately), and
widespread “teleworking”/”telecommuting”, as white-collar sectors grow and improvements in computing and telecommunications facilitate the “anywhere office”

Of those three dreams, the third soon seemed like it would become the most-immediate. Revolutionary advances in mobile telephony, miniaturisation of computers, and broadband networking ran way ahead of the developments in AI that might precipitate the first dream… or the sociological shift required for the second. But still… progress was slow.

At eight years old, I genuinely believed that most of my working life would be spent… wherever I happened to be. So far, most of my working life has been spent in an office, despite personally working quite hard for that not to be the case!

Driver's temperature being checked at the roadside by somebody in full protective equipment. — Apply directly to the head! Commuting looks different today than it did last year, but at least the roads are quieter.

I started at Automattic six months ago, an entirely distributed company. And so when friends and colleagues found themselves required to work remotely by the lockdown they came in droves to me for advice about how to do it! I was, of course, happy to help where I could: questions often covered running meetings and projects, maintaining morale, measuring output, and facilitating communication… and usually I think I gave good answers. Sometimes, though, the answer was “If you’re going to make that change, you’re going to need a cultural shift and some infrastructure investment first.” Y’know: “Don’t start from here.” If you received that advice from me: sorry!

(Incidentally, if you have a question I haven’t answered yet, try these clever people first for even better answers!)

More-recently, I was excited to see that many companies have adopted this “new normal” not as a temporary measure, but as a possible shape of things to come. Facebook, Twitter, Shopify, Square, and Spotify have all announced that they’re going to permit or encourage remote work as standard, even after the crisis is over.

Obviously tech companies are leading the way, here: not only are they most-likely to have the infrastructure and culture already in place to support this kind of shift. Also, they’re often competing for the same pool of talent and need to be seen as at-least as progressive as their direct rivals. Matt Mullenweg observes that:

What’s going to be newsworthy by the end of the year is not technology companies saying they’re embracing distributed work, but those that aren’t.

…some employers trapped in the past will force people to go to offices, but the illusion that the office was about work will be shattered forever, and companies that hold on to that legacy will be replaced by companies who embrace the antifragile nature of distributed organizations.

Distributed Work's Five Levels of Autonomy, by Matt Mullenweg. — I’ve shared this before, I know, but it exudes Matt’s enthusiasm for distributed work so well that I’m sharing it again. Plus, some of the challenges I describe below map nicely to the borders between some of

Tomorrow’s Challenges

We’re all acutely familiar with the challenges companies are faced with today as they adapt to a remote-first environment. I’m more interested in the challenges that they might face in the future, as they attempt to continue to use a distributed workforce as the pandemic recedes. It’s easy to make the mistake of assuming that what many people are doing today is a rehearsal for the future of work, but the future will look different.

Some people, of course, prefer to spend some or all of their work hours in an office environment. Of the companies that went remote-first during the lockdown and now plan to stay that way indefinitely, some will lose employees who preferred the “old way”. For this and other reasons, some companies will retain their offices and go remote-optional, allowing flexible teleworking, and this has it’s own pitfalls:

Some remote-optional offices have an inherent bias towards in-person staff. In some companies with a mixture of in-person and remote staff, remote workers don’t get included in ad-hoc discussions, or don’t become part of the in-person social circles. They get overlooked for projects or promotions, or treated as second-class citizens. It’s easy to do this completely by accident and create a two-tiered system, which can lead to a cascade effect that eventually collapses the “optional” aspect of remote-optional; nowhere was this more visible that in Yahoo!’s backslide against remote-optional working in 2013.
Some remote-optional offices retain an archaic view on presenteeism and “core hours”. Does the routine you keep really matter? Remote-first working demands that productivity is measured by output, not by attendance, but management-by-attendance is (sadly) easier to implement, and some high-profile organisations favour this lazy but less-effective approach. It’s easy, but ineffective, for a remote-optional company to simply extend hours-counting performance metrics to their remote staff. Instead, allowing your staff (insofar as is possible) to work the hours that suit them as individuals opens up your hiring pool to a huge number of groups whom you might not otherwise reach (like single parents, carers, digital nomads, and international applicants) and helps you to get the best out of every one of them, whether they’re an early bird, a night owl, or somebody who’s most-productive after their siesta!
Pastoral care doesn’t stop being important after the crisis is over. Many companies that went remote-first for the coronavirus crisis have done an excellent job of being supportive and caring towards their employees (who, of course, are also victims of the crisis: by now, is there anybody whose life hasn’t been impacted?). But when these companies later go remote-optional, it’ll be easy for them to regress to their old patterns. They’ll start monitoring the wellbeing only of those right in front of them. Remote working is already challenging, but it can be made much harder if your company culture makes it hard to take a sick day, seek support on a HR issue, or make small-talk with a colleague.

Teleworker dressed from the waist up. — On the Internet, nobody knows that you’re only properly-dressed from the waist up. No, wait: as of 2020, *everybody* knows that. Let’s just all collectively own it, ‘k.

These are challenges specifically for companies that go permanently remote-optional following a period of remote-first during the coronavirus crisis.

Towards a Post-Lockdown Remote-Optional Workplace

How you face those challenges will vary for every company and industry, but it seems to me that there are five lessons a company can learn as it adapts to remote-optional work in a post-lockdown world:

Measure impact, not input. You can’t effectively manage a remote team by headcount or closely tracking hours; you need to track outputs (what is produced), not inputs (person-hours). If your outputs aren’t measurable, make them measurable, to paraphrase probably-not-Galileo. Find metrics you can work with and rely on, keep them transparent and open, and re-evaluate often. Use the same metrics for in-office and remote workers.
Level the playing field. Learn to spot the biases you create. Do the in-person attendees do all the talking at your semi-remote meetings? Do your remote workers have to “call in” to access information only stored on-site (including in individual’s heads)? When they’re small, these biases have a huge impact on productivity and morale. If they get big, they collapse your remote-optional environment.
Always think bigger. You’re already committing to a shakeup, dragging your company from the 2020 of the real world into the 2020 we once dreamed of. Can you go further? Can you let your staff pick their own hours? Or workdays? Can your staff work in other countries? Can you switch some of your synchronous communications channels (e.g. meetings) into asynchronous information streams (chat, blogs, etc.)? Which of your telecommunications tools serve you, and which do you serve?
Remember the human. Your remote workers aren’t faceless (pantsless) interchangeable components in your corporate machine. Foster interpersonal relationships and don’t let technology sever the interpersonal links between your staff. Encourage and facilitate (optional, but awesome) opportunities for networking and connection. Don’t forget to get together in-person sometimes: we’re a pack animal, and we form tribes more-easily when we can see one another.
Support people through the change. Remote working requires a particular skillset; provide tools to help your staff adapt to it. Make training and development options available to in-office staff too: encourage as flexible a working environment as your industry permits. Succeed, and your best staff will pay you back in productivity and loyalty. Fail, and your best staff will leave you for your competitors.

I’m less-optimistic than Matt that effective distributed working is the inexorable future of work. But out of the ashes of the coronavirus crisis will come its best chance yet, and I know that there’ll be companies who get left behind in the dust. What are you doing to make sure your company isn’t one of them?

Automattic Lockdown (days 79 to 206)

Since I accepted a job offer with Automattic last summer I’ve been writing about my experience on a nice, round 128-day schedule. My first post described my application and recruitment process; my second post covered my induction, my initial two weeks working alongside the Happiness team (tech support), and my first month in my role. This is the third post, running through to the end of six and a half months as an Automattician.

Always Be Deploying

One of the things that’s quite striking about working on many of Automattic’s products, compared to places I’ve worked before, is the velocity. Their continuous integration game is pretty spectacular. We’re not talking “move fast and break things” iteration speeds (thank heavens), but we’re still talking fast.

Graph showing Automattic deployments for a typical week. Two of the 144 deployments on Monday were by Dan. — Deployments-per-day in a reasonably typical week. A minor bug slipped through in the first of the deployments I pushed on the Monday shown, so it was swiftly followed by a second deployment (no external end-users were affected: phew!).

My team tackles a constant stream of improvements in two-week sprints, with every third sprint being a cool-down period to focus on refactoring, technical debt, quick wins, and the like. Periodic HACK weeks – where HACK is (since 2018) a backronym for Helpful Acts in Customer Kindness – facilitate focussed efforts on improving our ecosystem and user experiences.

I’m working in a larger immediate team than I had for most of my pre-Automattic career. I’m working alongside nine other developers, typically in groups of two to four depending on the needs of whatever project I’m on. There’s a great deal of individual autonomy: we’re all part of a greater whole and we’re all pushing in the same direction, but outside of the requirements of the strategic goals of our division, the team’s tactical operations are very-much devolved and consensus-driven. We work out as a team how to solve the gnarly (and fun!) problems, how to make best use of our skills, how to share our knowledge, and how to schedule our priorities.

This team-level experience echoes the experience of being an individual at Automattic, too. The level of individual responsibility and autonomy we enjoy is similar to that I’ve seen only after accruing a couple of years of experience and authority at most other places I’ve worked. It’s amazing to see that you can give a large group of people so much self-controlled direction… and somehow get order out of the chaos. More than elsewhere, management is more to do with shepherding people into moving in the same direction than it is about dictating how the ultimate strategic goals might be achieved.

Na na na na na na na na VAT MAN!

Somewhere along the way, I somehow became my team’s live-in expert on tax. You know how it is: you solve a bug with VAT calculation in Europe… then you help roll out changes to support registration with the GST in Australia… and then one day you find yourself reading Mexican digital services tax legislation and you can’t remember where the transition was from being a general full-stack developer to having a specialisation in tax.

An Oxford coworking space. — Before the coronavirus lockdown, though, I’d sometimes find a coworking space (or cafe, or pub!) to chill in while I worked. This one was quiet on the day I took the photo.

Tax isn’t a major part of my work. But it’s definitely reached a point at which I’m a go-to figure. A week or so ago when somebody had a question about the application of sales taxes to purchases on the WooCommerce.com extensions store, their first thought was “I’ll ask Dan!” There’s something I wouldn’t have anticipated, six month ago.

Automattic’s culture lends itself to this kind of selective micro-specialisation. The company actively encourages staff to keep learning new things but mostly without providing a specific direction, and this – along with their tendency to attract folks who, like me, could foster an interest in almost any new topic so long as they’re learning something – means that my colleagues and I always seem to be developing some new skill or other.

I ended up posting this picture to my team’s internal workspace, this week, as I looked a VAT-related calculation.

I know off the top of my head who I’d talk to about if I had a question about headless browser automation, or database index performance, or email marketing impact assessment, or queer representation, or getting the best airline fares, or whatever else. And if I didn’t, I could probably find them. None of their job descriptions mention that aspect of their work. They’re just the kind of people who, when they see a problem, try to deepen their understanding of it as a whole rather than just solving it for today.

A lack of pigeonholing, coupled with the kind of information management that comes out of being an entirely-distributed company, means that the specialisation of individuals becomes a Search-Don’t-Sort problem. You don’t necessarily find an internal specialist by their job title: you’re more-likely to find them by looking for previous work on particular topics. That feels pretty dynamic and exciting… although it does necessarily lead to occasional moments of temporary panic when you discover that something important (but short of mission-critical) doesn’t actually have anybody directly responsible for it.

Crisis response

No examination of somebody’s first 6+ months at a new company, covering Spring 2020, would be complete without mention of that company’s response to the coronavirus crisis. Because, let’s face it, that’s what everybody’s talking about everywhere right now.

Dan in a video meeting, in a hammock. — All workplace meetings should be done this way.

In many ways, Automattic is better-placed than most companies to weather the situation. What, we have to work from home now? Hold my beer. Got to shift your hours around childcare and other obligations? Sit down, let us show you how it’s done. Need time off for COVID-related reasons? We already have an open leave policy in place and it’s great, thanks.

As the UK’s lockdown (eventually) took hold I found myself treated within my social circle like some kind of expert on remote working. My inboxes filled up with queries from friends… How do I measure output? How do I run a productive meeting? How do I maintain morale? I tried to help, but unfortunately some of my answers relied slightly on already having a distributed culture: having the information and resource management and teleworking infrastructure in-place before the crisis. Still, I’m optimistic that companies will come out of the other side of this situation with a better idea about how to plan for and execute remote working strategies.

I’ve been quite impressed that even though Automattic’s all sorted for how work carries on through this crisis, we’ve gone a step further and tried to organise (remote) events for people who might be feeling more-isolated as a result of the various lockdowns around the world. I’ve seen mention of wine tasting events, toddler groups, guided meditation sessions, yoga clubs, and even a virtual dog park (?), all of which try to leverage the company’s existing distributed infrastructure to support employees who’re affected by the pandemic. That’s pretty cute.

(It might also have provided some inspiration for the murder mystery party I plan to run a week on Saturday…)

In summary: Automattic’s still proving to be an adventure, I’m still loving their quirky and chaotic culture and the opportunity to learn something new every week, and while their response to the coronavirus crisis has been as solid as you’d expect from a fully-distributed company I’ve also been impressed by the company’s efforts to support staff (in a huge diversity of situations across many different countries) through it.

Getting Hired at Automattic

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I started at Automattic on November 20, 2019, and it’s an incredible place to work. I’m constantly impressed by my coworkers kindness, intelligence, and compassion. If you’re looking for a rewarding remote job that you can work from anywhere in the world, definitely apply.

I’m still overjoyed and amazed I was hired. While going through the hiring process, I devoured the blog posts from people describing their journeys. Here’s my contribution to the catalog. I hope it helps someone.

…

Jerry Jones

I’ve written about my own experience of Automattic’s hiring process and how awesome it is, but if you’re looking for a more-concise summary of what to expect from applying to and interviewing for a position, this is pretty great.

Contents

The Test

The Theory

Simple case with O(n) complexity

Achieving O(1) time complexity

The Implementation

What did I learn?

Lesson #1: programming more languages can make you better at all of them

Lesson #2: even when I’m rusty, I can rely on my fundamentals

Lesson #3: structural rules are harder to gearshift than syntactic ones

Okay, time for a new job

Footnotes

React? Sure, I can do that…

Let’s reimplement this as Web Components

React is the new jQuery

You shouldn’t be hiring “React developers”!

Footnotes

Focus time is great

A silly solution?

This is the bit where you’re expecting me to tell you I made a thing

Nope

Footnotes

Automattic

Three Rings

The difference

Footnotes

Podcast Version

Footnotes

1. Timezone Privilege

2. Language Privilege

3. Passport Privilege

The Future is Now

Tomorrow’s Challenges

Towards a Post-Lockdown Remote-Optional Workplace

Always Be Deploying

Na na na na na na na na VAT MAN!

Crisis response