Skip to main content

Engineer Levels

Let's talk about the levels of engineers in a company.

Stage 1: Developer(Coder) vs Engineer​

Engineer vs Developer

Developer (coder) - is a person who writes code to solve a problem described by someone else, and does it in a way described by someone else. Engineer - is a person who recognizes a problem, describes its essence and consequences, and proposes a solution that they can implement themselves or with the help of other resources.

With the emergence of artificial intelligence, we often hear opinions that AI will replace all specialists in our field. This is not true. AI can only replace coders, but not engineers. While AI can easily solve a described problem in a prescribed way, it cannot recognize problems globally in a project or propose solutions that depend on many other factors.

Why is it beneficial for businesses to move away from coders and look only towards engineers? Since coders' work can be easily replaced by having an engineer who knows how to use AI, businesses get someone who will recognize problems, find solutions, and resolve these problems either independently or with the help of artificial intelligence. Artificial intelligence costs much less than coders' salaries - therefore, it's quite profitable to give part of the money saved on coders to the engineer and keep the rest.

I believe that the modern software development world should move away from the terms coders, programmers, developers, and replace them with the term engineer.

Stage 2: Engineer Levels​

Engineer Levels and Areas

For me, there are two ways of describing the level of engineer. The first one in long, but well describred on the Career Ladders. The second on is short and simple, but it's enough to understand the difference between levels. I am actually going to describe this one.

The main difference between engineers of different levels is their area of focus and responsibility. I want to emphasize that an engineer of any level should be able to recognize problems, find solutions, and know how to resolve them. An engineer of any level should do this with high quality and should be able to do it quickly. The difference is that the higher the engineer's level, the larger (broader) their area of responsibility becomes. There's no need to consider a junior specialist as just a coder. We should consider everyone as engineers, treat everyone as engineers, and look only for engineers, not coders.

  • Engineer I - their scope is a task (according to Scrum task gradation). That is, they find problems in a very narrow area, know how to fix them, and successfully implement solutions.
  • Engineer II - their scope is an epic. That is, they deal with problems in an area that includes several tasks/features, which can be an entire system module.
  • Senior Engineer - their scope is the project. That is, the problems they raise are global problems. The importance and criticality of these problems are often very high.
  • Staff Engineer - their focus is on company goals. That is, they deal with problems that affect the entire company. They work on problems that impact

Stage 3: Engineer Areas​

Engineer Growth in Width

A modern software engineer should strive to go beyond the boundaries of their primary area of responsibility. Often, developers, especially those early in their careers, focus solely on completing tasks directly related to their role—whether it be frontend, backend, or another specialization. However, in practice, this limits opportunities for growth and project success.

The provided illustration shows the difference between the narrow approach of a frontend developer, who works exclusively on the client side of the application, and the broader approach of a frontend engineer. The latter not only focuses on their specific responsibilities but also actively engages with other areas of development: design, DevOps, business analysis, support, testing, and the server side of the application.

The task of a modern engineer is not only to solve immediate tasks but also to proactively identify problems and offer solutions in related areas such as UX/UI, code quality, backend integration, or security. This helps establish better communication between teams and prevents potential bottlenecks in development.

For example, if an engineer notices that a solution proposed by the UX team causes a load on the backend or complicates testing, they should bring it up. This approach not only improves the overall quality of the final product but also contributes to its stability and efficiency at all stages of development and deployment.