var __defProp = Object.defineProperty; var __getOwnPropDesc = Object.getOwnPropertyDescriptor; var __getOwnPropNames = Object.getOwnPropertyNames; var __hasOwnProp = Object.prototype.hasOwnProperty; var __export = (target, all) => { for (var name in all) __defProp(target, name, { get: all[name], enumerable: true }); }; var __copyProps = (to, from, except, desc) => { if (from && typeof from === "object" || typeof from === "function") { for (let key of __getOwnPropNames(from)) if (!__hasOwnProp.call(to, key) && key !== except) __defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable }); } return to; }; var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod); var stdin_exports = {}; __export(stdin_exports, { default: () => _2020_05_31_unicorns, metadata: () => metadata }); module.exports = __toCommonJS(stdin_exports); var import_index_10ac95e2 = require("./index-10ac95e2.js"); const metadata = { "title": "I don't want to be a unicorn \u{1F984}, an engineer or a designer - I just want to build things better", "author": "Thomas Wilson", "date": "2020-05-31T00:00:00.000Z", "draft": false, "slug": "2020-05-31-unicorns", "tags": ["frontend", "essay"] }; const _2020_05_31_unicorns = (0, import_index_10ac95e2.c)(($$result, $$props, $$bindings, slots) => { return `

I like building software, or parts of software, which are visual and interactive. I do not particularly enjoy the more abstract, very important, areas like technical optimisation, language design, or anything with the word \u201Cdistributed\u201D in it. I like building user interfaces (UIs); but also architecting and engineering the code that underlies these interfaces, so that engineers can build delightful and functional UIs, without going through as much effort. Good UI and user experience (UX) should be a norm, a default.

A lot of people either design or code. People with feet in both sides of this skillset are often referred to as Unicorns \u{1F984}, because people who do this are rare.

I don\u2019t like the term Unicorn, but it is dangerously close to describing where I am working hard to move my career. I have a difficult time explaining what I do to people. This is a problem when I want some of those people to pay me real human money to do that thing that I can\u2019t quite explain. The current software/technology landscape has made it hard for me to feel I can convey my self, my interests, and my skills using the small number of keywords (Engineer, Designer, Manager). I don\u2019t want to be a unicorn, or an engineer, or a designer - I would like to be seen as a professional who can help teams and companies build things better. And this little essay is nearly 2,000 words asking why is that so difficult to convey in a way which is taken seriously \u{1F937}\u200D\u2640\uFE0F?

Unicorns \u{1F984}

This is a subject I\u2019ve had to mull over since I entered the workforce 4-5 years ago. I have a very clear memory of listening to Episode 318 of the Design Details podcast, apparently in mid-late 2019, in which the co-hosts answer a question about the topic of unicorns (emphasis my own, I\u2019ve not transcribed the \u201Cerms\u201D and \u201Clikes\u201D which were superfluous, forgive me):

I\u2019ve been thinking about this idea of a unicorn, I think it\u2019s kind of a meme at this point. A designer being a unicorn is a designer who can code. I think that\u2019s actually not possible anymore, or maybe it hasn\u2019t been possible for a long time. And if we add in product management into the that, the ability for a single person to be really good at product, and also really good at design, and then when you get into coding it becomes so broad it\u2019s like: okay, can they make iPhone apps? Android apps? Websites? Can they do the frontend and the backend, are they really good at animation and visuals? Can they do user research? There\u2019s so many disciplines that to expect that of one person seems entirely unreasonable. And thus, kind of breaks the idea of a unicorn being one person who can do it all.

While I was searching around for other people\u2019s opinions on this matter, it\u2019s hard to find people praising the idea of hiring a unicorn, or marketing yourself as one. I\u2019ve seen them called \u201Cso hard to hire they might as well be imaginary\u201D. Or that \u201DHiring a generalist typically means you hire someone mediocre at everything.\u201D. Or criticised as \u201Dcreating teams that are light on experience and overly competitive to move onto the next skillset before mastering the previous one\u201D. These are all valid criticisms that any business looking for a cross-discipline employee should be aware of.

Despite this criticism, I think the relatively recent expansion and funding in the no/low code tools space is evidence that creating software shouldn\u2019t always be done by those with the technical knowledge or experience. Most directly with tools like Framer, which prides itself on being able to output code from visual prototypes. There\u2019s more to software than a robust codebase, and engineers can be better utilised than a widget/JIRA/feature factory. The notion of sliding pizza and some printed-off functional requirements under a door and waiting 3 months for the software to emerge is a funny trope. It\u2019s a trope because it was once more widespread than it is today, but also because it implies that engineers are only code machines. That they cannot bring technical and creative energy to a project.

Specialisation and language

I, like a lot of humans, am not just interested in one thing. I imagine very few accountants go home and keep thinking about accounting (by choice), and I\u2019d imagine even less janitors go home and think about building maintenance. In the west we accept having hobbies and interests outside of work as normal, and to some extent, w expect it. If I go on a date with someone and they have literally 0 hobbies (liking food, travel, dogs, and gin are not hobbies or a personality \u{1F645}\u200D\u2640\uFE0F) that\u2019s probably going to be the last date.

In a professional context, however, it\u2019s much more common to do one thing, or a narrow set of things. Sure, we change jobs, but this is mostly in seismic events - a promotion, a sideways move, a career change. Economically speaking, allowing people to specialise makes sense - it\u2019s division of labour. We should let jobs be done by those who are good at them, and we can offer more value to a company (and therefore the entire economy) by having a higher unit output per unit input. I can\u2019t turn up one day to work and play CEO, then turn up on Wednesday and be HR, then round the week off by being CFO. If you listen closely you can hear all the co/founders of small, scrappy startups blustering \u201CBUT THAT\u2019S WHAT I DO\u201D - listen Jennifer, you know as well as I do that the first thing you\u2019ll do if you have money is hire someone to do the things you don\u2019t like doing, and they\u2019ll do it better than you\u2019ve been doing it. You\u2019d be mighty annoyed if you hired Benedict to do your accounts for you, and two weeks later he\u2019s running your Instagram marketing campaigns instead of running payroll. Stay in your lane Benedict \u{1F44E}

Look, I got off track, let\u2019s bring this back to software. There\u2019s a lot of things to build when you\u2019re building a system of software to support a modern business. Sometimes, there\u2019s not a lot of room for mistakes in these systems: your bank and the government need the highest quality security, search engines need the fastest indexing, e-commerce websites need to load fast, and so on. No one person can master all of these things - if they could, then they would - but I would be so bold as to say that most software engineering teams are more than one person big.

Like a lot of things, the closer you look at each area of software, the more detail you see. I\u2019ve got a bit of experience working with web technologies - over the past few years, people have been really ambitious about what they can do with the web platform and technologies. The result is a bigger set of moving parts that you can plug together to produce really engaging, sturdy, and high quality software. Arguably, we\u2019re getting a little bit carried away with all we can do but let\u2019s stay on track.

I really like Chris Coyer\u2019s idea of The Great Divide, a term and an idea which evolved from conversations he has on the podcast he co-hosts (Shoptalk Show). The tl;dr is that \u201Cfrontend engineer\u201D or \u201Cweb engineer\u201D no longer gives you enough granularity to summarise someone\u2019s job, or skillset. Instead, you can think about it in terms of the \u201Cfront of the front\u201D and the \u201Cback of the front\u201D.

This division rings true for me personally. My interests and skills in web are around creating and systemising visual design, and creating accessible, usable pages. Equally valid is someone who loves working with web technologies because the challenges in data fetching, build process, authentication or security. These are different jobs, but both could very easily fit into the category of Frontend Engineer on a job board.

This isn\u2019t just a frontend thing: I see similar things happening with DevOps and Reliability Engineering: these are engineers tasked with making sure software is deployed in a sound and reproducible way, and consistently available to the end user. Some people say this is everyone\u2019s job, someone people say it\u2019s a speciality.

So\u2026?

So why does any of this matter? Look, if you want to get high minded about it, but you need to know what makes you happy on the day-to-day basis, because life is just a series of day-to-days and we shouldn\u2019t underestimate their importance. For me that\u2019s about knowing what kind of problems my brain enjoys solving, and what kind of work I find meaningful. It\u2019s also about knowing the kind of people I want to work with and for. I cannot really do any of that, if I cannot explain what I do professionally.

To make it more pragmatic, businesses need to know what kind of technical and creative talent they\u2019re trying to attract. We need the right words to describe the job - for some companies it will be \u201Call about the koolade-train\u201D - looking for Design Unicorns. For others it might be more toned-down, or basic, UI/UX Engineer or Design-Developer Hybrid. Even if these jobs are functionally identical, you will be signalling more than just the functional requirements.

The final thing I wanted to end on is something that I only realised when I was in the process of putting my stray and abandoned thoughts together into writing. It is dangerously easy to use these words, like hybrid or unicorn and accidentally misrepresent your ability or competencies. Or if, for example, you\u2019re writing - the vagueness makes it all too easy to make sweeping generalisations. The term Unicorn appears to have been adopted for the design-code boundary I discussed, but also a UX Unicorn, and also engineers who work at Unicorn (i.e. >\\$1bn valuation companies). We have to use language to make shortcuts, in part because not everyone can understand everything (like how we say \u201Ccompiler\u201D when really we mean \u201Cmagic box\u201D). When we use words like \u201Cfull stack\u201D or \u201Chybrid\u201D or \u201Cunicorn\u201D - they\u2019re so vague, you\u2019re asking people to fill in the blanks with their own colours or words, which is kind of like asking people to put words in your mouth. Something a true unicorn would never do.

`; });