We recently interviewed a developer who was a new grad, brimming with enthusiasm. They answered our interview questions deftly, did well on our coding test, and presented a side project app that was sophisticated for somebody only six months out of university. Even better, their primary language was Swift.
They had been writing Swift 70 hours a week, and were working methodically to develop their skills at an accelerated rate. Their goal, which they hoped to pursue by learning from our team at Steamclock, was to become a “senior developer” in 1.5 years.
Now, I love enthusiasm and a can-do attitude. In fact, for junior developers, it’s one of the things I value most. That said, idea of a new grad toiling 70 hours a week trying to soon be deemed Senior Developer ruffled my feathers. To start, constant overtime is unsustainable and counterproductive. More than anything though, the mere thought of a new grad expecting to be a “senior developer” in less than two years got me agitated, even though I couldn’t articulate why. Even though I use the term “senior developer” when talking about growth or putting together a team, I realized that I didn’t have a working definition of what it means.
Untitled
We’ve never really had titles at Steamclock. I’m a co-founder, and Nigel is a co-founder. For the most part I run the business, but I’m not Chief Business Runner or chief anything else. Any attempt to coin a Chief Something Officer title for myself never really captured what I do, and felt overwrought for a ten-person team. I’m not a chief, I just run the place.
Beyond the founders, we employ developers, designers, and somebody who helps us manage our office. Like most independent software shops, we prefer flexibility over formality. Job titles, especially when assigned to individual contributors like developers, are a formality - harbingers of politics and bureaucracy. Rands even goes as far as to declare them toxic:
The main problem with systems of titles is that people are erratic, chaotic messes who learn at different paces and in different ways. They can be good at or terrible at completely different things, even while doing more or less the same job. A title has no business attempting to capture the seemingly infinite ways by which individuals evolve. They are imprecise frameworks used to measure the masses. To allow leadership to bucket individuals into convenient chunks so they can award compensation and measure seniority while also serving as labels that are somehow expected to give us an idea about expected ability. This is an impossibly tall order and at the root of title toxicity.
Rands is right, as he often is. Attempting to quantify a developer’s skill or value or experience is at best imprecise, and at worst gross. In a perfect world, we could just put that aside, pay every employee the same, and avoid the process of labelling some people senior and other interns. These aren’t spherical developers in a vaccuum, they’re people. Unfortunately, without titles you can end up with a different kind of vacuum.
The Art of the Title
Titles help people outside your organization orient themselves to who they’re talking to. Avoiding titles or, alternatively, letting people choose meaningless titles makes it harder for new hires or clients to grok your organization. We’ve worked with large companies that lack formal titles, and determining whether the Chief Pixel Assassin or Senior Code Snorfler has the final say on a key product decision can be a… challenge.
A lack of formal designations in a larger organization can also make it harder for certain people to communicate authority. For example, people from underrepresented groups in senior roles can have an even harder time communicating their authority if they don’t have a title to back it up. You can dislike titles all you want, but if the strongest developer at your company is a black woman, equipping her with business cards that actually say “Principal Software Developer” is going to be a net win. Of course, that’s only helpful if your institutional biases don’t prevent her from attaining that title in the first place.
Besides their value in communication, titles’ most important role is to help reason about growth. Talented people want to grow their skills and responsibilities, and need recognition and compensation for that growth. Doing that in a totally ad-hoc way without any kind of labels gets hard as a company grows.
Even at our size, where we’re small enough to do without titles, we need some way to discuss professional development and paying people fairly. We need to make sure bright developers with a lot of potential see a path to becoming seasoned developers with a lot of skill. We also need to talk about compensation, and understand what it means when some competitor is paying “senior developers” a “shitload of money” to “move to San Francisco and live in a closet in the Tenderloin”.
The title sequence
With that in mind, I attempted to hash out for our Enthusiastic Applicant what we mean at Steamclock when we discuss terms like intern, junior, and senior, even if we don’t have those terms on any business cards.
Intern: Does not actively sabotage app development. Is learning the language and tools, probably has some education but hasn’t held a full-time development job. Isn’t experienced enough yet to evaluate further.
Junior: Has shipped at least one app, and are generally productive. Junior developers still typically need oversight, might not be comfortable yet with gnarly tasks like choosing open soure components or code signing, and are still primarily evaluated on enthusiasm, attitude, and growth. Typical experience: 0-3+ years.
Intermediate: Has the experience and wisdom to lead technical direction on a small project, coach and review other developers’ code, and prioritizes well. Has become comfortable with the technical tradeoffs that present themselves day by day, and actively works to better understand these tradeoffs and design patterns. Intermediates can work directly with non-developers and know when to escalate issues, technical or project-wise. Intermediates have developed the skills for discussing project issues productively with the team, and have refined key communication skills around software development. Technology wise, they have knowledge of the various tools and frameworks that relate to their work, and have gotten relatively fast at picking up new ones. When they encounter technical problems, they are usually hard problems like caching or naming things. Typical experience: 2-6+ years.
Senior: Has the wisdom, intuition, and humility of a battle-worn developer. Can accurately estimate tasks and projects, primarily by drawing on experience. Has led other developers and is good at motivating, teaching, prioritizing, and coordinating. Has overcome and can spot common bad instincts like “not invented here” and “second system”. Has internalized the costs and general futility of overwork. Builds good relationships with other employees and clients using a honed sense of organizational and personal awareness. Thinks in terms of product and business success. Could probably have their own company, but knows they’re stronger as part of a team. Can systematically address technical problems that are mysterious and messy. Has developed specialties and technical expertise in specific areas that makes them unusually valuable on certain projects. Is active in the community and helps recruit and interview new talent. Is in control of their own motivational whims to the degree that their productivity isn’t limited to tasks they enjoy. Typical experience: 5-15+ years.
Title Card
Having read my outlines of what career development might look like at Steamclock, our Enthusiastic Applicant was humbled yet motivated. They realized that becoming a senior member of a software team wasn’t just about having typed a lot of Swift and having read a lot of blog posts, but more about being tempered in the fire of mistakes and self-improvement. They still like the idea of getting to a “senior” level in a couple years, and while that seems exceedingly unlikely, why not let them try? Worst case scenario, we have a bright developer working on getting better at their craft for years to come.
Well, worst case scenario is that they leave after six months to make a hojillion dollars burning themselves to a husk at Amazon. But it’s my job to be an optimist.
Wait - Chief Optimism Officer? Nah, co-founder will have to do for now.