Thoughtworks Xu Hao: Why become a full-flow programmer instead of a full-stack programmer?

This article is compiled by Geek Time from Thoughtworks Global Technology Strategy Consultant and China CTO Xu Hao’s speech in the live broadcast “Why Become a Full-Stream Programmer, Not a Full-Stack Programmer”.

Author｜Xu Hao

Editor｜Li Chenyang

A few years ago, Facebook claimed that they only recruited full stack developers (Full Stack Developer), requiring some knowledge and knowledge of most technologies. As a result, such a trend has also emerged in China, and full-stack programmers have become a new direction that everyone is flocking to.

However, with a series of technologies such as microservices, BFF, and micro front-end becoming more and more popular today, full-stack programmers no longer mean efficiency, which also makes us confused about the efficiency it advertises. So we have to ask:

• Why in the past few years everyone has put a lot of emphasis on Full Stack, but recently it has been less and less?

• If you want to achieve the efficiency improvement and people growth promised by the full stack, what are the prerequisites behind it?

• Around this prerequisite, does Full Stack really live up to its promise?

It should even continue to ask, what kind of programmer is more worthy of attention in today’s environment? These are some of the topics we would like to discuss today.

The appeal of full stack engineers

We will definitely use technology stacks when we do projects. The so-called technology stacks are actually an analogy. For example, the database will use Redis, mongo, SQL, etc., and some systems of Backend may be used in the middle, including Java, Spring, Ruby on Rails, and JavaScript, HTML, etc. in the foreground. That is, according to the layered architecture, when arranged from the front end to the back end, it is like a stack from top to bottom.

Full stack programmers are required to follow the direction of the stack and master the main technical points involved. It should also be known that when talking about the Full Stack, its focus is on the technical architecture, as well as the various components and technologies used in the technical architecture, so that we can understand the direction of the stack.

The full stack was able to work because of two important backgrounds at the time. One is Collective Code Ownership. Regardless of the foreground, background or database, when the environment is deployed, the relevant code will be put into a unified version control. And these things under version control can be directly accessed by everyone.

I think you can easily think of some best practices in the industry, such as Google’s Monorepo is a big single repository, and we will put all the projects and components into these repositories. Obviously, you will see a lot of Java and JavaScript database code in Monorepo. So in that state at that time, many big Internet companies were emphasizing the change of code from small teams to collective ownership.

As a full stack engineer, when you debug or use other people’s components, if you can understand the technologies used in the technology stack, your efficiency and working methods will be greatly improved. This is a starting point.

The second starting point, or the second point that makes Full Stack attractive, is an end-to-end delivery model emphasized in the industry.

The so-called end-to-end delivery mode is different from the previous sub-module delivery mode. Before, there may be a group of people writing the database, and a group of people landing in the background, and the same is true for the front desk. In the end-to-end delivery process, both the database, the backend, and the frontend must be delivered. To be more efficient in this way of working requires more knowledge of the full stack.

In this case, we believe that over a period of time, full-stack engineers can adapt to the changes in R&D efficiency and business models that the entire industry wants. So four or five years ago, the concept of a full stack engineer was sought after by some in the industry.

There is now little emphasis on full stack

Today, we rarely talk about the full stack anymore. The most obvious reason is that as more and more technologies are used, it is difficult for us to make a clear definition of the full stack. For example, to what extent is it full stack? ?

Of course, there are several other very objective factors. The first one is the introduction of a new architecture style based on microservices in the industry.

When the microservice components are divided, there is a main feature, that is, the front-end and the back-end are separated by API. It seems that it is no different from the previous separation of front-end and back-end and delivery by component, but in fact the difference is huge.

After the front-end and back-end are separated by API, the result is that business capabilities and User Journeys are actually separated by API. Before, the reason for end-to-end delivery was that we did not make a clear distinction between business capabilities and User Journeys.

About a dozen years ago, we might use Spring MVC, Map-Works, Ruby on Rails, etc. when we were building systems. The contracts between the server and the client were mainly generated in page flow, user experience and user flow. .

Today, the API has been completely decoupled from the user experience and UI layers, and we think that the front-end and back-end encapsulated and separated by the API can be turned into an independently delivered component. In the past, they did not have the meaning of independent delivery.

For example, if an enterprise wants to do microservices, and the service encapsulates a certain core business capability in the enterprise, then it has the value and significance of independent delivery. But more than ten years ago, if the background system encapsulated the logic of three or five page jumps and the data required for the page jump logic, this independently delivered background did not have a corresponding foreground system, so there was no Any meaning that can be delivered independently.

And microservices tell enterprises that even if there is no front desk, it is still meaningful to update and improve business capabilities in the enterprise ecosystem. Therefore, for the boundary of independent delivery, there has been a very big change in thinking. Our systems today have clear delivery boundaries, and it is no longer something that needs to be delivered from start to finish.

As shown in the figure, from the bottom up, the background is the API layer, which can access the database by encapsulating business capabilities into services. In the middle is the BFF, where User Journeys are usually restructured.

Taking BFF as an example, there may be a client with an API in the middle. It will access the API called Business capabilities in the background. With these APIs and the models contained in the API, we can reorganize User Journeys, which is the page. The corresponding jump process.

Going forward, it may be a real client, such as UI components, UI interactions, and client calls triggered by UI components and delivery, to call such a process accessed on the BFF.

In today’s scenario, we can’t help but ask such a question, is it still the same as the previous concept, across the client, BFF, and Microservice, the whole stack is called Full Stack? Or in the independent delivery boundary, as long as the content within the independent delivery boundary is mastered, it can be called a Full Stack?

If it is represented by a diagram, in our traditional sense, should the Full Stack be drawn like this (yellow line on the left) or like this (yellow line on the right)?

In fact, this is also an important factor in the recent period of time, the industry has stopped talking about Full Stack, because our default architectural style and the context of the architecture have changed.

We now tend to use a smaller-grained scope than before, turning it into a single deliverable component. So we can say that as long as these technology stacks used and mastered in the component are grouped into one, will it be considered a Full Stack?

This makes the concept of Full Stack very awkward. Either I unrealistically expect you to master all the techniques used from start to finish, or as before, just spread it out into small modules and it will be considered a Full Stack. So what are the differences and differences between Full Stack and the back-end development and front-end development we talked about earlier?

In today’s architectural style and architectural environment, people don’t quite know what kind of value and utility the Full Stack can bring. Instead, it has become a very confusing concept.

Some people may say that Full Stack is a trend, a trend, and the past is gone. I don’t think we can say that. We need to reflect deeply. When Full Stack was advocated back then, or when Full Stack was wildly adopted by the industry, many people even predicted that in the future, full-stack engineers will be needed, and single-point engineers will no longer be needed. All these indicate that we fully understood at that time. To the value and significance of Full Stack.

So what we need to ask further is: What is the logic behind Full Stack? Around this logic, what kind of programmer is more valuable in today’s environment?

The starting point of the full stack: synergies

If I ask a little more extreme, has the concept of Full Stack really had the effects it promised historically? My answer is no, it never even achieves the goals and claimed benefits it wants.

In addition to the collective code sharing and end-to-end delivery just mentioned, the core starting point of Full Stack is actually synergy, which is the so-called 1+1>2. For example, when two full-stack engineers work together, their productivity will be greater than two.

You know, what a full-stack engineer pursues is not how much more efficient a full-stack engineer can be than a non-full-stack engineer. What it actually pursues is that the efficiency of a pair of full-stack engineers working together will be many times higher than that of non-full-stack engineers, because they have synergistic effects.

We emphasize the full stack, not referring to the individual at a single point, but to the efficiency and effectiveness he exerts in the team. In other words, the full stack engineer can generate and create more synergies in the team.

for example. Full stack engineers emphasize that developers need to understand the content of the entire stack. A very direct impact is to be able to understand all the codes in the system. If there is a bug that needs to be debugged, there is no “I don’t understand, I need to wait for another person to do it for me” situation. Rather, I can keep debugging until I find the source of the problem, and even make changes.

This is an important role played by a full-stack engineer. He has mastered the content of other people’s knowledge fields and can produce a synergistic effect in the work process.

Further down the line, why do you need synergies in software development? I’ve covered this topic on a number of occasions, and it’s also a meta-proposition of my talk show The Octave, that software engineering is knowledge work.

When talking about software engineering, we usually compare it to building a house, including people who make drawings, people who move bricks, people who put cement, and so on. In fact, this is not the case. In the process of software development, only knowledge is really generated, so it is a process in which knowledge is transmitted, digested and absorbed.

We can think of it as the customer, or the person who actually pays for the software. In his mind, there is a way and a method to help the business succeed, and he informs this method to roles such as BA. When the BA fully understands the customer’s context and what the context represents, it will generate this knowledge into another form, that is, a requirement document, or a solution design plus a requirement document.

After generating the scheme design and requirements document, he needs to talk to the developer. The developer understands and absorbs the business context specified in the solution document, as well as all the meanings in the business context, and can convert it into code. At this time, knowledge is transformed from a utopian concept into an executable form.

Finally, following our traditional process, the code is put into the hands of a QA or tester who verifies that the customer’s original problem has been uniquely resolved in his context.

This is what I want to stress that in today’s environment, we can view the entire development of software engineering as a process of knowledge production and transfer.

knowledge consumption

The process of knowledge production and transmission requires synergy, which is easy to understand. If developers don’t understand the business context at all, they don’t quite understand what the requirements are. If he can’t understand the requirements, then his code is probably not written correctly. So when we turn software development into a knowledge job, there is a huge need for synergy.

Of course, there is a more rigorous statement here, derived from Peter Gluck, a master in the field of management. He said that the biggest subversion of knowledge work is that the point of production of our value has changed. The value of knowledge workers does not depend on production, but on consumption.

Take a more practical example. A person doing business analysis said that his requirements document was very well written, with 200 pages, but no one could understand what was written. He may write everything correctly, but because other people can’t understand it and cannot consume it, he has not played an effective role in knowledge transmission, and his value is 0. As a knowledge worker, his value needs to be measured by consumption.

Likewise, for developers, it means nothing if the functionality and code written is not consumed. Not being consumed means that it cannot be converted into actual functions to be used by others, or even those functions written out, which cannot be inherited and called by others.

For example, I wrote an API library, used a lot of design patterns, and the final code was very cool, but no one understood it. If no one understands it, no one will use it, and this framework will have no meaning.

This is a very important point. If we see ourselves as knowledge workers, our value is not determined by work, but by consumption. For a knowledge worker, the focus should be on the value of consumption and the efficiency of consumption, not how much value or how much efficiency is produced.

Obviously, the synergistic effect will improve the efficiency of knowledge consumption , which is a very simple inference. For example, if you have worked on a project for three years, everyone will feel that your level has improved and your work efficiency is very high. Compared with another person who has just joined the company for two or three days, he may not be as efficient as you.

But it’s not how high your level is. Maybe a big reason is that you have a deeper understanding of the environmental context, and the synergy effect with the rest of the team is higher, and the final results and efficiency are higher. We all understand what we say to each other, the communication cost is lower, and the distortion and loss of knowledge in the process of transmission are smaller, which in itself will improve the efficiency and effect of knowledge transmission.

At this point we can see that the original assumption of full stack programmers is that synergy occurs when we understand everything on the working stack. This assumption itself is not wrong.

The next question to ask is, since the basic assumptions and premise of full-stack engineers are correct, does the full-stack approach really increase the consumption of knowledge? The answer is a little bit, and only at the code level (Sort of, and at code level).

At the code level, it means that I can understand your code, but it does not mean that I can fully understand the business context and business logic behind the code.

We all have such experiences in our lives. For example, a person’s English is very good, but it does not mean that he can understand an English paper in a professional field. It is possible that he could understand all the words and grammar in it, but he had no idea what the paper was talking about.

So when we understand the technical points used on the full stack, we can only say that we have the ability to understand the final product. But the real process of software development revolves around knowledge transfer , so just understanding the final product does not mean that you can understand the business context and business logic behind the output. At this time, we can say that synergies will not be produced in large quantities.

In addition, work experience tells us that the mastery of the technology stack does not mean any meaning. Even if they use the same technology stack, because they are in different businesses and fields, the two developers often talk about the same thing. Therefore, if the shared knowledge just follows the direction of the stack, it is actually difficult to generate the necessary synergy.

So what kind of synergy do we really need?

true synergy

Regardless of the development style, what we end up doing is understanding the real problem, getting the solution, breaking the solution down into smaller tasks, executing it, and verifying that our problem is solved.

Note that we are not verifying the solution, but whether the real problem is solved. As shown in the figure below, from top to bottom is the process of knowledge generation and transfer (Konwledge generates and transfer), and from back to front is the process of knowledge consumption (Konwledge consumption).

At this time, we can regard the software development process as a stream around knowledge, that is, a stream of knowledge transmission and consumption. Then we can draw the conclusion that if more knowledge is shared along the direction of the flow, more synergies will be generated.

Knowledge is passed along the direction of flow and finally implemented into software. If we increase knowledge sharing and knowledge decomposition in the direction of the flow, instead of processing in the direction of the stack (not the vertical direction), the synergy will be. Produce more and stronger.

I think you can think of many specific technologies that conform to this principle. For example, the purpose of the unified language is to share more knowledge in the direction of flow, so that everyone has a similar understanding of the business context, and then allow developers and business people to communicate more effectively, resulting in stronger collaboration effect, which is a simple and straightforward way.

Another example of a situation that is often encountered at work. The more you do and know about a business area, the more efficient it becomes. That said, there are more and more business contexts that somehow make you a better programmer.

There should be some students who will say, do you mean to let developers fully understand the business, and then set the business direction and do product design? Is it about having one person do everything from start to finish?

Not really. We emphasize sharing knowledge. As long as communication efficiency can be improved, corresponding synergies will be generated. So as long as you know and understand what other people say, that’s actually enough. For example, after a decision is made, it is enough to understand the reasons behind it and infer it based on the business implementation background. Instead of making you an expert or a solution, the necessary synergies can be created.

At this point, we can naturally figure out what the full flow programmer is referring to. Full Stream is to expand the field of knowledge and context along the upstream and downstream, so that we can understand more business. This is the full stream engineer we need to be now, a programmer with more detail and knowledge in the context of streams.

How to become a full flow engineer?

The remaining question is, how to become a full flow engineer? I think many students may answer that to learn more domain knowledge and have more business scenarios.

This is indeed a direction we need to pay attention to, but in fact it is not just such content. As shown in the figure below, there are several directions that I hope you can consider.

The first is analysis and modeling . How can I get to grips with what is built on the business and the domain faster? The final answer lies in whether you can effectively analyze and model the problem. Can you quickly understand what others have modeled? Can you quickly understand what everyone is talking about behind the same language?

Then there is task decomposition , otherwise known as architecture. Architecture is how many components are in the system and how those components interact. When there is a new requirement, the only role that the architecture actually plays is to guide the task decomposition. From an implementation point of view, when you get the requirement, can you restore the architectural picture behind it and understand why you made such an architectural decision in the first place.

Of course, you don’t need to do an architectural design, just understand it, then the rest is testing and coding . With all this stuff, what better way to test to make sure it’s done? What better way to do efficient coding? These are the parts that revolve around coding to solve real problems and generate solutions.

Of course, there are still very important online and operational work in the future.

You might say the company has a dedicated DevOps department, a product operations department. But without understanding how the software actually works online, it’s easy to make bad decisions during coding. Not even understanding the operational requirements can produce similar results. Assuming that you don’t bury the point where you should, then when you really need to locate the operation and maintenance, you will find that the data is missing.

But if we can have more understanding and experience of knowledge along the direction of this flow, our collaboration will be more efficient.

From my personal growth experience, one of the most useful lessons I have learned is how to do business analysis, which is how to identify business value and write it on User Journey. To this day, I think it was a very important course for my career, but it had nothing to do with coding.

I think most programmers have put a lot of attention into coding and technology when planning their careers. But when it comes to the need to open up our technical horizons or hope for a longer-term career development, we actually need to enhance our capabilities along the stream of knowledge transfer and knowledge consumption, at least let ourselves be There are no obvious shortcomings in the entire flow process.

Believe that if you do this, you will become a completely different Engineer from today!

The text and pictures in this article are from AI Frontline