About the role of techlide

Who is this article for?

This is mainly an article for technical leaders of software development teams and those who seek to become one. 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 willing to share their own thoughts on this subject.

What will be discussed next? Basically, these will be thoughts on the role of the technical leader, important points in his work, as well as quite a bit about architecture and modularity.

Quite a bit about myself

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

Who is techlide

Depending on the company and the project, there is a different understanding of the role of a technical leader. Sometimes with an advantage in the technical part, sometimes with an advantage 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 fully taken over by the architect, coordination - by the manager. Be that as it may, it is important for you to clearly understand what your colleagues expect from you - both managers and all other interested people. Inconsistency in expectations can reduce confidence in you and, as a result, reduce work efficiency and motivation, both yours and the team as a whole. One of the ways to keep up with expectations is when there is no understanding who is responsible for any issue, play a manager and find the right person. Make sure he does it. Also, some of the questions can and should be taken over, but always evaluate your capabilities and do not overload yourself - you can reduce your effectiveness by spraying too much. This flexible approach will also allow you to better understand the overall status of the project.

Understanding the roles of team members is all the more important the less you communicate. In other words, if some of the colleagues work from another city or country, if their work schedule does not overlap well with yours, if any of you communicate in a different language, then all this will interfere with solving issues informally. In this case, understanding who to contact on what issue becomes even more important for effective work. In this case, the importance of a convenient process accepted by the team and understood by it also increases.

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

• You make technical decisions.You 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 you to take a different type of responsibility - for a result made in a predictable time, with a quality result. It is often accepted that the whole team is responsible for the result. We can say so, but if you have the last word in solving technical issues, you can influence the project more than others, thus taking on greater responsibility. It is also important to mention that refusing to participate in solving a problem or delegating a solution to another will not relieve you of responsibility, because is also a solution. Some of the issues may be the responsibility of architects or other interested parties - you need to know about this and involve them if necessary. Also, do not be afraid to ask colleagues for advice - this can help make a better decision.
• You manage expectations. Be predictable for your management and customer. You know that in 2 weeks the iteration (sprint, project) will end, and with a probability of 80% you will not have time to do one of the planned tasks - collect the necessary information about the causes and methods of solving the problem and discuss with interested parties, there may still be time that then decide. Leave this for a surprise at the end of the iteration - you may get some unpleasant surprise in return.
• You are in the subject. Without conducting a code review or 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 speaks of completely different.
• You respect colleagues. Some might call it controversial, but I would like to leave it here. If you do not respect you, then they will not respect you either, today or tomorrow. You may not always be able to see reciprocity, but at least you are trying, which makes you certainly no worse.
• You are constantly learning. The IT industry is developing so rapidly that technologies that were popular only 3-5 years ago can be outdated (inefficient, not supported) today. Whether your employer allocates this time or not, you and both need it and find a solution (you have 24 hours in a day, and there are also weekends - a joke). Working for a long time with one set of technologies, you are likely to improve your skills in them, but broadening your horizons allows you to see more alternatives and make more effective decisions. Explore not only in depth, but also in breadth.

Suppose you have learned to cope with this role very well and thought about what next. Intuition can prompt you to move to management or even to start your own business. Try everything that seems interesting. Only you need to remember the limited hours in the day and, therefore, if you start to do more with one thing, it will force you to do less with something else. More managerial work - less technical. Another development option is an architect. You are forced to at least partially play his role as a technical leader. Therefore, speaking conditionally, if we decrease managerial moments and increase technical ones, we will move towards the architect. Try to look at these movements not as raising or lowering, but as focusing on a more interesting area of ​​activity for you.

The processes

Most today know what a process is, and they also use, or at least hear about, flexible methodologies. Why do we need a process? For example, in order to make the team more efficient and / or predictable. Is it difficult to predict the timing of the project? Different developers randomly and independently take on the same task, what else will they learn only after a week? Sometimes buried in problems whose solution is already known to someone else from the team? When you answer yes to one of these or similar questions, you should consider improving your process. And everyone should be interested in this. The technical leader also, no matter how cool he is in technical terms, in case of failure of the project, he can not wait for praise (unless this was an insidious plan initially).

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

Struggle with complexity

We usually consider architecture to be a high-level system structure. To work it out in advance, in the process of work, or not to think about it at all - you need to decide. If someone else works with the system, it may be useful to have an up-to-date document describing it. On the other hand, if the system is small and the source code is simple enough to understand, no one else may need an additional document and you should not 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 key points. From a simplified scheme, it is much easier to move on to studying more detailed and direct source code schemes. A plus of understanding the architecture by the team is knowing the context - the conditions in which the developed code will be executed. In some cases, this may also help in selling the system - some customers will trust a product whose architecture is understandable or at least not hidden. But in general, this is our way of dealing with the increasing complexity of the system. Despite the number of new kilo-lines of code, we want to provide the necessary level of quality, supportability, extensibility and scalability.

When designing, you will often come across issues for which proven solutions already exist. It's about architectural patterns and principles. If you are not familiar with them or are new to them, it is good advice to study them. You can better see not only solutions, but also problems that you might not have thought about before. In addition, it will allow you to speak the same language both within the team and with colleagues from other teams and companies.

Modularity

How much can we keep in mind the circuits and other information while working on some new functionality? No matter how much they might, it needs to be put there somehow. Those. the more information you need, the more likely you will be to collect and stack it. This will be the time of entry, which is required for a person who has not worked with the product before, in order to get into the course of business and to get the opportunity to work independently. We may be less or more bothered by this time, depending on how often people change on the project. In addition, the more information, the easier it is to get confused, forget about something or not take something into account. This conceptually simple idea is often not given due attention, and we get a bulky monolithic monster, which is difficult to expand, maintain and test.

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

How can separation into modules help?

• Replaceability. Relatively simple fraud, you can replace the module with a compatible one (with a suitable external interface). For example, you can build one product with the export module in PDF, and another in CSV. However, the rest of the product will not change. Or even replace the module on the fly, depending on some settings.
• Reduced dependency between function blocks allocated to separate modules. Changes to one module will not affect the rest of the modules, provided that the contract remains unchanged. In reality, of course, this is not entirely true due to the frequent lack of certainty of the contract. For example, we can describe that a certain method returns a string, but does not explicitly specify its maximum and minimum length, format or anything else that may be important for the caller.
• Work on different modules can be carried out by different teams. This will be more efficient due to less overlap in the source code. There is less need to discuss small implementation details, only interfaces if these modules should work with each other. You can even get the potential to use different libraries or even languages, to test separately.

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 edge. In each case, she can be her own. Analyze and try.

One way to break down moves us towards layered architecture. There are a different number of layers, with different meanings, but the general idea is that each layer only works with a 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 the data access. Business logic is only access to data, but not representation. 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 way to break up can bring us closer to microservices. These are some full-fledged services or applications that form a product together, but work conditionally independently of each other. This can be completely transparent to the user, as one service may well redirect the user to another. Suppose you have a portal, part of which works with orders, and the other with customers. It may well be different applications. Since this is still one 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 division.

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

Conclusion

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