In Software, the Medium is the Material – But Developers Should Not Be Defined by Their Tools
If jobs for architects were written like those for developers, they would read something like this:
Exciting new opportunity for a small-building architect. You must have 3-5 years experience designing buildings with GiantCorp concrete, XYZ Rebar, and BigManufacturer glass. It’s essential you have extensive experience with buildings that are a single level high and with pitched roofs—none of that flat-roof crap. Must be passionate about buildings—if buildings are your hobby, not just your job, we want to talk to you.
Pluses:
- Bonus points for experience with buildings to be painted yellow.
- Our studio uses dark graphite pencils and we expect you do too!
- Experience designing buildings with medium-height cielings, one to five rooms, parking spaces, and backyards.
- Backyards make you tremble with joy and you spend your weekends peeking over fences into them.
Perks: Bi-weekly group outings to design museums and late nights playing tennis with the whole office.
I’m exaggerating to make a point. Of course there are significant differences between iOS developers and Ruby on Rails developers, just as there are for architects who do residential buildings versus high-rise skyscrapers.
However, the amount of project-specific components loaded into job listings for programmers is mind-boggling. Note that what’s absurd about my fake job listing is that there is an emphasis on materials, not skills, and situation-dependent experience, rather than high-level and reusable concepts.
The specificity excludes candidates who would otherwise be qualified, based on choices the employer made (using XYZ Rebar) and constraints that the project demands (medium-height cielings) which might not really be so important. Bonus points are applied for things that are about style rather than skill. And on top of it, naive enthusiasm is demanded—which is just patronizing.
I’m spoofing mainly startup job listings here, of a type you often see in the Bay Area and elsewhere in the U.S., but which also appear frequently in the English language listings in Europe for jobs in places like Berlin, Barcelona and London.
Part of the confusion stems from the fact that software and web developers have to be the architect and the construction foreman and the grunts pouring concrete all at once. To build the thing is to understand the thing – comprehension is construction. So programming doesn’t so easily split into neatly divided domains of design on the one hand, and execution on the other.
Despite that blurred line given the unique properties of software, it’s the big-picture problem-solving skills that matter most, and following that, a cascade of experience factors in lesser degrees of importance. If an architect has used concrete, understands its load-bearing properties and so on, it doesn’t matter that much what brand they’re using. Likewise, programming languages aren’t nearly as different from each other as German and Greek, though you would easily get that impression.
If a developer has used a dependency manager, an object-oriented language, an MVC framework, and so on, then picking up a new tool in a similar vein is not going to be particularly difficult. But it will be time-consuming and annoying, requiring an investment of time and taking on the risk that it will be a waste of precious brain space if the technology goes out of fashion.
Whose responsibility is it to take on that risk? Judging from job listings, it would seem to be entirely on the programmer, not the companies that employ them.
Why do tech companies do this? Why the rigid focus on materials?
For a start-up, using XYZ Rebar (i.e. insert software buzzword here) seems mission-critical. They’re trying to get an edge on competitors, and unlike most building materials, new technologies really can be a lot more performative. Then again, also unlike brands of cement, they take a lot more time to learn to work with, and thus can slow down a project. The performance advantage of using a new material might be wiped out due to the workflow disadvantage of building a product with an immature technology.
That calculation of risk – cutting-edge tech vs. existing pool of expertise – is a gamble that the company and its owners and investors is deciding to take on (knowingly or not). It’s a strategic issue that should be considered right at the outset of a project. Making that gamble on a trendy new tech stack, then finding out it’s hard to source the expertise, is a problem that ultimately belongs to the company.
Inverting that responsibility and putting the expectation of ready-made experts out in the world has been going on so long it’s a known trope. Just a couple weeks after Apple released the Swift programming language, I saw developers on Twitter poking fun at a job listing that asked for ‘at least two years’ of experience with Swift. This leads to a related problem: programmers faking it until they make it, with mixed results.
There is an alternative. Organizations can hire for problem-solving skills and communications skills, along with technical acumen (obviously) and proven learning ability – rather than acronym-soup – when collecting the people they want to execute their idea. Rather than inviting naive enthusiasm or demanding “passion,” they can just treat developers like adults – with normal, human limitations and also, the ability to grow. You might as well invite developers to learn on the job and give them the resources, structure, and support to do so. Because they’ll be doing it anyway. Because this learning process is the job. Even the most skilled and seasoned programmer doesn’t know exactly how they will fix a specific problem until they do it.
Like architects, or other types of industrial designers, developers don’t need foosball tables or extra caffeine in order to do their jobs. The big perk they need is a hospitable workplace culture that invites learning and has realistic expectations. Doing that also directly addresses the issue of programmer diversity, in which the industry welcomes more of the many different types of people who are lining up to do this work: a better set of onramps, where they can take the skills they have already and build them into the skills companies need today.
