Experience, they say, is the best teacher, and the more experience you’ve had, the better you would be at handling a certain task. This, however, begs the question: Just how do you measure it? Well, as a software engineer at least, experience is not determined by the number of years you’ve been one. In fact, let’s ditch that misconception forever: just because you've been a developer for 15 years does not necessarily mean you're a Senior developer.

Let me illustrate why I say this without doubt: If within a 10-year period, developers just sit at their desk, working on the same old technologies in a static company, what they will be after 10 years would be older junior developers, and not exactly developers with the right experience.

What we need to understand is that the market is not static. Technologies evolve, and so do the ways we develop software. In that environment, it’s not possible to simply learn a single thing and then use it for the rest of one’s career. The next 5, 10 or 15 years a software engineer spends working with that limited knowledge would take him or her nowhere near a senior position.

Whether developers like it or not, or whether they are even aware of it or not, there is always a kind of competition among them. The moment a developer stops improving existing skills and learning new ones, his or her value will depreciate quickly, left behind by those who expand their range. Such is the industry we work in, and the sooner developers acknowledge the need to constantly hone their abilities, the sooner they can work their way up to higher levels.

Pay does not necessarily equal value

Ideally, you cannot ask for more money if you do not bring more value to a company or a customer. In reality, however, some companies may pay more, either because they don't know the value of their software engineers, or because they have an overabundance of resources; not necessarily because these developers are better. The market also evolves and this could lead to a particular language becoming rare or sought-after. When this happens, developers who have mastered this skill or language stand to earn more, but that doesn’t mean they have learned something new that will be valuable to their next employer.

The danger is in software developers falling into a sense of complacency where they think that their pay scale is a measure of their technical level, and hence, they no longer seek to acquire additional knowledge. To summarize: Just because one is well-paid does not mean that he or she is actually good and worth that income.

“Do not confuse motion and progress”
~ Alfred A. Montapert

Assessing your value as a developer

Following the law of compensation written by Ralph Waldo Emerson a long time ago, your value as a developer depends on three aspects:

• The NEED for what you do. (Can't control; hard to predict)
• Your ABILITY to do it. (Within one’s control)
• The difficulty of REPLACING you. (Consequential of the other two)

Of the three, the first aspect is the one that is completely beyond the control of the professional. It is the market that decides if a certain job or industry has a higher demand or thrives more than another. The third factor is dependent on the other two. If there is a need for one’s abilities, and a person is good at what he or she does, then there is an assurance of a decent job at all times.

Thus, it remains that the only thing you can directly act on is your own skills and capabilities. No one should be content with just doing the same things over and over again. Just because a developer has been slinging code for years doesn’t automatically warrant ‘seniority’. There should be a plan and effort for continuous improvement. To improve, it is fundamental to understand what your "value" is in the industry you belong to, and then strive to increase it. Even if you aim poorly, it’s still better than doing nothing and going nowhere.

As I recently explained in the clean coding presentation, a software company does not and should not calculate the value of a developer by just counting the number of lines of code written and looking at the resulting complexity. Complexity, in fact, is expensive for a company. Instead, developers who write simple, readable code that is easily maintainable, provide more value to the team.

One might argue that the very basic requirement should be a working software, and that is true to some extent. But these days, there is the need to offer more value to the organization. We developers should not be content with just producing code because that is only the start.

Rising up the software engineering career path also requires developing other capabilities. Some people have the tendency to focus on only one aspect of their skillset. For instance, the most logical for a developer would be upgrading programming skills and technical knowledge. But the truth is, you can rarely excel at a software engineering job without building a full range of competencies—this includes soft skills such as communication and social skills, as well as some periphery skills including business and marketing abilities.

Skill levels in software development

Knowing where you stand in your knowledge as a developer is the first step in planning for your skills improvement. Below, I give a description of the three levels of progress for a software developer.

Junior software developer

Starting their journey in the development world, junior developers first have to deal with the logic behind programmation like loops, variables, conditional statements, and memory management.

Then they learn the syntax of their preferred language, learn some code formatting, and work on how to implement basic algorithms like string and array manipulation, sorting, and searching. If they branch into web development, they also need to understand how the network works, study about protocols like HTTP, and learn what an API and a hosting platform are, among others.

Further along, they have to fully understand the differences between compiled and interpreted code; between procedural, functional, and object-oriented programming; between synchronous and asynchronous execution; and learn about basic security principles. Knowledge of all these will help them choose the language they prefer to work with the most.

The points below define the tasks of and expectations from junior developers:

• They don't yet see the difference between writing code and development; they focus solely on writing code.
• They are given specific tasks which they can execute at their level, and create working software under the close supervision of more senior developers.
• They often need a lot of time and help from other developers to solve problems that they may encounter.
• They are not yet autonomous and have difficulty tracking down a problem to its root, and fixing it.
• They know basic algorithms (e.g. searching, sorting), string, and array manipulation.
• They know how to access a database or an API and read/write data.
• The code they produce is barely maintainable, readable, and reusable. There are no abstraction layers and the code is piled up in the same file or class (oftentimes in the controller). Reusability is achieved by copying and pasting code, ignoring the DRY principle.
• A junior developer will fail to consider special cases—the list is empty, the client is offline, the input is incorrect, etc., and their code will crash as exceptions are improperly handled.
• Consequently, they produce code with frequent quality problems.

Mid-level software developer

As developers progress in their careers, they will begin learning from their mistakes. They will start getting an appreciation of the bigger picture, and understand that programming is not about writing small pieces of isolated code. Rather, it's about interactions, patterns, and layers of abstraction. Mid-level developers will start to learn these, and hence, are defined by the following characteristics:

• They now keep in mind that they have to be able to understand their code when revisiting it in a year and recognize that this is a very basic feature of maintainability. They learned that from having to maintain their old code.
• They know how to build a software, not just how to type code. They start to understand that their work is more than just producing lines of code.
• They see patterns in failures and are learning from them. They don't always know how to fix those issues yet, but at least they can feel it when something is going downhill.
• As they have just discovered design patterns, these are often misused or overused which can lead to over-complexification.
• They start learning the theories of software architecture but still cannot actually apply them.
• They start building good mental models of the tools and techniques they use.
• They can develop a software that is going to last for a longer time but can suffer from other disasters later down the road (bad performances, rigidity in architecture and infrastructure, code that’s not reusable, overlooked needs that beget a rewrite, etc).
• Mid-level developers often want to rewrite everything. This is because even though their code is good, their architecture is not yet polished and they still overlook many aspects of development like abstraction layers, single-responsibility principle, and strong coupling, among others.
• They can identify problems and search for good solutions with less supervision.
• They test the functionalities of their code, including the most obvious special cases. The tests though, may still be lacking in quality and many bugs could still appear because not all data flows are explored and validated.
• They discover that automated tests save them a lot of time and headache.
• They still have a hard time figuring out the business value of their work, and how to translate it in an efficient manner for the client’s benefit. This means they lose a lot of time doing useless work and typing useless code just for the sake of fun, learning, or simply because they don’t get it.

Senior software developer

A senior developer should already have the ability to fully deliver a solution. They have a better appreciation of the work in its entirety. They can ensure the quality of the entire code base rather than just their own code. They have the ability to move their team in the same direction towards a defined goal. While not all senior developers have the skills or insight to clearly define that goal, most of them have a good idea of the general objectives that they are working towards.

Senior developers are designated as such because of the following traits and responsibilities:

• They are the project leaders, and are respected for their technical knowledge, and at times, leadership capabilities.
• They interact with both management and customers. They should therefore, be able to translate technical discourse into terms that are understandable by mere mortals.
• They have developed a business mindset and an understanding of the client's needs. They also have a good appreciation of the value that the solution or application being developed brings to the customer.
• They can organize and moderate collaborative work and activities like pair programming, mutual code reviews, and discussions on technical issues or concepts.
• They can teach others the art of software development.
• Senior developers are able to architecture an application from start to end and, see the long-term consequences of architectural choices such as obsolescence, scalability, development speed, maintainability, reusability, performances, and others.
• They are able to give accurate estimations of a project, and review estimations made by other developers.
• They understand why projects fail and are able to preemptively provide suggestions to avoid that.
• They can perceive the difference between theory and reality, and are not romantically bound to concepts that are not applicable in the current context. They know common programming patterns, but more importantly, they know when NOT to apply them.
• They know how to adapt certain theories to give them more value.
• Contrary to lower-level developers who seek complexity, senior developers are obsessed with simplicity. Complexity for its sake is not fun for them anymore.

Moving forward in your career as a developer

Obviously, as stated in the article of Matt Briggs, the given outline of essential features for each level is an over-simplification of the respective roles of developers, whatever category they belong to. The reality is that, a software engineer’s career can take many different roads. Some will prefer becoming an architect, others like the business side, and a few will move towards the position of CTO. Some developers may also eventually choose to teach and/or write.

Still, I think it’s important to provide a seniority roadmap and define the expectations that companies would have in hiring and job promotion decisions. This post will also help software engineers determine the potential responsibilities that may be given to them if they were to join a business organization, bringing with them their current skills. They should now have an idea of how much they still need to learn (or experience, in the real sense of the word), to be able to make it up the seniority ladder.

I hope that if you, dear reader, are sitting at your desk and have been using the same old technologies during the last 5 or 10 years, this will give you a wake-up call. It’s a hard necessity to grow, but once you do, you will appreciate the fruits of your efforts.

Looking for new careers opportunities as a software developer? Let's talk. Check open jobs and apply online.