Don't let your job title stop you

In my last article, I spoke about my journey from "senior" to "junior" developer. Long story short, I saw myself being quite experienced, but only after joining an actual software development company, I came to realise how much there's still to be learned.

Because of that experience, I found myself thinking what does it mean to be a senior developer? What does it mean to be a junior developer? Should we even label ourselves using such narrow definitions? Doing so gives an idea of someone's skills, but the evaluation of the latter can be quite subjective. And that's why I dare to say that one's job title is not enough to define one's skills in the field.

In my eyes, a junior is someone who knows just enough about technology to be able to solve necessary problems. Mostly with others' help. Senior on the other hand is a developer whose analytical and technical skills are sufficient enough to solve any problem at hand(or seek necessary advice). Other developers seek his/her advice and project managers take his/her estimations as the basis for their future plans.

In order to become a senior, one must gain experience in a specific set of technologies. A really simplified career of a developer in a single company could look like this:

• one joins a software engineering company as an intern
• after 6 months becomes a junior developer
• after 1 year becomes a mid-level developer
• after 4 years becomes a senior level developer

Less-experienced developers can ask for tips on how to write code, business people can rely on his/her estimations. Sounds like a senior to me.

It makes sense to give a person a title that show's their experience in the domain. One who's been in a company for 5 years, probably knows a lot about what's going on - both business and technical wise. Less-experienced developers can ask for tips on how to write code, business people can rely on his/her estimations. Sounds like a senior to me. But what if we take the person away from that company? This is where things can go in very different directions.

Let's imagine that throughout his career, the previously described person(from now on, let's call him John) was constantly educating himself by learning the fundamental concepts of technologies used in his company. He also every now and then learned new programming languages and their concepts, was active in the development community and made sure his current knowledge was constantly challenged. When working, he sought to improve his craft and write beautiful, logical solutions. After 5 years, John's skills and experience would've probably been enough to call himself a senior developer, even outside of his company.

Now, let's imagine a different John. This John's goal was to get things done. He knew the tools used in his company very well as he's been working there for a while. He did not care how the methods in his favourite library work, as long as they worked. John also wasn't that keen on learning new languages as they were not used in his company. He did work on small pet projects, but always made use of the same tech stack as in his daily-job. After 5 years, John's probably very experienced and knowledgeable of how things are done in his company. In his company's context, he's a senior developer.

But as we know, in technology things can change quickly and skills learned in the past may not fully be applicable in the future.

When we compare these versions of Johns, we can see one of them being a developer in a sense that he always improved himself, in- and outside of the company's work. The other one saw himself as a developer-only for his company, locking himself to the knowledge only needed for his daily-work. But as we know, in technology things can change quickly and skills learned in the past may not fully be applicable in the future.

I'd like to reveal a secret - in some ways, I've been both versions of John. Not for 5 years though.

When I was freelancing as a teen, my only goal was to get things done. I didn't care about the quality of my code. Nor did I improve myself as a developer. When I got out from the comfort zone and became a developer in an actual company, it hit me that in order to become great at what I do, constant learning and challenging of myself needs to be done. I saw that the world of programming moves so fast that in order to survive, one must try to understand the fundamentals, but also seek new knowledge from emerging discussions, technologies.

...your job title does not define your skills. It does so only in the context of your current company, meaning your employer can only define you by the skills you've used at work.

At the moment, the job title at my company says I'm a front-end developer, as I've mostly contributed to FE. Outside of work, as I'm still freelancing, I'm also a backend developer and a project manager. Ooh, maybe even (as I'm writing this post), a writer. Sometimes I also like to see myself as a software architect. The point here being - your job title does not define your skills. It does so only in the context of your current company, meaning your employer can only define you by the skills you've used at work.

Label yourself with many titles and go beyond your current positions' requirements.

That's why I urge you to (re)define yourself all the time. Think WHO you want to become and act accordingly. Label yourself with many titles and go beyond your current positions' requirements. As a developer, try to learn new languages with unfamiliar concepts; try to understand the basics of your tools etc. Become a senior who knows about various topics, but is an expert in one of them, regardless of the context.