Seniority in Programming: Part Two

17 Nov

Episode 44

Last week, in part one of this article, I was pondering about levels of competence in general and in software development. I looked at mainstream naming schemas, recalled metaphor to medieval craftsmanship, described ranks in Japanese martial arts, presented SFIA skill framework and finally ability’s dots in role-playing game system. Now, let’s try to do something with it. How much levels do we actually want? Well, let’s have four.


  • HR would call it junior developer
  • Sensei would call it 5th to 4rd kyu
  • SFIA would call it level 2 to 3, the one who assists and applies
  • VtM handbook would call it 2 dots, the practitioner

We all have to start somewhere. I’m assuming that this is how we should call a person that begins professional career in software development, and has knowledge usually associated with at least bachelor degree in computer science or closely related field. Apprentice has some theoretical grasp and academic experience, but not much, if any, with commercial projects. Why skip 1st level of SFIA and 1st dot in VtM handbook? Because to be employed as junior developer, you have to know quite a lot. It’s not like random person from the street can get the job and do well after some on-site training. It’s not a damn factory. One need to understand some basics of computer science, and be able to code something. I’m not saying academic degree is a must, because many prominent programmers don’t have one, but some knowledge in the field is a prerequisite.

Apprentices often introduce fresh, outsider look on things and might be up to date in theoretical computer science topics that more experienced developers don’t apply that much in everyday work and therefore tend to forget.


  • HR would call it regular developer or middle
  • Sensei would call it 3th to 1st kyu
  • SFIA would call it level 4, the one who enables
  • VtM handbook would call it 3 dots,  the professional

Journeyman is a professional. It means, that he basically knows what he is doing and has decent commercial experience. You can assume that this person can work independently, does not require constant babysitting and can be trusted with stuff to be done. He has a general idea of many areas of software development, computer science, tools, current technologies, trends, best practices, methodologies and can put all this to practice in a commercial project. Of course it does not mean that he has to know everything, but he should have a common sense in regard to when ask for help: don’t interrupt others too much and too often, put reasonable effort into figuring out the solution alone first. But, on the other hand, know when you are stuck and need help. There is no shame in asking for help, there is shame in stupidly wasting time in a dead end road.

When one becomes Journeyman then? Well, as usual, it depends. Personal skills and talents, project, specialization, organization structure, market maturity, current situation and many more things are a factor here. But in general, I would say that one can be considered Journeyman after somewhere between half and two years of their career, one year being the average. If after more than three years of full time work, people still think of you as a junior, maybe software development is not your thing bro…


  • HR would call it senior developer
  • Sensei would call it 1st to 3rd dan
  • SFIA would call it level 5 to 6, the one who ensures, advises, initiates and influences
  • VtM handbook would call it 4 dots: the expert

Craftsmen are seasoned veterans who have seen a lot. A lot of projects, a lot of development pipelines, a lot of technologies, a lot of approaches, a lot of coffee and pizza, a lot of organization structures, a lot of production environments, a lot of smart people, lot of dumb people, a lot of triumphs and a lot of fuckups. Journeymen are independent at task levels, Craftsmen are independent at project levels and you probably need at least one to be on your team, unless the project is really small or simple. Craftsmen devote some time to mentor less experienced developers, organize things, lead, share knowledge, broaden their contact network, and act as a glue for different aspects of software development aside from coding – business, operations, organization or public relations. As of coding, they solved a lot of problems, so when a new one arises, they can leverage all their experience and discipline in methodical approach to conquer it. They see beyond their task or sprint and care about the project future and its surroundings. They understand business needs and can select right technology to fulfill it. They are not afraid to say “no” to someone above them, if needed.

When one becomes Craftsman? Depends, as always. I’ve seen people, who were still at university and had less than two years of commercial experience, awarded title of senior. I got mine shortly before I hit five years, and it seems to be, more or less, a standard in my environment. People tend to get it faster in certain technologies and when working in their first company for a long time, because they know their project and organization very well and can move fast. Generally speaking, I feel that one become software Craftsman after four to seven years of work, both in the office and after hours.


  • HR would call it lead or principal developer
  • Sensei would call it… Sensei. 4th dan and beyond
  • SFIA would call it level 7, the one who sets strategy, inspires and mobilizes
  • VtM handbook would call it 5 dots: the master

After years of  perfecting the craft, one may become master at it. Lead developer is sometimes a bit confusing title, as it may refer to permanent, linear hierarchy in the company, or might be a role assumed on per project basis. But considering in seniority scale, lead developer, or principal developer is a person who sets example, both technical and organizational, creates high level strategies, possess deep understanding of various technologies, not only from their domain. As a leader, excellent soft skills play as important role as technical mastery. Master Craftsmen have autonomy on company level, understand products landscape, they can create architecture for huge projects, implemented by hundreds of people, act as mediators between teams, ensure good practices, common understanding and proper degree of independence. They can save doomed projects and work on every level of software development, be it writing the actual code with the team or talking with CEO about the company vision. They are practicing thought leadership – speaking at top level conferences, writing books and mentoring senior developers.

When one can be called master? Perhaps never. Most people will likely end their career at Craftsman level, because they don’t want all that fuss with leadership, responsibility and public appearances. Don’t get me wrong, people can choose many paths and be great at what they do. But I fell, that you can’t be called lead or principal if you sit closed in a cellar writing your perfect code alone in the darkness. You can’t lead people from behind the firewall only. If you keep asking me about the numbers, I would say it takes at least ten to fifteen years to get there.

Chasing the rabbit

This is just my idea of seniority in software development, you can have a different one, your company may have a different one. This is also an approximation. People are great at some aspects and disastrous in others. You may know someone who has captivating charisma and gives enchanting talks, but writes crappy code. You can have geniuses who can solve any technical problem, but creeps out anyone who approaches them. And a spectrum of people in between.

At one of Aikido seminar I’ve been to, seventy year old 6th dan Shihan once smiled to us, a bit puzzled, and said:  “listen, I thought I know how to do this technique, but I was wrong for fifty years. It’s different…”. I would love to be able to say the same about software development when I’m seventy.

Happy rabbit chasing, and see you next week!



Posted by on November 17, 2016 in Misc, Recruitment


Tags: , , , ,

2 responses to “Seniority in Programming: Part Two

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: