Similarly to the nobility in the Middle-Age - who loved enslaving poor villagers to make lords and knights rich and powerful - we, as software developers, love titles. A glimpse at them and you’ll see exactly what the developers skills are, and how much value they bring to the world.
We don’t have lords, kings, and buffoons in our little Software Development World, but we have titles like “coder”, “programmer”, “developer”, “web developer”, “front end developer”, “software developer”, “software developer engineer”, “devops”, “architect”, and even “consultant”. More exotic terms might be used too, depending on the creativity of your management.
These titles aim to describe your role in a 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 knows 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-binding 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!
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.
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, these developers will code using some good old CSS, HTML, and often JavaScript.
Manager might venerate them, amazed by so many buttons, colors and little dogs flying all over the user interface. This can be a blessing, or a fatal curse.
The Backend Developer
Mortal enemy of the Frontend Developer, the Backend Developer is a troglodyte who deals with everything nobody sees. This kind will 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.
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 control what website you’ll see and consult. Its name begin by 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 expect 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.
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 which 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, bankrupt 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!
The Lonely Coder
Can you picture the end of countless old westerns where the hero, while the sun is going done, turn his or her back to the camera to go on new adventures, with his or her only friend, the horse? Then, the screen transition to black forever.
The Lonely Coders are alone too, but, contrary to the cow-boys, no horse will share their “adventures”, and the screen will never fade to black. Loneliness will stay till the end of time.
They are alone on a project or, even worst, in the whole IT team. A team of one.
The Lonely Coders have no chance to learn from anybody. Nobody can back up their mistakes, and they have 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 which doesn’t grow for years), 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. First, in the technologies the company uses, and second, 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 supportive brain on a project, is way, way safer. A diverse set of brains would be the best. We’re all humans, we all do mistakes, and we all need support. No way around that.
The Ultimate Coder
The Ultimate Coders are the best of the best. They need to know everything the other developers of the company know, plus the stuff nobody heard of.
They are human-Wikipedia-machine which can answer every questions about random topics, a possible winner of “Who Wants to Be a Millionaire - Developer Edition”. Infinity is not enough to speak about their knowledge and skills.
I see many companies searching The Ultimate Coders. 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 sanctified 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.
It’s even more dangerous if they sacrifice soft skills on the shrine of pure technical skills and knowledge. You can end up with very good technicians working 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 matters. The team dynamic and the complementary of skills of each member do. It’s called collective intelligence. That’s one of the reason diverse teams are better than mono-culture teams.
If you cross managers who want to find The Ultimate Coder, you can be sure that they have no idea what kind of skills they really need 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. In both cases, it doesn’t look good.
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.
The Ultimate God
This is a funny variant of the Ultimate Coder. Not only they have every technical skill you can ask for, but they are as well talented designers, magnificent project managers, wonderful customer care members, and they know 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.
Run away from this position, even if the salary is astronomical.
The Fooled Developer
Some companies are masters in the art of illusion. Most of the time, they even succeed to fool themselves.
The Fooled Developers are the unfortunate programmers thinking that they’ll work for a company with a good culture. On the paper, they’ll have interesting responsibilities, they’ll be trusted, and, ultimately, they’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 Developers will be in reality a Code Monkeys, an Ultimate Coders, or worst.
As a Fooled developer, 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, if it happens, try to find something better.
The Valuable Developers
A company searching Valuable Developers 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 a software is usually good at.
Valuable Developers bring 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 from their experiences. Even if they are beginners, 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 they are curious about many facets of the company. Indeed, these facets might affect the software’s features and the way they build it. Design, customer care, UX are taken into consideration.
Valuable Developers might have as well some knowledge about the mindset necessary to work iteratively. They’re not afraid to experiment and going out of their comfort zones. They like to test features quickly with real customers, and gather necessary feedback to see if things go in the direction the company wants to take.
Valuable Developers are afraid of eternal meetings, or developing huge features which can easily transform their life into an infinite death march. They don’t like late feedback and, therefore, no guarantee of any positive impact whatsoever for the user.
They like metrics and studies to backup their 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 a good company culture: no blames and a 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 Valuable Developers, and we should all aim to find companies understanding and supporting this concept.
Title as a Rank
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.
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 have 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 we compare two developers who have different experiences, different sets of knowledge, in different areas of 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 level of knowledge and skills. We all learned differently our craft. The same amount of experience can translate in very different skills too, depending of the content of the experience itself.
Every man is my superior in some way. In that, I learn from him.
Even worst: many years of experience don’t mean that skills improve. If a developer spent 10 years repeating the same mistakes (10 years 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 in many aspects than our 10 years veteran.
Being a “Junior” has another monstrous flaw: many company will use it to play on the impostor syndrome of our poor developer. Beginners won’t necessarily have a big self-confidence, and even if they have crazy problem-solving skills, a huge interest, and a superior will to learn than every other senior developers in the company, they’re still “Juniors”. They might bring a lot of value, but they won’t be considered (and payed) as much as the others.
That’s another problem about this title: it will decide how many zeros your payslip will have. You’ll understand easily that many company 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 developers and managers alike to understand that you can be payed more than possible 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. This is an important quality for a beginner: not being stuck in old habits and wrong mindsets difficult to unlearn.
My advice to any young man at the beginning of his career is to try to look for the mere outlines of big things with his fresh, untrained, and unprejudiced mind.
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. Their value in a company can be as high as anybody else, and it should be the only metric deciding on their positions and their salaries.
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.
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 million of comfy pillows surrounding your whole being.
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 successes. Praise, glory and fortune will always be on your side.
This is how you’ll become a Senior Developer.
There is another possibility: 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. Why not?
In short: it’s random.
For many companies, being a “Senior” Developer is very similar to be The Ultimate Coder. The “Senior” Developers should know a lot. They 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, they’re developers who can prepare well for twisted interviews.
Most of the time, they need to know what the interviewers know, or the “Senior” title will stay unreachable. These interviewers will claim that if the Senior Developer doesn’t know this or that, he’s (or she’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 a absolute state, even if it’s a relative one.
Is the candidate a Valuable Developer? Is the candidate bringing a set of ideas, skills and views the other developers don’t have? Can I learn from the candidate? 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 ridiculous title like “Rock Star”, “Ninja”, “Wizard”, or similar? We all 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 idea what the actual job is about. Ignore these. They are lame. I feel always embarrassed when people use these titles.
If you did use these titles to qualify your developers and you’re reading these lines, let me tell you: developers are 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 a Software Engineer can seek very different skills.
- Some titles are meaningful to a degree. Most of the time, 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 as well as your rank in a company. Are you a “Junior”, a “Senior”, or 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 before, if you want to change company, try to do a trial day 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 million of companies out there, and many of them are interesting to work with. You “simply” need to find them.
Now, I’ve a request for you, dear reader: please, share the weirdest titles you’ve encounter in the comment section. We shall altogether create the Ultimates Book of the Most Ridiculous Titles Given to Developers.