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 "distributed" 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 🦄, because people who do this are rare.
I don't 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't 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't 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?
Unicorns 🦄
This is a subject I've 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've not transcribed the "erms" and "likes" which were superfluous, forgive me):
I've been thinking about this idea of a unicorn, I think it's kind of a meme at this point. A designer being a unicorn is a designer who can code. I think that's actually not possible anymore, or maybe it hasn't 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's 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's 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's opinions on this matter, it's hard to find people praising the idea of hiring a unicorn, or marketing yourself as one. I've seen them called "so hard to hire they might as well be imaginary". Or that "Hiring a generalist typically means you hire someone mediocre at everything.". Or criticised as "creating teams that are light on experience and overly competitive to move onto the next skillset before mastering the previous one". 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't 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's 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's 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'd 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) that's probably going to be the last date.
In a professional context, however, it's 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's 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't 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 "BUT THAT'S WHAT I DO" - listen Jennifer, you know as well as I do that the first thing you'll do if you have money is hire someone to do the things you don't like doing, and they'll do it better than you've been doing it. You'd be mighty annoyed if you hired Benedict to do your accounts for you, and two weeks later he's running your Instagram marketing campaigns instead of running payroll. Stay in your lane Benedict 👎
Look, I got off track, let's bring this back to software. There's a lot of things to build when you're building a system of software to support a modern business. Sometimes, there's 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've 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're getting a little bit carried away with all we can do but let's stay on track.
I really like Chris Coyer's 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 "frontend engineer" or "web engineer" no longer gives you enough granularity to summarise someone's job, or skillset. Instead, you can think about it in terms of the "front of the front" and the "back of the front".
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't 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's job, someone people say it's a speciality.
So...?
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't underestimate their importance. For me that's about knowing what kind of problems my brain enjoys solving, and what kind of work I find meaningful. It's 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're trying to attract. We need the right words to describe the job - for some companies it will be "all about the koolade-train" - 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're 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 "compiler" when really we mean "magic box"). When we use words like "full stack" or "hybrid" or "unicorn" - they're so vague, you're 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.
See other articles