If you need to invoke your academic pedigree or job title for people to believe what you say, then you need a better argument.

— Neil deGrasse Tyson
American astrophysicist

These last years, we have seen a proliferation of new job titles to describe the same, unchanged activity — making lines of code come alive. DevOps Engineer, Backend Developer, Technical Architect, Developer, Tech Lead, IT Consultant, Hacker, Senior Fellow, Senior Big Data Engineer, Software Developer, Java EE Expert, Programmer, and so on. What can we learn from a job title? Should we care about it? Should we move to another position?

Why do we need job titles?

Organizations, large or small, need structure to bring order to chaos. Job titles contribute to this structure, defining the role each one of its members is playing. Large organizations use usually well-defined job titles, with a clear progression, and a beautiful organization chart, whereas small organizations use more informal job titles to strengthen their differences. There are no hard rules about job titles, especially about software development.

In practice, we often change job titles when we are changing jobs, at least on our employment contract. On social networks, it is not common to use a different position. At the beginning of our career, we generally use very precise description of what we do (e.g., Junior Frontend Web Developer), but slowly we acknowledge that we are programmers first (programmers, coders, and developers, are interchangeable), and in the end, our job titles get shorter.

Based on social networks, Kent Beck, Martin Fowler, Andy Hunt are programmers, Mitchell Hashimoto is a developer, James Gosling, Rod Pike are software engineers, and Bob Martin is a software craftsman. Their job titles are short and not very specific, and could be reduced even more, since they are all listed on Wikipedia under the list of famous programmers.

Do we need so much job titles?

Job titles make the distinction ambiguous between our profession and the role we play in a specific project because each new project often comes with a new job title, whereas what we do doesn’t really change. Writing web components or writing code to provision the application, in both cases, we are responsible for having a working deliverable solution. We don’t really need so many different job titles. It’s only when our responsibilities are changing that a new job title is pertinent.

In practice, it’s easy to persuade yourself you have more and more responsibilities. As a senior developer, you are responsible to assist newcomers, but the truth is, any programmer, right from its first day in the marketplace is responsible for helping teammates, in the same way he or she was helping other students at university. What changes is the scope of problems where you could assist. Expertise could differ, but responsibilities are the same, so should be the job title. Therefore, for the rest of this article, I will omit these subtle differences between job titles and focus instead on general job.

A job title says nothing about competence

I am a programmer, like Kent Beck, Martin Fowler, and Andy Hunt are programmers too. Does that means I am as competent as they are? Of course, not. A job title will never make someone competent. It identifies your role in a specific company, trying to solve specific problems for this company, that could be far different from problems people with the same job title solve in other companies.

For example, not all programmers are able to solve the same problems. Saving a form into a database requires different knowledge than implementing the database. In the same way, sending an HTTP request from a web application requires different knowledge than reimplementing the TCP/IP stack in the Linux kernel. Not all lines of code are equal. Cal Newport in his book Deep Work recommends to determine how long would it take to train a new graduate to complete a task? This is the difference between shallow work and deep work. Great programmers implement tasks that would take several years of effort for a new programmer to succeed.

Programmer is not just a job to start your career. You don’t need a new job title to progress in your career, you need more challenging problems. This is why I love my job, and why I am reluctant to move to another position.

A new job title says a lot about incompetence

A new job title will not make you more competent, it will make you less competent. You will have to learn new skills, and except if you are ready to devote sufficient time to learn, you could easily being stuck in an incompetency spiral, changing job title as often as possible. Climbing the corporate ladder does not mean doing a great job.

A new job title is at most the recognition of prior achievements, enough for your manager or a new company to believe you will succeed in a new position. The ladder metaphor is wrong. You are not climbing up to the next rung, you are changing of ladder and starting from the floor again. For example, your brilliant career of programmer will be useful in your new role of CTO, but you are no longer writing lines of code, you Fare managing the complexity inherent for a group of developers to collaborate and produce these lines of code—​leading by example with humility, inspiring with an actionable vision, fostering creativity with bottom-up innovation, developing mutual trust with nonviolent communications—​the fact is, you cannot be competent when starting a new position. You will need to reproduce what helps you in your career so far. Learn. Practice. Reflect. Again.

In addition, no expertise can be built by changing job titles too often. Research shows thousands of hours of deliberate practice, focusing on the hardest parts, are required to reach the top of any discipline (10 000 hours or a decade is often quoted as magical numbers, but it really depends on your discipline).[1] Changing your job titles too often means giving up on this endeavor.

Look for a new job title only if you want different responsibilities and are ready to commit yourself to learning something different. Moving to a management position because you can’t keep pace with the constant changes in software development is not an acceptable option. You will need to learn, maybe even more, if you want to be good in your new role. Choose your job according the problems you really want to solve, and not the problems you want to avoid.

In summary

Before applying for a new position, you have to face a dilemma: pursue in the current direction seeking harder challenges, or switch in a new direction seeking newer responsibilities. Should you go further in the same direction, or move back and fork in a new direction? Only you can answer that question. But don’t let the salary influence your decision because a higher-paid job does not guarantee you to be more "marketable" in the long run. On the contrary, "The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy", says Cal Newport. Business writer Eric Barker, calls this ability to perform deep work, "the superpower of the 21st centur." Deep work should be at the core of your professional life. Maybe stability in your job title is the change you need after all.

About the author

Julien Sobczak works as a software developer for Scaleway, a French cloud provider. He is a passionate reader who likes to see the world differently to measure the extent of his ignorance. His main areas of interest are productivity (doing less and better), human potential, and everything that contributes in being a better person (including a better dad and a better developer).

Read Full Profile

Tags