software architect

src: Are You an Architect?

Traits of a software architect

Over twenty five years ago, in 1992, at an OOPSLA workshop in Vancouver, Kent Beck, in answer to the question “What is an architect?” said, according to Philippe Kruchten, that it is “a new pompous title that programmers demand to have on their business cards to justify their sumptuous emoluments.” Not much has changed since then. There is a big difference between a smart programmer and a project architect. Here is a list of traits that, I believe, a good architect has.

No Country for Old Men (2007) by Coen Brothers

Disclaimer: Even though I haven’t seen a single female software architect in my life, I have to say for my leftist/feminist readers that in this blog post I’m assuming an architect is a man only for the sake of convenience of speech. There is no intention to offend anyone.

He Is Loyal

Programmers come and go. They are, as I mentioned many times before, egoists with a strong focus on their personal profit. They change projects, they work on multiple projects at the same time, they have no personal attachments to any piece of code. They worry only about their individual tasks and feature branches. The branch is merged? All bets are off. Professional developers are “polygamous” and disloyal.

An architect, however, is a different creature. He stays with the project even after it runs out of funds, loses the last programmer, and proves that the architecture is a total mess that can’t handle even a fraction of the traffic it was supposed to work under. The architect stays and says “No worries, we’ll get through, no matter what!” How to find such a guy and how to motivate him are different questions, maybe for another blog post.

He Is Disciplined

Design patterns, quality of code, static analysis, unit testing, high performance, reliability, security and even maintainability are all very important things to worry about. However, a good architect knows that all these can be resolved and achieved by programmers, if they are properly hired, motivated, organized and controlled. How to hire, motivate, organize and control them—that’s what a good architect worries about.

He knows that process comes first, people next.

An architect puts discipline on top of everything else, constantly inventing new rules and enforcing them.

However, this is not what most software experts think. For example, according to Alistair Cockburn’s article Agile Software Development: The People Factor published in IEEE Computer in 2001: “If the people on the project are good enough, they can use almost any process and accomplish their assignment. If they are not good enough, no process will repair their inadequacy—‘people trump process’ is one way to say this.” It is acceptable if a programmer thinks like that, but not an architect.

An architect puts discipline on top of everything else, constantly inventing new rules and enforcing them. Moreover, he is not only making others obey, but also following the rules himself. Here, for example, are the rules to enforce:

No changes without a code review;
Every idea starts with a ticket;
The master branch is read only;
Static analysis is mandatory;
No singletons, no getter/setters, and so on;
Unit testing is mandatory for all new changes;
No informal discussions outside of tickets.

Each project has its own set of rules. The list above is a subset of what we have on our projects at Zerocracy. A good architect thinks about the rules first and about the architecture second.

I totally agree with Len Bass that “the architecture should be the product of a single architect,” as he said in his book Software Architecture in Practice. The question, however, is how exactly the architect will create the product: either in solo mode, making all technical decisions alone, or letting the team contribute in an organized and disciplined manner. The former is easy but less effective, the latter is way more difficult, but leads to much stronger solutions and better team synergy (I hate this word, but here it fits well).

He Is Strong

Matthew McBride said in his article The Software Architect, published in CACM in 2007, that “Without strong supervision from the software architect, projects and attempted solutions tend to fall apart due to the weight of unmitigated complexity.” The word strong is what is important to emphasize here.

The strength of an architect is in the ability to say “No” when it’s difficult to do so.

What does strength mean in this context? An ability to stay in the office two days straight with just pizza and cola? An ability to multiply six-digit numbers in memory? An ability to memorize the purpose and design of all classes and methods? An ability to stay in a meeting with investors for three hours without checking Facebook even once? Not likely.

The strength of an architect is in the ability to say “No” when it’s difficult to do so. For example:

“No, I will not merge your pull request”;
“No, we will not implement this feature”;
“No, you do not deserve a promotion yet”;
“No, your code is not as good as we expect”;
“No, this build is not stable enough to be released”;
“No, you will not go on vacation this month.”

There are many other instances of “No” which can easily turn an architect into a hated figure, but this is what his job is: to be the bad guy. This is why he has to be strong—to handle it all calmly and continue leading the project forward, toward his own well-defined technical goals.

He Is Abstract

Abstract thinking is a very important positive trait of an architect. Programmers may lack that, since they are mostly focused on their own isolated tasks. An architect must think globally and see the product as a whole. Details are less important. He must rely on his people when talking about details.

Software is a product of people. No matter how great the architect is, if he can’t find the right people to implement his ideas and to bring back new ideas, he is doomed to fail. The key quality of the architect is the ability to work with people: recruit, motivate, and control their results. Social skills are what an architect needs in order to be successful in that, especially in finding new programmers and engaging them on the project. What exactly does this mean? Well, here are some examples:

High visibility in social networks;
A long list of previous projects and teams;
Active membership in professional groups;
Publicity in the blogosphere.

In other words, a good architect is the one with a big group of followers and supporters around him. I mentioned that in my recent talk How Much Do You Cost? at JEEConf 2017.

He Is Brave

A good architect says many times a day: “It is my fault.” If an architect doesn’t have a habit of saying that frequently, he is not a good architect. He is just a programmer who is afraid of responsibility and authority.

The golden rule of a good manager is: “Success is yours, faults are mine.” This is the attitude a good architect has to express to his team. When they win, he will always find a way to celebrate and reward them. When they fail, he will take full responsibility for the failure. Because it’s his team, he found them, he motivated them, he controlled them, and he didn’t punish them properly. That’s why they failed. First of all, it’s his fault.

He didn’t punish them properly. That’s why they failed. First of all, it’s his fault.

What will he do with this fault is a separate question. Maybe he will train and coach someone, maybe he’ll enforce some rules more aggressively, maybe he will even give someone his card. It’s up to the architect. But for the outside world he will always be the guilty one and the team must know that. If they know that, they will do everything to not let the architect down.

He Is Simple

“Simplicity is a great virtue,” said Edsger Dijkstra in 1984. For a programmer it’s a virtue, for an architect it’s a survival skill. An architect who can’t explain his ideas in simple words, easily understood by other programmers, is not an architect. No matter how smart he is, no matter how bright his ideas are. If they can’t be delivered in a simple form, they are worth nothing.

“If I don’t understand you, it’s your fault” said Yegor Bugayenko in 2015. A good architect remembers that.

He Is Coding

Anthony Langsworth in his piece Should Software Architects Write Code? argues in favor of code-writing architects and in particular says that “Understanding code means the architect can use his or her judgment more effectively rather than rely on which developer is more persuasive.” Indeed, an architect that is only capable of talking and drawing is a weak architect that will sooner or later let the team and the project down.

How much code the architect has to write, depends on the age of the project. When the project is young and is still in the phase of prototyping, the architect produces the majority of code. Then, later, when the product matures, the architect steps away and mostly reviews the contribution of programmers. Eventually, when the project migrates into the maintenance phase, the architect may quit the project and transfer his responsibilities to one of the programmers.

A good software architect writes code every day! codeahead

— Yegor Bugayenko (@yegor256) October 14, 2018

He Is Ambitious

An architect does want to get something in addition to money. He wants to be the smartest guy in the room, he wants to solve complex tasks nobody else has been able to solve before, he wants to save the world. He wants all of that to be appreciated and rewarded. He wants to be number one. In most cases he fails miserably. But he always gets back on his feet and tries again. Look for the guy with ambitions if you want to hire an architect, not just yet another programmer.

An architect wants to be a man of power, not just a smart technical engineer.

Michael Keeling, in his recent book Design It!: From Programmer to Software Architect (worth reading), says: “On some teams, architect is an official team role. On other teams, there is no explicit role and teammates share the architect’s responsibilities. Some teams say they don’t have an architect, but if you look closely, someone is fulfilling the architect’s duties without realizing it. If your team doesn’t have an architect, congratulations, you’ve got the job!”

Michael’s point is that the architect’s position is rarely given to someone voluntarily. Instead, an architect has to fight for it and demand it. Sometimes even going straight ahead and saying “I want to be the architect!”

What is important is that it will not sound like “I want to architect this.” That would be the voice of a programmer, not an architect. An architect wants to be a man of power, not just a smart technical engineer. So, it’s way more about a title for him, rather that just his actual responsibilities.

He Is Expensive

Yes, the money question again. A good architect is expensive. If he is not, he is not a good architect.

src: Are You a Software Architect? - InfoQ

Line between software development and software architecture

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn’t exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it’s a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there’s a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole. While this may help to differentiate software development and software architecture, it doesn’t necessarily help to understand how somebody moves from development into architecture. Furthermore, it also doesn’t help in identifying who will make a good software architect, how you go about finding them if you’re hiring and whether you are a software architect.

Experience is a good gauge but you need to look deeper

Becoming a software architect isn’t something that simply happens overnight or with a promotion. It’s a role, not a rank. It’s an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role.

There are a number of different qualities that you can look for in a software architect and their past experience is often a good gauge of their ability to undertake the role. Since the role of a software architect is varied though, you need to look deeper to understand the level of involvement, influence, leadership and responsibility that has been demonstrated across a number of different areas. Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it’s delivered.

Definition of the software architecture

The architecture definition process seems fairly straightforward. All you have to do is figure out what the requirements are and design a system that satisfies them. But in reality it’s not that simple and the software architecture role can vary wildly depending on how engaged you are and how seriously you view your role. As the following diagram shows, the architecture definition part of the role can be broken down further into a number of different elements.

The role of a hands-on software architect from a definition perspective

Management of non-functional requirements: Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) they need. Sometimes the stakeholders will tell us that “the system must be fast”, but that’s far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them. Most of the non-functional requirements are technical in nature and often have a huge influence on the software architecture. Understanding the non-functional requirements is a crucial part of the role, but there’s a difference between assuming what those requirements are and challenging them. After all, how many systems have you seen that genuinely need to be operational 24x7?
architecture definition: With the non-functional requirements captured, the next step is to start thinking about how you’re going to solve the problems set out by the stakeholders and define the architecture. It’s fair to say that every software system has an architecture, but not every software system has a defined architecture. And that’s really the point here. The architecture definition process lets you think about how you’re going to take the requirements along with any imposed constraints and solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. Defining architecture is your job as a software architect but there’s a big difference between designing a software system from scratch and extending an existing one.
Technology selection: Technology selection is typically a fun exercise but it does have its fair set of challenges when you look at cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple task of choosing something like a rich client technology into a complete nightmare. And then there’s the question of whether the technologies actually work. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. Technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. If you’re defining an architecture, you also need to be confident that the technology choices being made are the right choices. Again there’s a big difference between evaluating technology for a new system versus adding technology into an existing system.
Architecture evaluation: If you’re designing software, you need to ask yourself whether your architecture will work. For me, an architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and provides a sufficient platform for solving the underlying business problem. One of the biggest problems with software is that it’s complex and abstract, which makes it hard to visualise the runtime characteristics from UML diagrams or the code itself. We undertake a number of different types of testing throughout the software development lifecycle to give us confidence that the system we are delivering will work when rolled out. So why don’t we do the same for our architectures? If you can test your architecture, then you can prove that it works. And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best.
Architecture collaboration: It’s unusual for any software system to live in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to other stakeholders who have an interest from a security, database, operations, maintenance, support, etc point of view. For a software project to be successful, you need to collaborate closely with all of the system stakeholders to ensure that the architecture will successfully integrate with its environment. Unfortunately, architecture collaboration within the development team seldom happens, let alone the external stakeholders.

Delivery of the software architecture

It’s the same story with architecture delivery too, where the software architecture role can vary depending on the level of engagement across the elements that contribute to a successful software project.

The role of a hands-on software architect from a delivery perspective

Ownership of the bigger picture: In order to carry the architecture through to a successful conclusion, it’s important that somebody owns the big picture and sells the vision throughout the entirety of the software development lifecycle, evolving it throughout the project if necessary and taking responsibility for ensuring that it’s delivered successfully. If you’ve defined an architecture, it makes sense to remain continually engaged and evolve your architecture rather than choosing to hand it off to an “implementation team”.
Leadership: Owning the bigger picture is one aspect of technical leadership, but there are other things that need to be done during the delivery phase of a software project. These include taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions. As the architect, you need to undertake the technical leadership to ensure everything is taken care of and that the team is being steered in the right direction on a continuous basis. The software architect position is inherently about leadership and while this sounds obvious, many project teams don’t get the technical leadership that they need, with architects assuming that a successful delivery isn’t necessarily their problem.
Coaching and mentoring: Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about steering the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people’s skills and to help them improve their own careers. This is something that should fall squarely within the remit of the software architect, and clearly there’s a big difference between coaching your team in architecture and design versus helping them with their coding problems.
Quality assurance: Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect’s role, but it’s more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It’s safe to say that most projects don’t do enough quality assurance, and therefore you need to figure out what’s important and make sure that it’s sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can’t necessarily assure everything, doing something rather than doing nothing.
Design, development and testing: The last thing that falls squarely within the role of a software architect is design, development and testing. Being a hands-on architect doesn’t necessarily mean that you have to get involved in the day-to-day coding tasks, but it does mean that you’re continuously engaged in the project, actively helping to shape and deliver it. Having said that, why shouldn’t the day-to-day coding activities be a part of an architect’s role? Most architects are experienced coders, so it makes sense to keep those skills up-to-date. In addition, the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in coding activities because their architects are “too valuable to undertake that commodity work”. Clearly this is the wrong attitude … why let your architects put all that effort into defining the architecture if you’re not going to let them contribute to its successful delivery? Of course, there are situations where it’s not practical to get involved at the code level. For example, a large project generally means a bigger “big picture” to take care of and there may be times when you just don’t have the time. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines.

Are you a software architect?

Regardless of whether you view the line between software development and architecture as mythical or a gaping chasm, the elements above highlight that people’s level of experience across the software architecture role varies considerably depending on how engaged they are and how seriously they view their role. Most developers don’t wake up on a Monday morning and declare themselves to be a software architect. I certainly didn’t and my route into software architecture was very much an evolutionary process. Having said that though, there’s a high probability that those same developers are already undertaking parts of the software architecture role, irrespective of their job title.

There’s a big difference between contributing to the architecture of a software system and being responsible for defining it yourself; with a continuum of skills, knowledge and experience needed across the different areas that make up the software architecture role. Crossing the line between software developer and software architect is up to you, but understanding your own level of experience is the first part of the journey.

src: The Path to Becoming a Software Architect | by Nikolay Ashanin | Medium

The path to become a software architect

Have you ever wondered what career opportunities a developer has? What directions are open, beyond what horizons to grow. And most importantly, where are developers beyond the age of 45? Is there a developer among your friends who is over 45? I know several developers beyond this age, and many of them are hardcore programmers who even saw punch cards back in the day.

There are several career paths a developer might take:

● The first and obvious one is to grow in the area in which you are working. If you are a junior developer, then become to middle, then senior and lead roles.

● Transition to another technology stack. A significant number of developers moved into the mobile area when iOS and Android OS gained ground.

● Grow into a manager role. As a developer, the hugest staffing issue I saw was the shortage of competent managers. Smart managers are expensive, hence they are scarce. If the manager has a technical background, that will allow him to be on the same wavelength with the developers.

● Become a software architect. This direction will be considered in this series of articles.

● Get out of IT. Sometimes this happens. It is never too late to do what you like to do.

Article series

Yes, This Was My Path

In the past eight years, I have worked with Java EE, then moved to iOS, and became a team lead. I managed various developer teams, including Android, and Web stacks. Created the architecture of the network layer for several services developed by the company, with sockets and REST API. I became acquainted with the managerial role and the prospect of growing in this direction while in the position of team lead for over two years. In my next role, my goal is to grow as a software architect.

For most developers, the function of the architect on the project is often unclear, so in this series of articles, I will try to find the answers to these related questions. Who is an architect, what is the scope of responsibilities, and how to grow in this direction and outline an action plan for myself and beginners wanting to move along this path?

Who Can Benefit from This?

This series of articles will help you if you belong to one of the following categories:

● IT developer or engineer. You are still growing as a developer, but you are looking ahead and planning your career. Even if the goals are initially vague, a person who consciously sets strategic goals will reach them much quicker than a person who does not plan where she is heading.

● Team leader, lead software engineer. You are at the highest stage of the software development discipline. To grow further, you have a choice to either learn one more stack of technologies, pursue a career outside software engineering, or to become a software architect.

● Software architect. You recently took this position, or have been working in this field for a long time. Perhaps one of the main qualities of such a specialist is the understanding that there are always areas that a person does not know and that the learning process is continuous.

● IT manager. Although you are a manager, you understand perfectly well that you should at least approximately understand what your subordinates or colleagues are doing. The acute problem of management is the technical incompetence of the manager in the field in which he or she is managing.

Who is an Architect?

Before moving on to more specific questions, it is necessary to define the software architect role and responsibilities.

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect. (Wikipedia, The Free Encyclopedia, s.v. “Software architect”, https://en.wikipedia.org/wiki/Software_architect

Like most high-level positions, there are no clear criteria that define this role. However, it is possible to identify several responsibilities and qualities that contribute to the career of the architect.

First, let’s consider the characteristics of the architect:

Communicability. Having talked with many software architects, I heard that it is one of the essential characteristics of this specialist. During the working day, they have to speak with customers in the language of business, managers of all levels, business analysts, and developers. If you have a natural charisma and you know how to convince people, then this will be a huge plus, as it is crucial to explain your actions correctly. Architects are laconic, eloquent, and competent speakers. The software architects with whom I spoke have highly developed skills in communication and persuasion. Another reason why this characteristic is most important is that the architect in this role participates in most discussion making processes, and often compromises must be reached that is acceptable and beneficial for all involved parties.
Broad and deep technical knowledge. It should be obvious since one cannot become a software architect with a medical background. Besides, the architect usually has expertise in several technological stacks at a decent level and should have a good understanding of a few other ones. The software architect should also be prepared to compose a large number of technical documentation, reports, and diagrams.
Responsibility. You should understand that architect decisions are usually the most expensive. Therefore, a person in this position should take the most responsible approach to his work and the decisions made. If the developer’s error costs a couple of days of work of one person, then the architect’s mistake can cost person-years on complex projects!
Stress resistance. You will have to make decisions because in this role, you will be asked to do so, and you will need a response. You will be working with different people from different areas, and you will have to deal with rapidly changing demands or even with changing business environments. Therefore, it is necessary to be ready for stress and to look for some ways to escape negative emotions. Work is always more pleasant when it brings pleasure. So if you choose this role only for the money, then think again.
Management skills. This includes both organizational and leadership skills. The ability to lead a team, which may be distributed and composed of very different specialists, is essential.
Analytic skills. Even if a specialist has a broad erudition in technology, he has tried many things on his own or participated in projects of various types. It does not guarantee that he can easily change the style of thinking to an architect. One of the most valuable tasks is the ability to represent an abstract problem in the form of some finite real object of the system, which developers are already evaluating, designing, and developing. Excellent communication skills are essential to represent the abstraction in the form of the final system to the members of the team and the customer. It will be necessary to communicate with both business and development, which is still to be done.

If we talk about the responsibilities of the architect, then here is the perfect example from the 19th century about bridge construction. At that time, the tests of the newly constructed bridge were the following: the key group of engineers, architects and workers stood under the bridge while the first vehicles were on it. Thus, they staked their lives upon the construction and the strength of the structure. So if there is a question — what is the responsibility of the software architect on the project? The answer is, he is responsible for everything.

If you give up loud and beautiful phrases, then the architect’s work includes:

Identifying the stakeholders on the project.
Identifying business requirements and requirements of the stakeholders on the project.
Designing the entire system based on the received requirements.
Choosing the system architecture and each component of this system at a high level.
Choosing the technologies for the implementation of each component and connections between the parts.
Architectural review. Yes, yes, it exists.
Code-review.
Writing project documentation and support it.
Creating unified development standards in the company.
Controlling the architecture during the next iteration of the system release.

It is only a subset of the software architect’s responsibilities. The most important responsibility is full technical support of the project from the moment of inception, through product release, to the development of enhancements. And supporting the next releases. It will be necessary to switch a lot between different tasks during the working day.

How to Become a Software Architect?

To begin with, it is requisite to define milestone goals that lead to achieving your strategic goal of becoming a software architect. For me, such goals for the next six months are:

● Understand and try several technological stacks. My current knowledge is concentrated in the field of iOS. It is necessary to try Android, several server languages, to start python, and refresh Java EE skills. The architect is a full-stack developer, so it is essential to have a broad technical knowledge.

● Reading literature. It is required to determine the most valuable books and articles that will help to grow in this direction. Usually, the most effective way to find such literature is to ask other professionals in this field for their recommendation. In one of the future articles, I plan to give you such a list of literature.

● Find a mentor. It is desirable to find a software architect at your current place of employment. It is always easier to get experience from a trained specialist than to start considering a particular area from scratch. It is requisite to be prepared to ask the right questions from your mentor.

● Study courses/obtain certificates. There are many courses and certifications available, but only a few are worth their money, and the higher level courses cost a lot of money. I have attended the architectural courses of Luxoft (http://www.luxoft-training.com/it-course/ARC-001/), which have proven to be a worthy investment. It is crucial that the lecturer of the course be a professional in this field and be able to answer questions. As for certificates, before starting, it is best to understand whether there are authoritative certification systems for architects and whether it is worthwhile obtaining the certification. This point I will discuss in a future article of this series.

One of the essential parts is a clear and stable plan review. What has been done, what should be reviewed, and where to accelerate or which goal to remove as useless.

Check Your Readiness Level

If you are interested in this introductory article from the series on how to become a software architect, or if you suddenly have thoughts to try this path, it is worth making sure that you want it.

Firstly, people are afraid of everything new. A new position, new kind of stress, as opposed to the comfortable status quo. Of course, the choice is not always unambiguous and depends on how much you are willing to change something in your life. At the same time, it can depend not only on you but also on the family, your financial commitments, parents, and other factors.

Secondly, this path takes several years. The process of becoming a software architect does not happen overnight. As a team lead, I realized what to do and how to deal with stress only a year after I was appointed to an official position. At the same time, six months before that, I performed it unofficially. One software architect I know said that he understood what his responsibilities are 18 months after he was promoted to this role. Such intervals of time are reasonable, and you need to know whether you are ready to move in this direction. Even if you do not have a stable plan available, it is better to start taking small steps that move you ahead, rather than remaining in the same place.

Standing in the same place in IT is a synonym for stagnation and personal fetters in life.

🗒️ l-lin

Explorer

software architect