Coder -> Programmer -> Architect?

Question

Career in IT

background

In one of the reports at a small it-conference, the gradation of the development of a programmer by the level of problem solving was once described (the wording is inaccurate from memory):

1. Написание кода - когда руководитель дает четкое описание, которое нужно перевести в код, со входными и выходными данными
   
2. Решение небольших задач - когда необходимо самому продумывать способ решения данной задачи (это может быть метод, модуль и т.п.)
   
3. Решение задач бизнеса - когда нужно спроектировать решение проблемы бизнеса, взаимодействовать с людьми вовлеченными в это, на выходе может получиться не просто модуль, а отдельный проект со своими правилами
   
4. Решение задач пользователей - планирование развития программного продукта, взаимодействие с большей аудиторией.
   
5. Решение глобальных задач - то, что "меняет мир", написание инструментария, платформы для решения более широкого списка задач
   

From this it follows that if the level of "writing code" means a coder, the level of "problem solving" - "programmer", then the next level - "solving business problems" - will correspond to "architect".
Is the programmer-architect transition a consistent career path?
How is this development taking place? Some advise to change jobs frequently to try different projects in different subject areas, study them and draw understanding of architecture from there. But this method is not for everyone.
It is also obvious that good technical training alone will not be enough to build an IS architecture for business from scratch.
What additional knowledge is needed for this and where / how is it most effective to get it? In which direction to google, where to start?

Answer 1

An architect - first of all, experience, ideally in different projects, in order to understand in practice the difference between the implementation of different SDLCs.
The name Waterfall or Scrum are just names with no specific implementation. You can implement a great Waterfall and everyone will be happy, you can implement a terrible Scrum and everything will fall apart. Therefore, the experience of different projects helps to see exactly different implementations.
The architect, business analyst and manager are the three links that form the basis of the project, each in its own way.
Business analyst - must understand the customer's business as much as possible in order to understand the meaning of the requirements and translate them for performers.
The architect must have at least a little understanding of the business, but his main task is to decide how to embody the requirements of the business. Determine hardware, technologies, requirements. To say that "for this you need to use 10 of this and 20 of this, and use such languages, libraries, paid solutions." Technical hi-level vision of the project.
Manager - in agreement with the business analyst and the architect, he must resolve personnel issues. The number of people, the quality of the people, the work of the team, the timings, the office and the equipment are all monetary matters. Reports. Negotiate, convince the customer about prices and terms. Knock out new tasks and develop the project. Monitor team spirit.
The programmer-architect transition is not always consistent. It must be initiated by the programmer.
A programmer can remain just a senior programmer, can become a team lead, spending part of the time on team management, but still leaving most of the time for coding.
But coding cool stuff and at the same time being an architect who spends a decent amount of time on rallies is difficult. Therefore, the programmer - the architect is connected, but not always consistent.

Answer 2

The coder is just a jun.
A guided creature, which in no case should be allowed into an area free from control, otherwise it will encode such that it will be re-encoded later.
Architect - I don't know where you've been reading. Any developer with experience is an architect in one way or another. In today's highly competitive world, few firms can afford to keep dedicated architects. In the vast majority of cases, the architect is the same developer.

Answer 3

There is no difference between a coder and a programmer. Whether a person will do according to the finished TK, or will think with his own head - it does not matter, he remains a programmer.
Architects do not solve business problems. These are exactly those people. that bring TK to coders to work with. Business tasks are solved by managers and some team leads, and the first ones do not need to be able to write programs at all.
Additional knowledge for an architect depends on the field of work. If you're an architect somewhere at SpaceX, it's understandable that you need to know the science of physics and how your devices work. And so you don’t need to know anything else, any programmer can become an architect if he has a couple of his own projects that are unusual and which he designed himself

Answer 4

In the last 2 years, I only see the absence of an architect in the team, but for me this is a key link without which chaos often happens. Many companies neglect architects trying to save money.

Answer 5

Is the programmer-architect transition a consistent career path?

Yes.
In the direction of understanding processes and creating databases. (this is at the very beginning)
Then - the creation of schemes for the movement of data through the nodes of the infrastructure.
And calculations of loads and bottlenecks in the system.
After - already to the construction of classes and the study of design patterns.

Answer 6

Usually there is no position of an architect and his duties are performed by senior programmers together when they come to a rally and discuss architecture. The smartest one makes an initial project plan, and then, during a joint discussion, something can be added or removed. And such joint discussions in large projects take place every week so that everyone is aware of the architecture, and not just the architect.
Those. a programmer rarely becomes an architect, since such a vacancy is very rare and usually growth occurs in two ways:
1. programmer, senior programmer (senior), technical director. department.
2. programmer, project manager, product director.
In the first option there is more technical work, in the second option there is more finance and business. At the same time, in both options, top positions have a lot of communication with people.

Answer 7

I have a personal description of the levels of a programmer, similar to the indicated gradation:
- Junior writes the code as he understood the customer's task
- Middle writes the code in such a way as to solve the customer's task well and correctly
- Senior writes in such a way as to make the customer's future task (so that the project code was ready for future tasks, without rewriting the entire project from scratch)
Signor has experience and understands what will be needed in the future in the project (if necessary, he will ask, if not, he will guess). It is the signor who can be an architect who deals with the infrastructure of the project so that other programmers reuse the already finished parts of the project.
Middle also has developed architecture design skills, but often works with medium and large features (parts), and not with system things.
Junior does small tasks, his architecture skills are related to one or more related classes for the current task. A good manager pushes things a little harder to give you the opportunity to practice your architecture.