In my first few weeks at my new employer, my code contributions have added 218 lines of code, deleted 2,663. Only one of my PRs has resulted in a net increase in the size of their codebases (by two lines).
I need to pick up the pace if I’m going to reach the ultimate goal of deleting ALL of the code within my lifetime. (That’s the ultimate aim, right?)
My new employer sent me a laptop and a monitor, which I immediately added to my already pretty-heavily-loaded desk. Wanna see?
Off to my first day at Firstup. Gotta have an induction: get my ID badge, learn where the toilets are, how to refill the coffee machine, and all that jazz.
Except, of course, none of those steps will be part of my induction. Because, yet again, I’ve taken a remote-first position. I’m 100% sold that, for me, remote/distributed work helps me bring my most-productive self. It might not be for everybody, but it’s great for me.
And now: I’m going to find out where the water cooler is. No, wait… some other thing!
In a little over a week I’ll be starting my new role at Firstup, who use some of my favourite Web technologies to deliver tools that streamline employee communication and engagement.
I’m sure there’ll be more to say about that down the line, but for now: let’s look at my recruitment experience, because it’s probably the fastest and most-streamlined technical recruitment process I’ve ever experienced! Here’s the timeline:
With only eight days between the screener interview and the offer – and barely a fortnight after my initial application – this has got to be the absolute fastest I’ve ever seen a tech role recruitment process go. It felt like a rollercoaster, and I loved it.
1 The earliest available slot for a screener interview, on Tuesday, clashed with my 8-year-old’s taekwondo class which I’d promised I’ll go along and join in with it as part of their “dads train free in June” promotion. This turned out to be a painful and exhausting experience which I thoroughly enjoyed, but more on that some other time, perhaps.
2 After realising that “are you a robot” was part of the initial checks, I briefly regretted taking the interview in our newly-constructed library because it provides exactly the kind of environment that looks like a fake background.
I’ve been in a lot of interviews over the last two or three weeks. But there’s a moment that stands out and that I’ll remember forever as the most-smug I’ve ever felt during an interview.
This particular interview included a mixture of technical and non-technical questions, but a particular technical question stood out for reasons that will rapidly become apparent. It went kind-of like this:
Interviewer: How would you go about designing a backend cache that retains in memory some number of most-recently-accessed items?
Dan: It sounds like you’re talking about an LRU cache. Coincidentally, I implemented exactly that just the other week, for fun, in two of this role’s preferred programming languages (and four other languages). I wrote a blog post about my design choices: specifically, why I opted for a hashmap for quick reads and a doubly-linked-list for constant-time writes. I’m sending you the links to it now: may I talk you through the diagrams?
Interviewer:
That’s probably the most-overconfident thing I’ve said at an interview since before I started at the Bodleian, 13 years ago. In the interview for that position I spent some time explaining that for the role they were recruiting for they were asking the wrong questions! I provided some better questions that I felt they should ask to maximise their chance of getting the best candidate… and then answered them, effectively helping to write my own interview.
Anyway: even ignoring my cockiness, my interview the other week was informative and enjoyable throughout, and I’m pleased that I’ll soon be working alongside some of the people that I met: they seem smart, and driven, and focussed, and it looks like the kind of environment in which I could do well.
But more on that later.
This is a repost promoting content originally published elsewhere. See more things Dan's reposted.
When I posted to LinkedIn about my recent redundancy, I saw a tidal wave of reposts and well-wishes. But there’s one that I’ve come back to whenever I need a pick-me-up before I, y’know, trawl the job boards: a comment-repost by my big-hearted, sharp-minded former co-worker Kyle. I’m posting it here because I want to keep a copy forever1:
Bad news: I’m among the sixth of Automattic that’s been laid-off this week.
Good news: I’m #OpenToWork, and excited about the opportunity to bring my unique skillset to a new role. Could I be the Senior Software Engineer, Full-Stack Web Developer, or Technical Lead that you’re looking for?
Here’s what makes me special:
🕸️ 26+ years experience of backend and frontend development, with a focus on standards, accessibility, performance, security, and the open Web
🌎 20+ years experience of working in and leading remote/distributed teams in a diversity of sectors
👨💻 Professional experience of many of the technologies you’ve heard of (PHP, Ruby, Java, Perl, SQL, Go, DevOps, JS, jamstacks, headless…), and probably some you haven’t…
👨🎓 Degrees and other qualifications spanning computer science and software engineering, psychotherapy, ethical hacking, and digital forensics (I don’t believe there’s a career in the world that makes use of all of these, but if you know differently, tell me!)If this man isn’t hired immediately, it’s a huge loss. Dan is easily one of the most talented engineers I’ve ever met. His skills are endless, his personal culture is delightful, and I don’t think I went a day working with him where I didn’t learn something. Let him build you beautiful things. I dare you.
Incidentally, Kyle’s looking for a new role too. If you’re in need of a WordPress/PHP/React pro with a focus on delivering the MVP fast and keeping the customer’s needs front-and-centre, you should look him up. He’s based in Cape Town but he’s a remote/distributed veteran that you could slot into your Web team anywhere.
I was updating my CV earlier this week in anticipation of applying for a handful of interesting-looking roles1 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 lie2. Let’s find out!
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
putinto the cache, along with a retrieval key in the form of a string. Using the same string, you cangetthe objects back.- If a
putoperation would increase the number of objects in the cache beyond the size limit, the cached object that was least-recently accessed (by either aputorgetoperation) 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
getandputoperations 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 simplest way to implement such a cache might be as follows:
get, iterate through the list to try to find the matching item.
put, first check if it already exists in the list as with get:
The problem with this approach is that it fails the requirement that the methods “should resolve within constant (O(1)) time”3.
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 4. Let’s try another design:
Here’s another way to implement the cache:
get, check the hash map to see if the item exists.
put, check the hash map to see if the item exists.
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
tail at the tail item’s prev, and
unlink the expired tail item from the new tail item’s next.
prev and next to find its siblings and link them to one another (removes the item from the list).
next to the current head, and the current head‘s prev to the promoted item.
head of the list at the promoted item.
It’s important to realise that this alternative implementation isn’t better. It’s just different: the “right” solution depends on the use-case5.
That’s enough analysis and design. Time to write some code.
Picking a handful of the more-useful languages on my CV6, I opted to implement in:
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!
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 another7.
And there’s a few takeaways I got from this experience –
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 Ruby8, TypeScript9, and Python10, respectively.
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 was11.
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.:
#-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?12
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?
1 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.
2 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.
3 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.
4 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?
5 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.
6 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!
7 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?
8 Ruby’s safe navigation/”lonely” operator did the same thing as PHP’s nullsafe operator since 2015.
9 TypeScript got union types back in 2015, and apart from them being more-strictly-enforced they’re basically identical to PHP’s.
10 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?
11 The feature was the three-way comparison or “spaceship operator”, in case you were wondering.
12 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!
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!
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 back1, but the things for which I’d enjoy feeling a little more-confident2. 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.
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:
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.
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.
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:
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:
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:
document.querySelectorAll
$.ajax until the Fetch API was a reliable replacement to XMLHttpRequest
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, routing4, 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…
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.
1 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.
2 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.
3 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…
4 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!
“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.”
😭
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
A couple of weeks ago, I kicked off my first sabbatical since starting at Automattic a little over five years ago1.
The first fortnight of my sabbatical has consisted of:
The trip to Spain followed a model for European family breaks that we first tried in Paris last year2, but was extended to give us a feel for more of the region than a simple city break would. Ultimately, we ended up in three separate locations:
I’d known – planned – that my sabbatical would involve a little travel. But it wasn’t until we began to approach the end of this holiday that I noticed a difference that a holiday on sabbatical introduces, compared to any other holiday I’ve taken during my adult life…
Perhaps because of the roles I’ve been appointed to – or maybe as a result of my personality – I’ve typically found that my enjoyment of the last day or two of a week-long trip are marred somewhat by intrusive thoughts of the work week to follow.
If I’m back to my normal day job on Monday, then by Saturday I’m already thinking about what I’ll need to be working on (in my case, it’s usually whatever I left unfinished right before I left), contemplating logging-in to work to check my email or Slack, and so on5.
But this weekend, that wasn’t even an option. I’ve consciously and deliberately cut myself off from my usual channels of work communication, and I’ve been very disciplined about not turning any of them back on. And even if I did… my team aren’t expecting me to sign into work for about another 11 weeks anyway!
Monday and Tuesday are going to mostly be split between looking after the children, and voluntary work for Three Rings (gotta fix that new server architecture!). Probably. Wednesday? Who knows.
That’s my first taste of the magic of a sabbatical, I think. The observation that it’s possible to unplug from my work life and, y’know, not start thinking about it right away again.
Maybe I can use this as a vehicle to a more healthy work/life balance next year.
1 A sabbatical is a perk offered to Automatticians giving them three months off (with full pay and benefits) after each five years of work. Mine coincidentally came hot on the tail of my last meetup and soon after a whole lot of drama and a major shake-up, so it was a very welcome time to take a break… although of course it’s been impossible to completely detach from bits of the drama that have spilled out onto the open Web!
2 I didn’t get around to writing about Paris, but I did write about how the hotel we stayed at introduced our eldest, and by proxy re-introduced me, to Wonder Boy, ultimately leading to me building an arcade cabinet on which I finally, beat the game, 35 years after first playing it.
3 Whose construction has come on a lot since the last time I toured inside it.
4 Although alcohol helped with that.
5 I’m fully aware that this is a symptom of poor work/life balance, but I’ve got two decades of ingrained bad habits working against me now; don’t expect me to change overnight!
My employer Automattic‘s having a bit of a reorganisation. For unrelated reasons, this coincides with my superteam having a bit of a reorganisation, too, and I’m going to be on a different team next week than I’ve been on for most of the 4+ years I’ve been there1. Together, these factors mean that I have even less idea than usual what I do for a living, right now.
On the whole, I approve of Matt‘s vision for this reorganisation. He writes:
Each [Automattic employee] gets a card: Be the Host, Help the Host, or Neutral.
You cannot change cards during the course of your day or week. If you do not feel aligned with your card, you need to change divisions within Automattic.
“Be the Host” folks are all about making Automattic’s web hosting offerings the best they possibly can be. These are the teams behind WordPress.com, VIP, and Tumblr, for example. They’re making us competitive on the global stage. They bring Automattic money in a very direct way, by making our (world class) hosting services available to our customers.
“Help the Host” folks (like me) are in roles that are committed to providing the best tools that can be used anywhere. You might run your copy of Woo, Jetpack, or (the client-side bit of) Akismet on Automattic infrastructure… or alternatively you might be hosted by one of our competitors or even on your own hardware. What we bring to Automattic is more ethereal: we keep the best talent and expertise in these technologies close to home, but we’re agnostic about who makes money out of what we create.
Anyway: I love the clarification on the overall direction of the company… but I’m not sure how we market it effectively2. I look around at the people in my team and its sister teams, all of us proudly holding our “Help the Hosts” cards and ready to work to continue to make Woo an amazing ecommerce platform wherever you choose to host it.
And obviously I can see the consumer value in that. It’s reassuring to know that the open source software we maintain or contribute to is the real deal and we’re not exporting a cut-down version nor are we going to try to do some kind of rug pull to coerce people into hosting with us. I think Automattic’s long track record shows that.
But how do we sell that? How do we explain that “hey, you can trust us to keep these separate goals separate within our company, so there’s never a conflict of interest and you getting the best from us is always what we want”? Personally, seeing the inside of Automattic, I’m convinced that we’re not – like so much of Big Tech – going to axe the things you depend upon3 or change the terms and conditions to the most-exploitative we can get away with4 or support your business just long enough to be able to undermine and consume it 5.
In short: I know that we’re the “good guys”. And I can see how this reorganisation reinforces that. But I can’t for the life of me see how we persuade the rest of the world of the fact6.
Any ideas?
1 I’ve been on Team Fire for a long while, which made my job title “Code Magician on Fire”, but now I’ll be on Team Desire which isn’t half as catchy a name but I’m sure they’ll make up for it by being the kinds of awesome human beings I’ve become accustomed to working alongside at Automattic.
2 Fortunately they pay me to code, not to do marketing.
3 Cough… Google.
4 Ahem… Facebook.
5 ${third_coughing_sound}… Amazon.
6 Seriously, it’s a good thing I’m not in marketing. I’d be so terrible at it. Also public relations. Did I ever tell you the story about the time that, as a result of a mix-up, I accidentally almost gave an interview to the Press Office at the Vatican? A story for another time, perhaps
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!).
I’m incredibly fortunate that my job gets to tick so many of the boxes I’d put on a “dream job wishlist”:
Did I mention that we’re hiring?2
But you know where else ticks all of those boxes? My voluntary work with Three Rings. Let me talk you through that wishlist again:
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 me4. 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.
1 I’m badly-paraphrasing Matt, but you get the gist.
2 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…
3 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!
4 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.
This post is part of my attempt at Bloganuary 2024. Today’s prompt is:
Come up with a crazy business idea.
Smell-based social networking for dogs.
Hear me out…
I’ve tried to explain to our occasionally-anxious dog that, for example, the dog-and-human shaped blobs at the far end of the field includes a canine with whom she’s friendly and playful. She can’t tell who they are because her long-distance vision’s not as good as mine1, and we’re too far away for her to be able to smell her friend.
If this were a human meetup and I wasn’t sure who I’d be meeting, I’d look it up online, read the attendees’ names and see their photos, and be reassured. That’s exactly what I do if I’m feeling nervous about a speaking engagement: I look up the other speakers who’ll be there, so I know I can introduce myself to people before or after me. Or if I’m attending a work meet-up with new people: I find their intranet profiles and find out who my new-to-me colleagues are.
Wouldn’t it be great if I could “show” my dog who she was going to meet, in smell-form.
I imagine a USB-C accessory you can attach to your computer or phone which can analyse and produce dogs’ unique scents, storing and transmitting their unique fingerprint in a digital form. Your subscription to the service would cover the rental of the accessory plus refills of the requisite chemicals, and a profile for your pooch on the Web-based service.
Now, you could “show” your dog who you were going to go and meet, by smell. Just look up the profile of the playmate you’re off to see, hold the device to your pupper’s nose, and let them get a whiff of their furry buddy even before you get there. Dogs do pretty well at pattern-matching, and it won’t take them long to learn that your magical device is a predictor of where they’re headed to, and it’ll be an effective anxiety-reducer.
The only question is what to call my social-network-for-dogs. Facebutt? Pupper? HoundsReunited???
1 Plus: I get contextual clues like seeing which car the creature and its owner got out of.