Why You Should Try Full Stack

When programmers see the concept of full stack, they probably have two reactions

1. Damn, this is good, it's awesome

2. You know nothing about the full stack.

The above two reactions are actually biased. Even if they only know one technology, there are many people who are very bad at it, and there are also many full-stack programmers who are good at everything, not to mention that there is another type of programmer who is a master of all stacks and is good at everything.

Full-stack apprentices must master at least the following skills

Web front-end development, master at least one front-end framework

Server backend development, master at least one backend framework

Server operation and maintenance, master the construction and maintenance of Linux Server

Client development, master at least one of iOS and Android

Databases, master SQL and noSQL databases

To be called a full-stack developer, one should have at least completed the construction of a product independently, and have actually experienced commercial operations and been pitted by his own stupidity countless times.

From this we can see that the threshold for full-stack is still quite high. It does not mean that if you master the above five skills, you can be called full-stack. At least you have to add the word "apprentice" to modify it. It is precisely because too many apprentices claim to be full-stack that the second reaction is so widespread.

However, the title of this article is - Why you should try full stack, so the point of discussion is not whether to do full stack, but to try.

Laymen and experts

In the past few years, I have talked with many team members and found that most of the team conflicts are caused by -

The server side doesn't understand the client side, and after designing an API, they talk nonsense.

The designer does not understand the client, so the interactive design is a mess

The client does not understand the server and talks nonsense to the API

The client does not understand the product and talks nonsense about the requirements

The product manager does not understand the requirements and talks nonsense to the team

Except for the product manager who should be burned to death, the first four contradictions can still be solved.

Programmer is a god-mode profession, and their daily work is to create, which is why this profession looks cool. But because of this, programmers are more or less conceited, and the result of conceit is to speculate on how others should do their work with their limited knowledge.

If the server does not understand the client, it is easy to design an API that does not conform to the client mechanism. It uses the thinking of web pages to understand the client. If it is good at this time, it will be patient to explain the client and spend one or two days to run in each API. If it is not good, there will be a quarrel.

But the server is not always wrong. The client wants all the data to be given without further processing. If the structure is given according to the client's requirements, some queries may take one or two seconds. If the client does not understand the server's mechanism and insists that "the server is there to serve the client", there will be another quarrel.

If the debate between technical people is a cold weapon war, then if you encounter a more layman's product manager or boss, a nuclear war will break out.

"You just edit a webpage. Can you finish it in ten minutes?"

"How can the effect be difficult to make? I'll make one for you."

"It will be online tomorrow, hurry up"

"I don't care what the technical difficulties are, you just have to make it happen for me."

Such scenes are happening almost all the time, no matter which company it is.

Try to understand the other party's technology

Let me first talk about my technical trajectory. I started using Linux in junior high school, with Ubuntu as my main system, then switched to ArchLinux, and then returned to Ubuntu. I continued to use it until my freshman year. The experience of using Linux in these years laid the foundation for the Server architecture, and I started to try to make a product myself in my freshman year.

At that time, I thought that I should write a web version first and then write a client.

So starting from the backend, I used Django as the starter, but soon I moved to the Rails camp. The agile development of Rails greatly reduced the development cost, and its conventions and habits also enabled rookies to safely fly through many dangerous areas.

When I started writing the front-end of a web page, I didn’t know there was such a thing as a front-end framework. It was not until I finished writing it with Rails that I discovered there was something called Ember.js. So I started to rewrite it with Ember.js. At first, I understood how to use Rails to render the front-end. Later, I found that after the introduction of the front-end framework, the role of Rails has become an API Server.

So I started to consider how to design Rails API from a new perspective. I read a lot of information on API design, how to design the front end to be easy to use, how to reduce query time, server cache, redis, security and so on.

Rails' automation helps a lot. It has helped me with many things that I didn't know about. When you want to learn more, you will find that its implementation is so exquisite. Not to mention Rails's acceptance of new technologies, so you always have new things to play with. CoffeeScript and Sass were first absorbed by Rails as the default front-end technology of its own framework.

Then I switched from Ember.js to Angular.js and rewrote it with Angular. During this period, I came into contact with the front-end tool Grunt (the front-end changes rapidly, and the tools I use now are no longer this)

***When it came to the iOS client, the interface implementation of iOS was very different from the HTML and CSS of the web page. Therefore, it took a lot of time to understand the UI concept of iOS and convert the thinking from the web page to the iOS interface development idea.

The database was also changed from MySQL to MongoDB during this period, because this was the trend in those years.

Fortunately, I was alone during this process, so there was no one to argue with. Otherwise, I think there would be a lot of things worth arguing about at every stage.

After the project was launched, as the complexity of operation and maintenance gradually increased, we came into contact with automated operation and maintenance methods such as Chef and Ansible. Later, monitoring services such as NewRelic were also used. In order to have a stable development environment, Vagrant was used.

And all this happened in just one year, but the interesting thing is that many times when I was writing iOS, I suddenly understood the implementation principles of HTML and CSS, and when I was working on Rails, I suddenly came up with a better iOS architecture method. The feeling of learning by analogy between different technologies happens every day.

In later time, this experience made it very easy for me to communicate with different technical people. Because of the filter I made last year, I started to study OpenGL. After picking up Blender again, many things that I didn’t quite understand before suddenly became as easy to implement as Hello World, so I just started to play with Unity. After all this accumulation, learning Unity became very easy and became my leisure project in the evening. Maybe soon, you will see a game I made (it may be an RPG).

I don’t think that full stack will make you mediocre in all aspects. Each technology can provide ideas for other technologies when it is used. On the premise that you understand various technologies, deepening one of them can often bring feedback to other technologies. On the contrary, if the technology you understand is very narrow, it is likely to be the reason for limiting your potential.

Respect and Peace

When communicating within a team, understanding each other's technology can greatly reduce communication costs and bring respect and peace.

It is rare to see the masters arguing about who should give in. On the contrary, it is often the beginners who quarrel all day long and their tempers flare up at the slightest provocation.

Although it is difficult to say whether the level of the entire industry can undergo qualitative changes quickly, I think if the product requirements can be described in detail and the reasons can be made clear, if the technical staff can learn from each other and discuss patiently, and if the designers can respect the technical dimension and design prototypes that are more in line with the current situation, then everything will develop in a good direction. It all starts with understanding each other's work.