Technology has advanced rapidly in the past few decades and will advance even faster in the decades to come. Today’s technology barriers are falling faster and faster, and Web applications that once required a team now require only one or two people.
At the same time, due to the changes in the organizational structure of the company, there will be more and more responsibilities assigned to each person. While we see the benefits of factory manufacturing, we also see the changes that lean thinking brings. It is this kind of change that makes more and more experts move to the full stack, allowing better communication within the organization.
You’ll also see two different learning modes for experts and full stack engineers, and the future of full stack engineers.
The history of technological innovation
From the initial CGI pattern to the MVC pattern, to the back-end separation of the architectural pattern, are constantly lowering the technical threshold. Those thresholds have been lowered enough to allow one or two people to do most of the work.
CGI
Twenty years ago, the website appeared in a static form, which did not require too many people to maintain and manage. Then the Common Gateway Interface (CGI) was invented to implement dynamic web sites. Here is a diagram of an early site:
At that time the website URL is similar to: https://www.phodal.com/cgi-bin/getblog
(PS: This link is for explanation, it doesn’t actually exist.)
When the user visits the above page, he will access the corresponding getBlog script in the cgi-bin directory. You can return to this page with a Shell:
Blabla, a jumble of codes. I have to say: I saw some of this code in 2012. In a nutshell, the code structure of this era looks like this:
It was a nightmare. Today, however, even novice PHP programmers write code that way.
Ok, now we can talk about the MVC pattern.
MVC architecture
I have reason to believe that Martin Fowler’s Enterprise Application Architecture Patterns was very popular at the time. The code changes from the above coupling state to:
Similarly, you are already familiar with this architecture, so we won’t explain it much. If you don’t know much about it, read the rest of the book.
Background servitization and front-end consistency architecture
From today’s point of view, we can see the architecture as shown below:
The backend has been servitized unknowingly, providing only API interfaces and services. The front end at this point has been combined with the APP side as much as possible to keep them consistent.
The core of software development: communication
Software development has been the preserve of big companies for decades, and small companies simply don’t have the capacity to do it. In the decades following the invention of computers, developing software was something only large companies could afford. The average non-technical company cannot customize its own software system, so it has to buy existing software. And with the cost of technology falling, today the average small business can hire one or two people to do the same thing. It’s an interesting evolution:
Each of these processes is essentially aimed at solving communication problems. From waterfall to Agile is to solve the problem of communication within the organization. From Agile to Lean not only optimizes the problem of communication within the organization, but also strengthens the relationship with the outside. In other words, lean incorporates a portion of Internet thinking.
The waterfall
At the very beginning, we designed our features in advance, coded them, and released our software when appropriate:
However, this approach is hard to deal with market changes — when we spend years developing software that people needed years ago. At the same time, due to the limitation of the complexity of software development itself, the copied system needs a lot of system integration work in the later stage. Such integration efforts can take a significant amount of time — weeks, months.
When people became aware of the problem, they started to improve the workflow. The emergence of agile software development explains why product managers often change requirements. If a feature itself is unnecessary, then why bother developing it? However, if a feature is not well designed at the beginning of the design, it is inevitable to change the requirements.
agile
The workflow of existing Internet companies is similar to agile software development in many parts, with iterations, analysis, and so on:
But as far as I know, most Internet companies in China do not write tests or Code Review. Of course, this is not an article about how to practice Agile. One big difference between Agile and waterfall development is communication. Traditional software development is analysis, development, and so on after research. Agile development emphasizes communication issues in this process:
Throughout the process, communication issues are constantly emphasized, but there is a problem: the organizational structure itself. Such organizational structure is shown in the figure below:
If the marketing/product manager doesn’t sit down with the r&d team to analyze problems, then there are a lot of problems. When a requirement encounters a problem during implementation, which department is the problem?
Similarly, if our R&D department were structured like this:
Then in the process of research and development, online will still encounter a variety of communication problems.
Now, let’s go back and look at the full stack of big company experts and small companies.
Big company experts with small company full stack
If you often read technical articles about full stacks and experts, you will see different people emphasizing different directions. Big company articles like to emphasize being an expert in a field, and small companies like small, beautiful teams — full stack engineers.
As we can see, both large and small companies are solving different types of problems. For big companies to solve performance problems, small companies to survive depend on near-all-powerful people. What’s more, both large and small companies are working overtime. In this sense, we can find that big companies are actually exploiting labor.
experts
Most of the articles we see about technologists becoming experts are written by people who have already become experts in a technical field. And one of the things that we find interesting is that they’re all managers. Managers are motivated by recruitment, so they need specialists in specific areas to help them solve problems.
The whole stack
Similarly, most of the articles we read about becoming a full-stack engineer are written by Ctos at startups. Most of these startup Ctos are full-stack engineers, and they need to hire full-stack engineers to help them solve problems.
Two different learning models
And I wonder if you have noticed that experts are also emphasizing how long a professional is. Because there are few experts who rely solely on the technology of one field, technologists have to explore different fields according to the needs of the company. After all, “a company is a legally established form of enterprise with all its capital invested by shareholders for the purpose of making profits.” Management assumes that the technology itself is interchangeable, and since you have a fairly long board in the technology field, it’s not that hard to get into a new technology.
As technologists, we are experts in some subdomain of the domain. As such experts, it is not difficult for us to expand our study to another field. Drawing on our previous learning experience, we can quickly master the knowledge of this new subdomain. As we can see, we can quickly fill in the gaps in the diagram:
It is interesting to note in recent explorations that the learning time to become an expert is comparable to that of the full stack if you rely on the 20/80 rule. At the very beginning, we want our full stack engineering and specialists to achieve a level of 80 in a certain technical area.
Then the experts need another 80% of the time to go deep into the technical field. Full-stack engineers, on the other hand, can rely on 80% of the time to explore four new areas:
Although this is theoretically true, experts have cross-disciplinary learning disabilities – applying existing models. Full Stack also has learning disabilities – how to become an expert, but knowing how to learn new areas.
Ways to solve problems: Different ways
The interesting thing is that becoming an expert or becoming a full stack depends on human nature, which is also determined by two different personalities. Being a manager or a technician seems like a simple division, and being an expert or a full stack among technicians is another. It depends on the way people think about a problem: whether it can be solved externally or internally. Here’s a picture that illustrates what I think:
And that kind of thinking may vary a little bit depending on what happens, but it’s generally similar. When faced with a problem that requires wheels to be created, we see two different approaches.
For full-stack engineers, they like to rely on external thinking to generate disruptive thinking. Frameworks such as angular.js are examples where the front end is combined with the thinking of the back-end development language Java. Experts rely on internal conditions to create a different kind of adaptive innovation. Such as the popular Backbone framework, adapt to the situation at that time.
The future of full stack engineers: no stack
Full-stack engineers themselves should not be limited to front-end and back-end development, but should try to explore a wider range of fields — because the full stack itself depends on the learning ability of engineers themselves, and it is this excellent learning ability that enables them to access a wider range of knowledge.
Full stack short board
If you had tried interviewing full stack engineers, how would you interview them? Ask all the questions you know about different areas. Yes, that’s what companies looking for full-stack engineers will ask you.
It’s an obvious misconception that full-stack engineers can do everything — but it’s hard to change that misconception. In the end, the result is a perception that full stack engineers are just that good. In other words, people don’t know what a full stack engineer is. On a regular basis, your team knows that you are knowledgeable in different areas. For those who don’t know you, they assume you know everything.
So it becomes a stigma, and it’s a problem that’s hard to change at the moment. In this respect, we can only try to understand some general problems, but not all problems. In the process of being interviewed as a full stack engineer, an interviewer prepared several questions for me in different languages (Javascript, Java, Python, Ruby). I just wanted to say Ciao — Italian: Hello!
Except for this problem — people don’t know what a full stack engineer is. There is another problem, which is the age-old problem of becoming an expert.
There are two reasons why I choose to be a full-stack engineer without hesitation:
-
The world is full of unsolved mysteries, but I just want to solve the parts that interest me.
-
Where is true love without exploration? You haven’t even explored the world, so you say it’s your favorite field.
When I first saw the name full stack Engineer, I realized I was already a full stack engineer. Because my learning route is quite unique:
Primary and secondary school: programming language -> High school: operating system, kernel, game programming -> College: hardware, Web development -> Job: back-end + front-end
At that time, I was very interested in SEO, and I found that the analysis and Marketing seemed to be doing ok. And then Growth Hacking:
This is the advantage of full stack learning. If you have learned more, your learning ability will become stronger. As your learning ability improves, it becomes easier to move into a new area.
Baichuan.taobao.com is alibaba Group “cloud” + “end” core strategy is Alibaba Group wireless open platform, based on world-class back-end services and mature business components, through the opening of “technology, business and big data”, Provide mobile entrepreneurs with solutions that can quickly build apps, commercialize apps and improve user experience; At the same time, it provides diversified entrepreneurial services – physical space, incubation operation, venture investment, etc., providing comprehensive guarantee for mobile entrepreneurs.
About Alibaichuan
