33 Becoming a Highly Skilled Mobile Developer #

Since the last update of this column, without realizing it, we have already completed the second module on “Efficient Development”. Stability, memory, lagging, I/O, networking - the “High-Quality Development” module has established an optimization path from the application layer, Android system layer, Linux kernel layer, and finally to the hardware layer, helping us establish a solid foundation as an Android development master.

What does “efficient development” bring to us? In today’s mobile Internet development, everyone talks about “improving quality and efficiency.” However, team efficiency cannot be achieved by simply encapsulating a utility class or component for low-cost reuse by others. We need to think beyond the limitations of the client, consider the pain points in the entire product development process, explore optimization opportunities for collaboration among different teams, and endeavor to improve product quality and team efficiency.

What we need is to think one step further, even if it’s just a small step, as it may have great value for our personal growth. To become a well-rounded “development expert,” we need not only the ability to systematically solve application performance and architectural problems but also the ability to think from a global perspective and understand the overall process. This is what I hope to inspire you to consider in the “Efficient Development” module, and I hope you can become a mobile development engineer who can “stand at a higher level.”

Becoming a Mobile Development Engineer with Depth #

During the era of WeChat, I highly admire the theory of T-shaped technical talents, which consists of two dimensions: breadth and depth.

A Mobile Development Engineer with depth needs to have the ability to delve deeply into vertical issues and also think comprehensively about every problem horizontally. For example, if a team wants to address the accuracy and real-time issues of data governance, looking at it from a client perspective would involve thinking about how to implement a data tracking component that ensures data is not lost, has high real-time performance, and is highly performant. As we know, the process model, storage model, and synchronization mechanism involved can be quite complex, so creating a highly available tracking component indeed requires a certain level of technical depth.

However, if we take a higher perspective, we will realize that optimizing the tracking component does not fundamentally solve the team’s data issues. What are the specifications for tracking? What is the flow for tracking? What pain points do the product, development, data, and testing teams have in terms of data? We need to map out the entire process of tracking, including product definition, client-side tracking development, testing, backend data handling, data display, and monitoring. In order to address the team’s data governance, we need to think systematically about each point, taking a comprehensive view from a higher perspective.

So how can we improve our depth and think about problems from a higher standpoint? Here are some of my thoughts.

1. From Terminal to Cross-platform

In the early days of app development, in order to achieve code reuse, we created various utility classes such as Util. As mobile internet development progressed, applications became more numerous and complex, and code needed to be reused across different applications. This led to an explosive growth of client-side components, such as Glide, Fresco, Picasso in the image library, and Atlas, DroidPlugin, and RePlugin in the componentization field.

Looking back, the immaturity and imperfections of the Android system at that time actually contributed to a flourishing era of mobile development. During this era, we could always find many optimization points and continue to refine them. As the complexity and requirements of applications increased, simply optimizing individual points on the client side could no longer meet the demands of the business, such as in complex scenarios like live streaming and mini-programs.

At this point, our first step is to break free from the limitations of being a client developer and take a more global perspective when looking at and thinking about problems. You need to understand that client-side implementation is only a small part of the whole picture. For example, if you are given a task to improve page loading speed, the foundation for extreme optimization is our ability to deeply study browser rendering principles and caching mechanisms. But what can we do on the frontend and backend? What should be done? In addition to this, we need to think about where a page is generated, how it is published, where it is published, how it is downloaded, how it is parsed, how it is rendered, and how page performance is measured and monitored – all of these are issues we need to consider.

On the one hand, before your project proves its value, many companies may not be willing to invest a lot of manpower. In this case, we can only handle both the front-end and back-end, just like when we built the log platform and APM platform for WeChat in the early days. More people will be involved only after the project proves its value. Therefore, we need to have cross-platform capabilities, with the goal of solving product problems. It is important to note that client-side technologies are not the only choice.

On the other hand, for continuous delivery platforms, testing platforms, network platforms, and data platforms, many client developers are originally users of these platforms. We should have a clearer understanding of the pain points and areas for improvement. Therefore, client developers should play a greater role in leading the evolution of these platforms.

2. From Platform to Middle Platform

As I mentioned above, componentization is just the most basic abstraction of client technology. How do we understand this? Taking performance components as an example, although we collect performance data from various dimensions of the application, we do not provide solutions for how to aggregate, store, analyze, and alert this data in the backend.

Each application that is integrated still needs to put in a lot of effort to build a complete system. In order to solve this problem, integrated service construction has begun to appear, such as the various developer platforms represented by Google’s Firebase. To address different application scenarios, we continue to incubate different service platforms.

Mobile development has long passed the era of single combat, and deep diving into individual client points is no longer the only consideration. Whether there are supporting services, and whether those services are simple and easy to use, have become increasingly important factors for developers. This is especially true for large companies that have dozens or even hundreds of applications. Avoiding redundant work for common business needs is crucial. China’s mPaaS from Ant Financial and EMAS Mobile Developer Platform from Alibaba Cloud both follow this service-oriented approach.

But is platformization the ultimate form of services? Have you ever experienced the pain of a new application needing to integrate with a dozen different internal platforms, where the account information and registration information are independent of each other, and many functions require separate debugging and testing with each platform? In order to solve the fragmentation of various platforms, the concept of middle platform has been proposed based on the platformization.

What is a middle platform? Simply put, it is to unify these dispersed platforms into one super-large platform. Some may think that we are going back in history. Do you remember how difficult it was to split a huge system into various sub-platforms back then? In fact, the “unity” of the middle platform here is mainly at the developer level, for example, using the same account, not needing to register repeatedly, and creating a closed loop between platforms.

For more information about the middle platform, you can refer to 《From Platform to Middle Platform (Part 1)》 and 《From Platform to Middle Platform (Part 2)》. In China, Alibaba has done the best job in terms of the middle platform. Of course, Tencent and ByteDance have also realized its importance. They have recently been actively adjusting their organizational structure and setting up dedicated middle platform departments. However, whether it is a middle platform or a platform, they are built up through countless large and small optimization points. They need to be accumulated slowly and it is difficult to build them very well in a short period of time.

FAQ (Frequently Asked Questions) #

In regards to efficient development, I have provided a comprehensive introduction to the practices and approaches of major companies. The knowledge involved in continuous delivery, testing, deployment, data, network, and logs is extensive. Therefore, just like high-quality development, even if you don’t fully understand the content of this column, there’s no need to be anxious. You can read the articles and the additional reference materials repeatedly, and believe that you will gain different insights with each study.

You can continue to learn at your own pace, and I believe that regardless of your perspective or understanding of mobile development, there will be great gains. However, when moving towards a higher level, we might have some questions. I will now select a few important questions to further discuss my views.

1. How to improve personal focus and efficiency?

The human brain is like a CPU, and the cost is very high when frequently switching processes and threads. If we look at WeChat for a while, then scroll through Douyin, and then check out the headlines, when we switch back to the work thread, it takes at least a few minutes to get back into the state.

Can this problem be solved by personal self-control? It can, but unfortunately, most people do not have the ability or strong enough self-control. Do not give yourself the opportunity to be tempted because most people cannot resist temptation. My suggestion is to directly uninstall software that may affect our work (you may not be able to uninstall WeChat, which is also its powerful aspect, laugh).

2. The relationship between personal development and company platforms

You may resonate with the doubts of DebugCat. My daily work is to write interfaces, adjust animations, and deal with endless business tasks. Although the things you mentioned are high-end, there is no opportunity for me to get involved.

For small teams, more often it’s a take-and-use approach, utilizing some third-party platforms. For large teams, you may have the opportunity to truly participate in the development of these platforms. But some people also say that in a small team, you can take charge, but in a large company, you can only be a small screw.

I believe that these limiting factors such as business and team indeed objectively exist and have a huge impact on us. However, they are not decisive factors. You need to ask yourself if you have really made efforts.

If you are in a large company, you should study the modules you are involved in comprehensively and deeply, from the client to the backend. Think about how to optimize the modules you work on to the extreme, and ensure that they can still operate stably in the face of a huge number of users. If you are in a startup team, you should persist in learning and continuously explore your technical expertise in your spare time. In the future, these efforts will become a highlight for countless job interviews and salary increases, whether it’s internal promotion within the startup team or jumping to a large company.

Summary #

To truly stand out as a mobile development engineer, you need both technical depth and breadth. The question is: should you focus on diving deep first, or expanding your knowledge broadly?

I recommend that you initially invest a significant amount of effort in one specific technical area, diving deep and gaining a thorough understanding. After that, you can consider expanding your breadth of knowledge. This is because experienced programmers can quickly learn new things, as there aren’t many completely new technologies anymore. What are often referred to as new technologies are actually combinations and slight innovations of existing ones.

There are no shortcuts to growth. I’ve noticed that some people in the tech industry enjoy writing articles on forums or giving lectures, and they may have gained some fame and popularity. However, when it comes to interviewing with big companies, they might be brought back to reality. I recommend you take a look at this article, and I want to share with you a sentence from it:

Be honest in your studies, be diligent in your work, and one day fulfill the ambitions you once boasted.

“Golden three, Silver four” is also a peak season for job hunting. Based on the experiences of many students in interviews, it is particularly challenging for those who only know how to write business code to find a job. For example, many interviewers from top companies often focus on performance optimization details to examine whether you truly understand the underlying mechanisms and principles. The requirements are getting higher, so we must actively adapt and study diligently. Lastly, I recommend you take a look at 《Programmer Growth Path》. I hope the “big truths” discussed today will inspire you.

Feel free to click on “Invite Friends to Read” to share today’s content with your friends and invite them to learn together.