Like many others in the tech industry, I’m tired of companies referring to web/software developers as “ninjas” and “rockstars.” Recruiters’ job postings are littered with phrases like “rockstar developer” and “coding ninja,” which just don’t make sense. Take a look at Merriam-Webster’s definition of ninja:
A person trained in ancient Japanese martial arts and employed especially for espionage and assassinations
There’s nothing in this description that is relevant to software development. Sure, you could probably make an argument about how the physical agility developed through martial arts is somehow related to the professional agility of technology teams practicing ADM, but that’s a bit of a stretch. Ninjas are trained spies and killers. If you’re using war characters as your metaphorical ideals for software developers, wouldn’t you rather look for people skilled in defense who can fortify your city (i.e. make your product as strong as possible)?
When I see a job posting asking for a “rockstar developer,” I wonder, what qualities of a rockstar should I embody? The media’s depiction of rockstars involves excessive drug use, promiscuous behavior, lip-syncing on stage, inflated egos, and crowd-surfing, none of which seem appealing or relevant to software development. So what happens if I don’t want to be a rockstar? What if I want to be an indie-folk singer-songwriter with a comfortable coffee shop following? Is there a place on your development team for me and my banjo?
The main reason the “ninja” and “rockstar” buzzwords fall short is that they’re too vague. When recruiters use these words, they convey “we want someone who’s awesome,” but they don’t identify the characteristics and skills that make someone awesome in their eyes. If recruiters want to refer to other professions in their job descriptions, I propose they get practical and discuss roles with skill-sets that are conceptually similar to those of software developers. Ditch the ideals of ninja and rockstar and instead look for sculptors and archaeologists.
The ideal software developer is a sculptor.
There are a remarkable amount of similarities between the four main techniques of sculpting and the activities of a successful software developer. Let’s take a look at each:
Modeling:
Modeling is the process of building up a sculpture from highly-malleable material, like clay. If you’re a technical recruiter, you want to make sure potential software developer hires have this down pat. At the bare minimum, software developers take the raw material of a programming language and use it to create something new. Expert software developers have more advanced techniques and tools — APIs, testing frameworks, architectural principles — that help them mold this raw material into something truly extraordinary.
Assembling:
Assembling is the process of combining multiple objects or materials together to make a sculpture. Think of this as 3D collage. The Master Builders in The Lego Movie excel at this (I just saw this movie and am obsessed!), and software developers should excel at it, too. It’s rare for a feature to use only one technology; good software developers are able to combine several external and in-house libraries, in several programming languages, into one coherent set of functionality. Additionally, when product managers ask them to combine a handful of features into one mega-awesome feature, good software developers know how to refactor and merge code to accomplish this goal.
Casting:
Casting is the process of creating a sculpture by pouring a liquid material into a mold and letting it dry. What’s brilliant about casting is that you can make multiple copies of the same sculpture. See, for example, the many bronze casts of Auguste Rodin’s Thinker. Where this pertains to software development is largely in the process of creating the mold; when good developers write code, they write it in such a way that it is reusable and extensible, so that they and others can use that code to quickly build new products without duplicating effort.
Carving:
Carving is the process of creating a sculpture by chipping away parts of a hard material, such as wood or stone. Of the four sculpting techniques, this is the only one that is subtractive. There is less room for experimentation here than in other techniques (What if you accidentally chip away too much?), so it is crucial to come up with a plan in advance and work through it methodically.
In my mind, this maps most closely to the work that software developers do to maintain and improve existing features, which, let’s face it, we spend a lot more time doing than working on new features. There is always something to optimize — whether it be a site’s performance or the code’s legibility — and optimization involves taking away pieces that aren’t necessary.
Refactoring existing code is an opportunity to refine old, crusty, spread-out functionality into something that is easier to understand and maintain. But not everyone can do it. Refactoring and optimization require a strong understanding of all relevant aspects of the system; complex codebases have complex dependencies, so if you change one thing, chances are you’ll have to change several more so as not to introduce regressions or — the scariest of scary! — cause data loss. An expert software developer must be like an expert stone-carver, carefully evaluating each move for its potential ripple effects.
The ideal software developer is an archaeologist.
(No, I’m not suggesting that the ideal software developer should take after Indiana Jones and wear a fedora all the time.)
Unless they’re part of a startup in its earliest stage, software developers spend most, if not all, of their time working within large systems full of code they didn’t write. This can be a huge hurdle to productivity, mostly because complex codebases aren’t nearly as well-documented as they should be. There are a number of reasons why they aren’t. When people are deep within their own code, everything makes sense to them, and it’s easy to forget that outsiders have no clue what’s going on there. Some code is not meant to last long, and a codebase may contain several bandaids with code comments like this:
// Hacked up temporary fix for bug #8675309
// TODO: Refactor this in next release
Several releases later, the temporary hack is now a permanent fixture, and a new developer is staring at these comments wondering what prevented the previous team from fixing the bug the right way the first time. When adding new functionality to a feature or fixing a bug, I spend at least half my time trying to understand other people’s code, and the rest of the time actually making the change.
The best software developers know how to be code archaeologists. They are experts at excavating legacy code. Like archaeologists, they are able to analyze the results of their excavations from multiple angles and come to a reasonable understanding about what previous generations — whether a thousand years ago or a thousand days ago — were thinking. They share their findings with others. Through analysis of existing systems, developers gain the requisite knowledge to work on those systems with confidence, to begin chipping away at them like stone-carvers.
Recruiters don’t write about this stuff in job descriptions because it’s not fun to admit that a role involves digging around in a cesspool of legacy code. But the best developers will welcome the challenge, put on their waders, and stride right into the cesspool knowing that they can learn from whatever they find.
The ideal software developer is _____________.
The ideal software developer is probably not going to identify as a ninja or a rockstar, but as someone who enjoys the challenges of learning complex systems, thinking through tough problems, and building solutions with a variety of tools. As much as I would love to see recruiters replace “code ninja” and “rockstar developer” with “code archaeologist” and “software sculptor,” these new phrases may not mean anything without context.
My best advice for attracting talent is to be descriptive and discuss the sorts of interests and skills an ideal software developer would have. If recruiters really want to talk about ninjas and rockstars, or even sculptors and archaeologists, they should spell out the qualities that are shared between those roles and the software development roles they’re advertising. Candidates will identify more with a list of desired skills than with a list of arbitrary buzzwords.
Originally published at cordeliadillon.com on March 2, 2014.
