So you’re interested in Growth Quarters? Then join our online event, TNW2020, where you’ll hear how the most successful founders kickstarted and grew their companies.
Similarly to the nobility in the Middle-Age who loved enslaving poor villagers to make lords and knights rich and powerful, we, software developers, love titles.
A glimpse at one’s title and you’ll know exactly what the developer is capable of, and how much value he’ll bring to the company. How useful! How magical!
We don’t have lords, kings, and buffoons in our little Software Development World. However, your favorite recruiter, CTO, COO, CEO, or whatever C-level manager, might enjoy calling you “coder,” “programmer,” “developer,” “web developer,” “front end developer,” “software developer,” “software developer engineer,” “devops,” “architect,” and even “consultant.” They might use more exotic terms too, depending on the creativity of your management.
These titles aim to describe your role in the company. If you’re lucky (trust me, you’ll be), they will be prefixed by a beautiful “Junior,” “Senior,” or “Wizard,” showing your rank and your greatness to your peers.
People holding these titles will share some common features. They are technical people who know how to code, and who will more or less spend their days coding. Consultants should not do that though, but it’s another subject.
We’ll see, in this very profound, thought-provoking, and mind-bending article:
- What are the meaningful titles you’ll encounter?
- Why millions of them are useless, and what other possible titles should we use?
- What are the titles which will catapult you to the bottom of your favorite company’s organizational chart?
I can see that you can’t wait to answer all these crazy questions! How do I know? I’m a Senior Developer: I know everything!
[Read:
To be honest with you, I can’t wait either! Let’s begin.
Title as a role
The meaningful titles
Some titles can give you an overview of your work if you hold them. Don’t expect to be enlightened though, they carry very basic information.
1. The frontend developer
This special specie of developer will deal with everything the end user can see or interact with, when the crazy software will be available to the populace. Typically, he’ll code using some good old CSS, HTML, and often JavaScript.
Managers might venerate them, amazed by so many buttons, colors, and little dogs flying all over the software. This can be a blessing, or a fatal curse.
2. The backend developer
The mortal enemy of the frontend developer, the backend developer is a troglodyte who deals with everything nobody sees. He’ll put together the gears and cogs of a software, if you will. Try to open your car’s hood: it looks boring and complicated, but without it your car would have difficulties to move around.
Most people won’t understand what backend is about, not because everybody else is stupid, but because nobody cares. As a backend developer, I definitely respect that. I don’t care about cars, either.
3. The web developer
A web developer is somebody coding anything which can be fetched using the amazing World Wide Inter Web. If you lived under a rock the past decades, it’s a mess of websites, linked all together with hyperlinks. A big corporation mostly controls what website you’ll see and consult. Its name begins with a “G.” Can you spot it?
The web developer is often opposed to a more “traditional” kind of developer who develops desktop applications. These applications are not executed by a resource-intensive browser but by an OS (Operating System). Why somebody would do that? I don’t know. Performance, maybe?
The titles which should exist
Except for the titles described above, titles describing some roles won’t give you any clue what the company really expects from you. You’ll spend some time coding in some wonderful offices, of course. After that, your fertile imagination can let you create the most amazing role which will disrupt the whole industry, the whole world, or the multiverse itself.
What’s the point to be a “software engineer” instead of a “developer’? Nobody agrees, because nobody really knows.
Since I have a whole article to write, let’s forget these titles and, instead, let’s describe the real roles you can have in a company.
These roles can be mixed. For example, a company might search a developer who’s 70% code monkey and 30% lonely coder.
1. The code monkey
If you care about development and the impact you have as a developer, you will thrive to be a code monkey as much as a fish will thrive to be in the Sahara.
As a code monkey, you’ll spend your time with your mouth shut and your finger producing billion of lines of code. You’ll be only there to follow blindly every decision taken by your superiors. Your name will be engraved in a scary and strict organizational chart.
For your managers, a developer is a worker on a production line: you have a plan, you follow it by the letter, and BAM! You have a software which will make everybody rich (except you, of course).
As a Code Monkey, you don’t think. You produce.
These companies have often a pretty poor company culture. It can be seen as an expensive experimentation to show how much scientific management (or Taylorism) is not a good idea for knowledge work.
Because of the strict hierarchy, expect the waterfall management style to be used, even if the company claims to be agile because of a whole array of ceremonies they carefully put on their Google Calendar: stand ups, retrospectives, you name it. Despite these ceremonies, the mindset of agile software development itself will be highly misunderstood.
You need to expect a high level of entropy regarding their projects, too.
Companies that want code monkeys might use fear and pressure when they won’t have the results they expect (and, trust me, they won’t). They will then impose infinite death marches to eventually burnout everybody.
After enough time to deplete your hopes and dreams, bankruptcy might be their ultimate fate, especially if we speak about startups.
If you are a code monkey, follow Gandalf’s precious advice: flee, you fool!
2. The lonely coder
Can you picture the end of countless old westerns where the hero, while the sun is going down, turns his back to the camera to go on new adventures, with his only friend, his horse? Then, the screen transition to black forever.
The lonely coder is alone too, but, contrary to the cow-boy, he has no horse, and the screen never fades to black. Loneliness stays till the end of time.
He’s the only developer on his project or, worst, in his company.
He has no chance to learn from anybody, nobody can back up his mistakes, and he has to endure every single crash and bug, without any shoulder to cry. What about feedback? Forget it.
The life of the lonely coder is full of sadness. Avoid this situation as much as you can.
If you work for a young startup (or a startup that is not growing), you’ll be likely to be the lonely coder. In that case, the risks could be acceptable when the potential benefits have more weight.
If you choose this path, you need to have a good experience as a developer, in the technologies the company uses, and in the business model of the company itself. In short, you need to know in what electric plug you put your fingers in.
Keep in mind though (and explain it to your management) that more than one brain on a project, which can support each other, is way, way better. We are all humans, we all do mistakes. No way around that.
3. The ultimate coder
The Ultimate Coder is the best of the best. He needs to know everything the other developers of the company know, plus the stuff nobody heard of.
He’s a human-Wikipedia-machine which can answer every question about random topics, a possible winner of “Who Wants to Be a Millionaire – Developer Edition.”
Infinity is not enough to speak about his knowledge and skills.
I see many companies searching for the ultimate coder. They are the Saint Graal in our industry. The ultimate goal of many recruiters out there.
Often, it doesn’t matter if they can work well with others, have good communication skills, or good soft skills in general. No: they need to be touched by the Light of Technical Knowledge, the Finger of All Technical Skills, the Breath of Every Technical Concepts.
Do you think many companies need this crazy amount of knowledge? Nop, not at all.
Very often, good-enough-code will serve companies better than more-than-perfect-software-which-will-be-still-shining-in-20-years-but-takes-two-years-to-have-two-functionalities.
If you cross managers who want The Ultimate Coder, you can be sure that they have no idea what kind of skills they really need to, to fulfill their goals.
There could be different reasons:
- Their goals are never really defined.
- Their goals change every two weeks.
It’s really common in the startup world.
It’s even more dangerous if they sacrifice soft skills on the shrine of purely technical skills and knowledge. You can end up with very good technicians who work in isolation, arrogant, with egos going through the roof. As some studies found out (including the famous Rework from Google), individual skills don’t really matter. The team dynamic and the complementary skills of each member do. It’s called collective intelligence.
The ultimate developer is essentially a myth, anyway. This title is often awarded to the developers who prepared the best for interviews.
Most of the time, if the company think they found one of this pearl, they might not even bring what the company really need.
4. The ultimate God
This is a funny variant of the ultimate coder. Not only he has every technical skill you can ask for, but he’s as well a talented designer, a magnificent project manager, a wonderful customer care member, and he knows everything about UX.
Searching a fullstack developer can be a conventional way to be on the quest of the ultimate God. The job description will often go into a lengthy list of technologies and skills the future employee needs to have.
After all, it makes sense: when you can have 10 employees in one, you reduce many costs.
Unfortunately, if the ultimate coder is a myth, the ultimate God is a scientific impossibility. Companies in quest of these ultra-dimensional beings will push any human, who can’t possibly be good in everything and anything, into burnout hell, before going themselves into a wall.
Runaway from this position, even if the salary is astronomical.
5. The fooled developer
Some companies are masters in the art of illusion. Most of the time, they even succeed to fool themselves.
The fooled developer is the unfortunate programmer who thinks that he’ll work for a company with a good culture. On the paper, he’ll have interesting responsibilities, he’ll be trusted, and, ultimately, he’ll find happiness 8 hours a day.
Instead, even if great and attractive principles will be thrown during the interview (they might even be displayed on the wall), the fooled developer will end up as a code monkey, an ultimate coder, or any other role nobody wants.
When you’ll speak, your superiors will node their heads in approbation, listening to every single of your idea. They might even begin to take action, but the result will be always the same: nothing will ever change.
Sometimes, the management will honestly project their dreams on the company, blind to the actual reality. It will make them passionate, convincing, and, accordingly, even more dangerous.
It can be as well a short term tactic to find or to keep developers when hiring is difficult and human resources scarce.
Being a fooled developer is never a good surprise. If you understand that your management won’t let you experiment and take your ideas into consideration, your motivation might take a slap in its face.
Again, try to find something better.
6. The valuable developer
A company searching a valuable developer understood that developers are not on this planet to code blindly, alone in their cubicles.
They are useful to understand problems and solve them using, most of the time, automation. You know, what software is usually good at.
A valuable developer brings value to a company, in form of money and/or time, not lines of code or other feel-good metrics.
They have a whole array of soft skills they might have learned with their experience. Even if they are beginner, they understand that communication, team effort, compromises, mentoring and healthy debates might be even more important than pure technical skills.
They are not only working with other developers, but are curious about many facets of the company, since they might affect the software’s features and the way they build it. Design, customer care, UX are taken into consideration.
The valuable developer, ideally, might have as well some knowledge about the mindset necessary to work iteratively. He’s not afraid of experimenting and going out of his comfort zone. He likes to test features quickly with real clients, to have the feedback necessary to see if everything is going in the direction the company wants to take.
The valuable developer is afraid of eternal meetings and developing huge features that can easily transform his life into an infinite death march, with late feedback and, therefore, no guarantee of any positive impact whatsoever for the user.
He likes metrics and studies to backup his ideas, avoiding the “everybody-does-it” and “it-is-known-that-this-is-the-way-to-do-it” arguments.
A company searching valuable developers will support them with good company culture: no blames and relative freedom, as soon as the work makes sense and is done.
They will be trusted, at every level, knowing that they like their work and, therefore, will thrive to do it correctly.
We should all aim to be the valuable dev, and we should all aim to find companies that understand and support this concept.
Title as a rank
Junior vs Senior developer
Let’s see now another side of this wonderful subject: the titles used to rank your potential and capabilities.
These titles will determine what position, in the company’s hierarchy, you have as a software developer. Don’t be a fooled developer: even if you’re working for a startup with a “flat hierarchy,” it’s commonly less flat than it pretends to be. Often, nobody took time to drew the organizational chart, but it exists anyway.
1. The junior developer
Every developer has been called “junior.”
You’re “Junior” if you don’t have “enough” years of experience in the software industry. You’re the rookie, the newbie, the unskilled mistake-maker. Congratulation!
It implies as well that you have less knowledge and skills than everybody else who has more experience than you. Therefore, you’ll be, in general, less useful, providing less value.
All of that stays pretty vague. If you look a bit closer, you begin to see some flaws.
First, how can you compare two developers who have a different experience and/or knowledge in very different areas, but still related to software development? Is a developer who studied cryptography still “Junior”, compared to somebody with 20 years of experience programming WordPress websites, without any knowledge in cryptography?
It’s difficult to compare the level of knowledge and skills. We mostly all learned differently our craft. The same amount of experience can translate in very different skills too, depending on the content of the experience itself.
Every man is my superior in some way. In that, I learn from him.
Ralph Waldo Emerson
Even worst: many years of experience don’t mean that skills improve. If a developer spent 10 years repeating the same mistakes (10 years of as a code monkey or as a lonely developer can produce this kind of expert beginner), we can’t really speak of improvement.
Consequently, a “Junior” Developer can be better, more productive than our 10 years veteran.
Being a “Junior” has another monstrous flaw: many companies will use it to play on the impostor syndrome of our poor developer.
Somebody beginning in the industry won’t necessarily have a big self-confidence, and even if he has crazy problem-solving skills, a huge interest, and a superior will to learn than every other senior developer in the company, he’ll still be “Junior.” A “Junior” bringing a lot of value, but still not considered and paid as much as the others.
That’s another problem with this title: it will decide how many zeros your payslip will have. You’ll understand easily that many companies are eager to call everybody “Junior.”
To go against this tendency, as a “Junior” developer, you can show your results with metrics, diagrams, and whatnot to prove that yes, you’re bringing value to the company.
I won’t lie to you: this “Junior” concept is very strong in the common wisdom. It will be difficult for managers and developers to understand that you can be paid more than legacy-code-producers called “Senior.”
Finally, even if you have less knowledge and experience than more experienced developers, you’ll have a fresh approach to many problems and situations more experienced programmers won’t. This is an important quality of a beginner: not being stuck in old habits and wrong mindsets, which are difficult to unlearn.
If you didn’t understand yet, I don’t like to use “Junior” as a title. I prefer “beginner.” The difference is subtle, but to me a beginner is somebody who doesn’t have much experience, and that’s all. His value in a company can be as high as anybody else, and it should be the only metric deciding on his position and his salary.
2. The senior developer
Be aware of the fact that experience does by no means automatically lead to wisdom and understanding; in other words, make a conscious effort to learn as much as possible from your previous experiences.
Edsger W. Dijkstra (Source)
If you’re not a senior developer yet, let me narrate you what will happen, someday.
You’ll wake up and you’ll hear a beautiful whispering in your ears. The whispering will soon become the most beautiful symphony you’ll ever hear. The music will be crystalline, flowing from the sky like the purest water would quench your thirst. You’ll be able to touch it, with all your senses.
The light around will intensify and envelop your soul, procuring an infinite feeling of joy and warmth. It will be like millions of comfy pillows surrounding your whole being. Then, it will be shown to you The Path to your Fate and the reason why you’re on Earth.
Fantastic Muses will give you all the knowledge you need and the self-confidence you lack. You will be blessed by the Perfection: no error will ever spoil your code again. Your software will become instantaneous masterpieces and commercial success. Praise, glory, and fortune will always be on your side.
This is how you’ll become a Senior Developer.
Unfortunately, I have the impression that some folks out there are still waiting for their enlightenment to happen, too insecure to call themselves “Senior.” Now, the reality: transitioning between “Junior” and “Senior” developer will be similar to a dice roll in our role-playing life. It can be after one, three, ten years of good and loyal services in a company, or by transitioning between one company to another. At that point, you might decide that, yes, you’re a senior.
In short: it’s random.
For many companies, being a “Senior” Developer is very similar to be The Ultimate Coder (see above). The “Senior” Developer should know a lot. He can answer any random question during an interview, and solve any weird challenge nobody heard of before, except the interviewers themselves. Most of the time, these tested skills will be useless for the actual, daily work the company needs to get done.
Theoretically, a “Senior” Developer is somebody who has a lot of experience and, therefore, who’s skilled. Practically, he’s somebody who can prepare well for twisted interviews.
Most of the time, he needs to know what the interviewer knows, or the “Senior” title will stay unreachable. These interviewers will claim that if the Senior Developer doesn’t know this or that, he’s not a Senior developer.
As we saw above, everybody can have a very different set of skill and knowledge. Somebody can be “Senior” compared to somebody else in one set of skills, but totally “Junior” to another one. We use the title “Senior” Developer as an absolute state, even if it’s a relative one.
Even worst: if a company searches exactly the same skills as every other developer they have, they won’t be able to learn a lot from each other. A team should thrive to have members with complementary skills, not clones. Otherwise, your collective intelligence, as a team, will stagnate.
Is the candidate a Valuable Developer? That’s what the interviewers should ask themselves. The industry is changing so fast (on the surface, the good old foundations stay the same), being able to learn quickly should be more important than what we already know.
Companies know as well what skills they need for their projects and recruit accordingly, instead of throwing again a fizzbuzz-like test to the face of their candidates.
The magical stealthy ninja warrior of the crown mounting a dragon
Did you see someone using a ridiculous title like “Rock Star,” “Ninja,” “Wizard,” or similar? Don’t lie. I’m sure you did.
Ninja! Wizard! That’s what I wanted to do when I was 8 years old. Unfortunately, my mom destroyed my dreams long ago. “These are no real jobs!”, she claimed. Little she knew! Mom! Look at me! I’m a Ninja now!
These titles will be thrown around to look cool and nerdy, most of the time by recruiters who have no clue what your actual job is about.
Ignore these. They are lame. I feel always embarrassed when people use them.
I’m sorry if you did use them to qualify your favorite developer (or to keep him in your company without increasing his salary). I need to remind you, however: we’re not 8 years old anymore.
Wrapping the titles up
What did we learn in this article?
Most titles are meaningless in a general context. Two companies searching for a Software Engineer can seek very different skills.
Some titles are however meaningful, but they won’t give you a lot of information.
We can however isolate some patterns of skills and mindsets the companies really seek and put funny titles on it.
Titles can be used to describe your role, but as well your rank in a company. Are you a “Junior,” a “Senior,” a “Wizard?” I vote for a “Fooled.”
Company’s managers who have a clear vision of what they want and where they want to go is always what you should seek. Otherwise, how can you add value to something which has no solid foundations?
From there, don’t trust the title they want to give you and try to see what they want and what they need.
As I was writing some months ago, if you want to change the company, try to do a trial day for them first. You can then learn about the managers’ intentions and the company culture.
Your technical skills are important, but they are only a mean to an end, not an end in themselves. If you’re a developer thriving to get better, with the mindset of a Valuable Developer, your knowledge will grow as a result, and your efficiency too.
There are millions of companies out there, and many of them are interesting to work with. You simply need to find them.
This article was written by Matthieu Cneude and was originally published on The Valuable Dev, a blog focusing on the important and timeless concepts in software development. You can read the piece here.
Published September 14, 2020 — 06:00 UTC