About the role of technical

Who is this article for?

Basically an article for technical leaders of software development teams and those who want to become them. And, of course, for the rest who are interested in the topic. For those who are interested in the opinion regarding the role of the technical leader, and for those who are ready to share their own thoughts on this matter.



What will be discussed further? Basically, it will be thoughts on the role of a technical leader, important points in his work, as well as very little about architecture and modularity.

Quite a bit about yourself

More than 15 years in software development. Experience in both grocery companies and outsourcing companies, both in foreign and Russian companies. Various roles, including technical leader and architect.

')

Who is techlide

Depending on the company and project, there is a different understanding of the role of the technical leader. Sometimes with a margin in the technical part, sometimes with a margin in management. Usually this person is engaged in architecture, code review, solving technical problems, coordinating the work of developers, and can also implement something himself. Architectural aspects can be partially or completely taken over by the architect, coordination ones by the manager. No matter how it is, it is important for you to clearly understand what your colleagues expect from you - both the managers and all other interested people. A mismatch of expectations may reduce your credibility and, as a result, decrease your work efficiency and motivation, both for you and the team as a whole. One of the ways not to lose sight of expectations is when there is no understanding of who is responsible for a question, to play the manager and find the right person. Make sure he does it. Also, some of the questions can and should be taken on by yourself, but always assess your capabilities and do not overload yourself - you can reduce your effectiveness by over-dispersing. This flexible approach will also allow you to better understand the overall state of the project.



Understanding the roles of team members is all the more important the less you communicate. In other words, if some colleagues work from another city or country, if their work schedule is weakly intersected with yours, if one of you speaks in a language other than your own, then all this will prevent you from resolving issues informally. In this case, understanding who to contact on what matter becomes even more important for effective work. In this case, the importance of a convenient process adopted by the team and understandable to it also increases.



Let's try to determine what you, as a technical leader, should do.

• You make technical decisions. Direct, initiate discussions if necessary, resolve technical conflicts, control. Look for different ways to get information - metrics, reviews or something else that brings visible benefits. However, management often requires a different type of responsibility from you - for the result made in a predictable time, and a qualitative result. It is often assumed that the whole team is responsible for the result. We can say that, but if you have the last word in solving technical issues, you can influence the project more strongly than others, thus taking more responsibility. It is also important to mention that refusing to participate in solving a problem or delegating a solution to another will not save you from responsibility, since is also a solution. Some questions may be the responsibility of architects or other interested parties — you need to be aware of this and involve them when necessary. Also, do not be afraid to ask colleagues for advice - this may help you make a better decision.
• You control expectations. Be predictable for your management and customer. You know that in 2 weeks the iteration will end (sprint, project), and you with 80% probability will not have time to do one of the planned tasks - collect the necessary information about the causes and ways of solving the problem and discuss with interested parties, there may still be some time then decide. Leave this for a surprise at the end of the iteration - you can get some unpleasant surprise in return.
• You are in the subject. Without reviewing the code and not participating in the development, it is very easy to lose contact with reality when your words (documents, letters, etc.) speak of one thing, and the code is completely different.
• You respect colleagues. Some might call it controversial, but I would like to leave it here. If you do not respect, they will not respect you either today or tomorrow. Probably not always you will be able to see reciprocity, but at least you are trying, which makes you certainly not worse.
• You are constantly learning. The IT industry is developing so rapidly that technologies that were popular only 3-5 years ago may be outdated (inefficient, not supported) today. Whether your employer allocates this time or not, it is necessary both for you and for him - find a solution (you have 24 hours a day, and there are also weekends - a joke). By working long with one set of technologies, you are likely to improve your skills in them, but expanding your horizons allows you to see more alternatives and make better decisions. Study not only deep, but also in breadth.

Suppose you have learned very well how to cope with this role and are wondering what's next. Intuition may prompt to move in management or even in starting a business. Try everything that seems interesting. Just need to remember about the limited hours in the day and, therefore, if you start to do more than one thing, it will force less to do something else. More managerial work - less technical. Another development option is an architect. You have to at least partly play his role as a technical leader. Therefore, speaking conventionally, if we reduce managerial issues and increase technical ones, we will move towards the architect. Try to look at these movements not as an increase or decrease, but as a focus on a more interesting area of ​​activity for you.

Processes

Most people today know what a process is and also uses or at least heard about flexible methodologies. Why do we need a process? For example, in order to make the team more efficient and / or predictable. Difficult to predict project delivery dates? Different developers randomly and independently of each other take the same task, which they also learn about only after a week? Sometimes buried in problems whose solution is already known to someone else from the team? Answering affirmatively to one of these or similar questions, you should think about improving your process. And everyone should be interested in this. The technical leader also, no matter how steep he might be in technical terms, in the event of a project failure may not wait for praise (unless this was a cunning plan initially).



Suppose that we understand the importance of the process and we also have some kind of process. Well, it's great, but let's not forget that everything changes, tasks, tools, people. Analyze what else can be improved. We, as technical people, should be close to the topic of automation. Spend a lot of time upgrading servers — consider automatic updates. Often break the code - build and verify it automatically when commits. Automation can greatly facilitate your process and make you more efficient.

Fight against complexity

We usually consider architecture a high-level system structure. It is up to you to work it out beforehand, in the process of working, or not thinking about it at all. If someone else will work with the system, it may be useful to have an actual document describing it. On the other hand, if the system is small and the source code is simple enough to understand, no one needs an additional document and you will waste time creating and maintaining it. Why do we usually draw high-level schemes of systems or algorithms - probably to conditionally simplify the system in order to study some basic points. From the simplified scheme it is much easier to move on to learning more detailed and directly source code schemes. Plus an understanding of the architecture of the team - context knowledge - the conditions in which the developed code will be executed. In some cases, it may also help in selling the system - some customers will trust the product more, the architecture of which is understandable or at least not hidden. But generally speaking, this is our way of dealing with the increasing complexity of the system. Regardless of the number of new kilo lines of code, we want to provide the necessary level of quality, maintainability, extensibility and scalability.



When designing, you will often encounter issues that already have proven solutions. Speech on the architectural patterns and principles. If you are not familiar with them or are not well acquainted with them, it is good advice to study them. You will be able to see better not only solutions, but also problems that you previously could not have thought about. In addition, it will allow you to speak the same language both within a team and with colleagues from other teams and companies.

Modularity

How much can we keep in our head schemes and other information while working on some new functionality? No matter how much you can, it must still somehow be put there. Those. the more information you need, the longer you will probably collect and stack it. This will be the time of entry required by a person who has not worked with the product before, to get up to date and to get the opportunity to work independently. We may be less or more worried about this time depending on how often people change on the project. In addition, the more information, the easier it is to get confused about it, forget about something or ignore something. This conceptually simple idea is often not given due attention, and we get a cumbersome monolithic monster that is difficult to expand, maintain and test.



What is a module? It can be an assembly or an application running in its own process, a source code file or part of it. It is important that this is part of a product with clear boundaries and external interfaces. We usually strive for module independence and minimization of interfaces between them.



What can the division into modules help?

• Interchangeability With relatively simple frauds, you can replace the module with a compatible one (having a suitable external interface). For example, one product can be assembled with an export module in PDF, and the other in CSV. However, the rest of the product will not change. Or even replace the module on the fly, depending on some settings.
• Reducing dependencies between functional blocks, separated into separate modules. Changes to one module will not affect other modules, provided the contract remains unchanged. In reality, of course, this is not entirely true because of the frequent lack of certainty of the contract. For example, we can describe that a certain method returns a string, but not explicitly specify its maximum and minimum length, format, or something else that might be important for the caller.
• Work on different modules can be carried out by different teams. This will be more efficient due to the smaller intersection in the source codes. There is less need to discuss small implementation details, only interfaces, if these modules need to work with each other. You can even achieve the potential to use different libraries or even languages, separately tested.

Of course, the idea is not new. Of course, there are also negative sides. And, of course, here you need to look for a certain line. In each case, it can be her. Analyze and try.



One way of breaking moves us towards a layered architecture. There is a different number of layers, with different meanings, but the general idea is that each layer only works with the layer directly below it. For example, there are layers of data access, business logic and presentation. The presentation layer will use only the business logic layer, but not data access. Business logic - only access to data, but not presentation. And the data access layer will not use any other layers. Thus, we get 3 modules, with some external interfaces and dependencies. This is a vertical separation.



Another method of partitioning can bring us closer to microservices. These are some kind of full-fledged services or applications that form a product together, but they work conditionally independently of each other. This can be completely transparent to the user, because one service may well redirect the user to another. Suppose you have a portal, part of which works with orders, and another part with clients. It may well be different applications. Since this is still a single product, they may need to somehow share common data — this can be achieved, for example, by using a common database or by replicating data from the database of one application to another. This is a horizontal separation.



Both vertical and horizontal separation require you to find the necessary degree of such separation so that the complexity of the separation is justified by positive effects. Also consider the system scalability requirements. If you need horizontal scaling, horizontal separation can give you more flexibility. Module testability can improve vertical separation. On the other hand, a strong fragmentation into modules may complicate their integration, configuration, and deployment. Look for the right strategy applicable for your product.

Conclusion

So, we thought a little about the role of a technical leader and a number of important issues for him, slightly touching on the architecture. One of our features is critical thinking, so try to skip the information received through the lens of your own experience and to make something for yourself. I am also very important to your opinion and advice on the topic of the article - both about the content and about the method of presentation. That's all for now.