38 How to quickly get into working mode when joining a new company? #
Hello, I am Zheng Ye.
After studying the previous modules, we have explored the application of various principles in different scenarios, and I believe you have also gained a deeper understanding of these principles. However, in actual work, it is not clear which principle should be used to solve a problem.
Therefore, in the next three lectures, I have selected three very classic scenarios in a programmer’s career to show you how to apply the principles we have learned to practical work.
In the first lecture of this module, which focuses on comprehensive application, let’s talk about what to do when you join a new company.
The IT industry is developing rapidly, with countless opportunities emerging. Frequent job changes are a typical feature of this industry. Changing jobs frequently is a high cost for both the company and the individual. Therefore, when joining a new company, how to quickly integrate yourself and start making a valuable contribution is an important question we face.
From an industry perspective, my job switching rate is quite low. However, due to the nature of my previous work, I need to collaborate with different companies and people. Every time I join a new company, the nature of the work is completely new, just like starting a new job. Because the collaboration period is limited, I cannot spend months getting familiar with everything like regular employees. I have to quickly get up to speed and also present my own new ideas.
So how do I do it? Actually, I use various methods mentioned in this column to solve this problem. Let me share with you the specific approach.
Applying a Framework of Thinking #
Do you remember the thinking framework I proposed at the beginning of the column? We need to ask three questions:
- Where are we?
- Where are we going?
- How can we get there?
Let’s start with the first question. If we have just joined a company, even if we are not completely clueless, we only have a basic understanding of the business of the company. This is our current situation.
As for the second question, let’s consider our goals. Generally speaking, we all plan to make a mark in the new company. But this answer is too broad, so we need to further refine it. The long-term development of the company is a concern for later. For now, we should set our first goal as being able to handle the job, such as being able to solve daily project problems.
Then, we need to answer the third question. How can we achieve this goal? We need to break it down.
You can think back to your past work experience. What do you need to know to start working on a project? Many people’s first reaction is technology. After all, I am a programmer, so of course, technology comes first. Most likely, when people join a project, they rush into the code and start researching various details. Technology is definitely something you need to understand, but it should not be the top priority.
Technology solves the “how” question, but the question we should first understand is “what” to do. The answer to what a software actually does is the business. So, the first priority should be understanding the business.
Understanding the business and technology are both important for playing your individual role effectively. However, we usually work in a team, so we also need to address the issue of collaboration with others. This requires an understanding of how the team operates.
Great! We have broken down the big goal and obtained three smaller goals:
- Business
- Technology
- Team operations.
Starting with the Big Picture #
Next, let’s take a look at the specific content we need to understand for each goal.
Business #
First is the business. This is often overlooked by programmers when starting a new project. In this column, I have emphasized the importance of knowledge structure in different modules. Knowledge without structure is fragmented. Therefore, no matter what project you are working on, you should always start with the big picture. Only by understanding the big picture can various pieces of knowledge fall into place.
For an ordinary programmer, the business is this big picture.
If you understand the business, you can deduce the basic code structure on your own. But if you are given code and asked to deduce the business from it, it is almost impossible.
In fact, every time I understand a business, I try to imagine how I would do it if it were my business. This way, I have a general idea in mind and when I correspond it to the actual code, it doesn’t feel so unfamiliar.
To understand the business, I usually ask someone to explain to me what the business does, what kind of problems it solves, and what the specific business processes are, and so on.
In the initial stages of understanding, I don’t try to understand all the details because my goal is just to establish a basic framework. With this initial understanding, I know where to start if I have any subsequent questions.
In theory, understanding the business is something every programmer should do, but in reality, it is often a problem area. During the process of having someone explain the business to me, I have found that many people have trouble distinguishing between the business and the technology and often mix the two when explaining. If you follow their line of thinking, it is easy to get caught up in discussions about the details.
Therefore, when understanding the business, you must be mentally prepared and tell yourself that at this stage, I only want to understand the business and do not talk to me about the technology.
Technology #
After understanding the business, we move on to technology. This is the favorite topic of programmers. But even when understanding technology, we need to have an order. So, let’s start with the macro content. The first question is the technology stack of this system: Java, JavaScript, or .NET. This way, I can have a rough expectation of the tools and frameworks that will be used.
Next is the system architecture, which includes the modules that make up the system and the interactions with external systems. It is best to have one or more diagrams that illustrate the architecture. The reality is that many projects do not have ready-made diagrams, so we need to discuss and draw them together on a whiteboard and then refine them later.
With a basic system structure in place, we can now go a little deeper.
I would start by understanding the external aspects. Here, the external includes two parts:
- What interfaces does this system provide externally, corresponding to the system’s capabilities;
- Which external systems does this system need to integrate with, corresponding to the support it needs.
Once there is involvement with external systems, there will be external interfaces to deal with. For example, whether it is a REST or RPC (Remote Procedure Call) interface, or whether messages are passed through a message queue (MQ).
Do not simply assume that all interfaces are familiar to you; there are always projects that use unconventional methods. For example, I have seen systems that use FTP as an interface.
All of these are equivalent to information delivery methods, and further understanding is the specific format of the information, that is, the protocol.
Today, the common protocols are in JSON format or binary encoding based on open-source projects, such as Protocol Buffers, Thrift, and so on. Some older systems may use dated protocols like XML, and some systems may use specific protocols in their own domains, such as the many protocols defined by 3GPP in the communication industry.
Generally speaking, understanding the external interfaces can give you an idea of the era in which a project exists, or at least the era in which the technical leader’s understanding of technology is based.
After understanding the external aspects, we can move on to understanding the internals. Understanding the internal systems also starts with the business, corresponding to which modules make up this system and what responsibilities each module has. If it is a microservice system, each service should be an independent module.
Usually, this is also a point for discovering problems. The division of modules in many systems often lacks clear responsibilities, resulting in serious dependency issues. In the previous content, I mentioned boundary contexts multiple times. Evaluating these modules from the perspective of boundary contexts often reveals problems that can be a starting point for future improvement work.
After the business comes the technology, corresponding to the need to understand the layers. As I mentioned earlier, the layered structure reflects the abstraction of the system. I want to understand how many layers a module has, and what each layer’s responsibilities are. Understanding these aspects gives you an overall understanding of the system’s design.
After the design comes the implementation, but it’s not yet time to write code. I would start with the build script and understand the commonly used commands for the project. I expect to find a build script that can be successfully built from the version control system. If this is not the case, I know where improvements need to be made.
Finally, we get to the code, such as the directory structure, the location of configuration files, and how modules are reflected in the source code, and so on. This is something that programmers are most familiar with, so I won’t say much about it. As a preliminary introduction, it is enough to have a basic understanding. The code is where we will invest a lot of effort in the later stages, so there is no need to rush.
Team Operation #
Lastly, we need to understand the team’s operation. Again, we start with the external aspects. What external interfaces does this team have, such as where the requirements come from, who will ultimately use the product, and to whom the team needs to report. If there are external clients, how is daily communication arranged?
Next is the internal activities. On the one hand, there are regular activities such as stand-ups, retrospectives, and weekly meetings. How is the timing for these different activities arranged? On the other hand, there are the team’s daily activities, such as whether there are daily code reviews and whether there is an internal sharing mechanism, and so on.
By understanding these aspects, you can generally judge the professionalism of a team. You can also know who to seek help from when you need it, laying the foundation for better integration into the team.
You might ask, “Doesn’t it take a lot of time to understand all of these things?” Actually, that’s not the case, because you only need a general understanding of the overall situation. If someone on the team has a clear understanding of the current state of the team, you can ask them for help, and it may only take a day. This is also why I can often get up to speed quickly. Now, it’s time to roll up our sleeves and get to work!
Summary #
I have introduced to you how to apply the knowledge learned earlier to understand a project from the perspectives of business, technology, and team operations.
The common approach of most programmers is to start with details, making it difficult to build a complete picture. They often “can’t see the forest for the trees”. On the other hand, my approach is to start from big to small, from the outside in, breaking down the content to be understood layer by layer. With the big picture, it is easy to understand where your work fits in the overall scheme. I have summarized the above content for your reference.
As an additional tip, use “jargon” in communication. Learn some “jargon” during the process, which will make others feel that you are knowledgeable and quickly gain trust, enabling you to integrate into the team sooner.
If there is one thing you can remember from today’s content, please remember this: When understanding a project, start with the big picture.
Finally, I would like to invite you to share your experiences with the difficulties encountered when joining a new company. Feel free to share your thoughts in the comments section.
Thank you for reading. If you found this article helpful, please feel free to share it with your friends.