We often say that we should listen to the voices of grassroots employees because they are the ones who are actually doing the work, and the same applies to development.

However, being a Tech Lead is not just about understanding the code itself, but more importantly, it requires a comprehensive understanding of the entire project. Here are a few important aspects that I think are crucial.

Introduction

A year ago, I wrote "Some Thoughts on Becoming a Tech Lead" and learned a lot of things throughout this year. Recently, I also wrote an article titled "Setting up a Server at the Company is Not as Easy as I Thought" where I summarized what I believe a Tech Lead should possess and treated it as my notes. I hope it can also help readers who are struggling with what a Tech Lead should do.

Frameworks and Technologies Used in the Project

Taking frontend as an example:

• Are frontend frameworks used? What are their new versions and features?
• Does it support SSR?
• How are APIs integrated? GraphQL, RESTful API, or gRPC?
• Do you have a basic understanding of the programming languages and architectures used in the backend?

Usually, software engineers who are assigned as Tech Leads represent that the assigned tasks can be completed smoothly, they can assist the project in solving problems, and they can grasp the team's progress. At least, it means there are no major issues with their programming skills. Since they contribute to the project as an Individual Contributor (IC), this part is not a big problem.

As for why it is important to understand the programming languages and architectures used in the backend, it is because besides design, the close collaboration with the frontend is through API integration. Understanding the problems encountered in the current backend architecture may lead to better discussions with the backend team and possibly come up with more suitable solutions. It may even help the backend team solve their own problems.

Important Business Logic in the Project

In financial services, some important business logic includes how to execute deductions, the timing of deductions, how to verify user identities, how to store personal information, and so on. For the frontend, these are usually matters that the backend should handle, but understanding the underlying mechanisms is essential for future requirements.

When displaying large amounts, whether to use BigInt to avoid overflow, whether currency conversion adequately addresses floating-point issues, whether decimal rounding is handled on the frontend or backend, and whether there are strict requirements for time handling (must be standard time, users cannot arbitrarily adjust, etc.) are all crucial aspects of projects involving financial services.

While understanding the business logic, developers usually need to have domain knowledge in this area and even be aware of the legal considerations involved in financial services.

Project Deployment

Although it is not directly related to project development, knowing how the code is deployed can be helpful in driving various process improvements.

For example, if the current project uses Docker, first, the project is packaged into an image and then uploaded to the company's private Docker Hub. The deployment machines will then pull and execute the image.

There are many aspects to consider here, such as who executes the image upload action, where the token is configured, whether the machine's ACL can access the Docker Hub, and how the token is passed. Although many of these aspects are beyond the scope of frontend responsibilities, the deeper the understanding, the more one can achieve what they want to promote. For example, if you want to introduce SSR by adding new machines, knowing the deployment process beforehand can quickly guide you on how to write scripts and proactively address any potential roadblocks.

Additionally, observing the deployment time can lead to process improvements. For instance, if installing dependencies needs to be repeated for each image, which lengthens the deployment time, one can try separating the common parts into another image to reduce installation time and speed up the overall deployment process.

The Entire Process of Requesting and Receiving Responses from the Server

• Does it pass through a load balancer?
• How many machines are there in the production environment, and what are their specifications?
• Where are the machines deployed?
• Are static files stored on the machines or on a CDN?
• Are there any reverse proxies (nginx or envoy)?
  • Are there any special rewrite/redirect rules that need to be understood?
• On which port is the server running?

Understanding the History

Sometimes, when we see poorly written code, we may start to complain, "Why was it written like this? WHY??" Apart from the "I'm just frustrated" kind of complaining, I have recently learned to understand the history behind it. Sometimes it's because of tight schedules, sometimes it's because the business requirements are too unique and don't align with the existing architecture, and sometimes it's due to compromises made during architectural evolution. Once we start thinking from a historical perspective, we might even feel a sense of admiration.

Understanding the Needs of All Parties

Sometimes conflicts arise in projects not only due to miscommunication but also because we don't know what each party cares about. For example, in a certain project, the schedule seems unreasonably tight, and each developer feels a lot of pressure to meet the deadline, thinking that it's just the PM's unilateral desire to compress the development time. However, the reality may be that this project is subject to new regulations and must be completed before the new regulations come into effect, otherwise, there may be fines for non-compliance.

In situations like these, it's often not intentional concealment but rather a failure to communicate the information to everyone or forgetting to convey it.

I think it's crucial at times like these to believe that the other party's problem is a problem. It may seem foolish or unreasonable to the developers, but if we approach it from the perspective of "everyone wants this project to be better," the outcome will be completely different. (Unless someone is intentionally causing trouble)

Another point is to speak up when there is a problem. It's okay to ask questions or ask multiple questions, even if they seem silly. However, many software engineers tend to have a strong ego and fear being proven wrong after asking a question, so they silently complete the functionality even if they are burning with anger inside. In such situations, asking a question or seeking confirmation can often defuse the crisis (if not, you should know what to do).

Conclusion

The reason why these things are important is not just because you are a Tech Lead and should understand them, but because they can help you effectively utilize existing resources to solve problems when encountering new projects, new requirements, or bottlenecks within the team.

For new requirements or improvements, the speed and quality of development often depend on understanding the existing architecture. For example, if there is a new requirement to upload images and generate thumbnails, and there is already a similar module in some other functionality, modifying the existing functionality would suffice. However, if the Tech Lead is not aware of this, it may result in more time and resources being spent.

Teams also frequently discuss various technical decisions or implementations for specific requirements with the Tech Lead, and the aforementioned points are good materials to help you provide insights. Only by truly delving into the architecture, understanding the challenges faced by developers, and clarifying each other's needs can we prevent new requirements or solutions from becoming mere flights of fancy.

Afterword

In the article "Some Thoughts on Becoming a Tech Lead" a year ago, I realized that I no longer care as much about salary increments (though I still do care to some extent). On the one hand, it's because I am satisfied with my current position, work mode, and content. On the other hand, I have come to understand that everyone has their own work style, and as long as I fulfill my responsibilities well, I can be content.

I might still complain a little on Twitter in private, but I still want to improve team productivity as much as possible and continue to improve the existing development processes and projects.