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

1. Holy crap, this is great, badass!

2. What the hell do you know? Full stack just means being mediocre at everything

Both of the above reactions are actually biased. Because even if you learn only one technology, there are plenty of people who are terrible at it, and among full stack engineers, there are quite a few who do everything and do it well. Not to mention there is another type of "stack-bursting" programmer in this world who excels at everything they do.

Starting from my personal practice,A full stack apprenticeneeds to master at least the following skills:

• Web front-end development — master at least one front-end framework;
• Server back-end development — master at least one back-end framework;
• Server operations — master the setup and maintenance of Linux Servers;
• Client development — master at least one of iOS and Android;
• Databases — master SQL and noSQL databases.

And obtainingthe "full stack"title should at least require single-handedly completing the construction of a product, and truly experiencing commercial operations, as well as being screwed over by one's ownstupiditycountless times.

From this, it can be seen that the bar for full stack is quite high. It's not that mastering the above five skills qualifies you as full stack; at least you need to add "apprentice" to modify it. It is precisely because too many apprentices call themselves full stack that makes others think "full stack" is a synonym for "mediocre at everything."

However, the title of this article is — why you shouldtryfull stack, so what I want to discuss is not whether to be full stack, but the trying.

Outsiders and Insiders

Over the past few years, I've talked with many teams and found that the vast majority of team conflicts arise because—

• Server-side people don't understand the client, so after designing an API, they just babble nonsense;
• Designers don't understand the client, so they design interactions while babbling nonsense;
• Client-side people don't understand the Server, so they babble nonsense about the API;
• Client-side people don't understand the product, so they babble nonsense about the requirements;
• Product managers don't understand the requirements, so they babble nonsense at the Team.

Except that product managers in the last case should be burned at the stake, the first four conflicts are still salvageable.

Programming is a God-mode profession; the daily work is creation, so this profession looks very cool. However, precisely because of this, programmers are more or less a bit arrogant.The result of arrogance is using your own limited knowledge to speculate on how other people's work should be done.。

If the Server side doesn't understand the client, it's very easy to design an API that doesn't conform to client mechanisms. At this time, if the client-side programmer patiently explains, and each API takes a day or two to iron out, it's still acceptable; if not, it leads to arguments.

But Server-side programmers aren't always wrong. The client side wants all data to be delivered without needing further processing, but if the data is structured as the client needs it, some queries can take one or two seconds. If the client side doesn't understand the server-side mechanisms and blindly demands on the principle that "the server exists to serve the client," arguments become hard to avoid again.

If arguments between technical people are cold weapon warfare, then encountering an even more unprofessional product manager or boss means a nuclear war breaks out.

"You're just changing a webpage — can you get it done in ten minutes?"

"How could the effect possibly be hard to make? Let me make it for you!"

"Launch tomorrow, hurry up!"

"I don't care what technical difficulties you have, you just have to make it happen!"

And this kind of scene plays out constantly in almost every company.

Try to understand the other side's technology

Let me first talk about my technology growth trajectory.

I started using Linux in middle school; my main system was Ubuntu. Later I switched to ArchLinux, then back to Ubuntu, and I kept using it until my freshman year of college. These years of Linux experience laid the foundation for my Server architecture. In my freshman year, I started trying to build a product of my own.

At that time, I was thinking I should first write a web version, then write a client.

So I started from the back end, using Django as my starting point, but I soon moved to the Rails camp. Rails' agile development greatly lowered development costs, and its convention-based habits also allowed rookies to safely fly over many dangerous areas.

When I started writing the web front end, I didn't know front-end frameworks existed. Only after finishing with Rails did I discover something called Ember.js, so I started rewriting with Ember.js. My initial understanding was still how to use Rails to render the front end, but later I realized that after introducing a front-end framework, Rails' role had already become an API Server.

So from there, I started thinking from a new perspective about how to design Rails' API. I read a lot of API design materials — how to design the front end to be easy to use, how to reduce query time, server caching, redis, security, and so on.

Rails' automation helped a lot; it had already taken care of many things I didn't even know about. And when you want to understand them, you find the implementation is so ingenious. Not to mention Rails' receptiveness to new technologies, which meant there was always something new to play with. CoffeeScript and Sass were originally adopted by Rails as its framework's default front-end technologies.

Later, I switched from Ember.js to Angular.js and rewrote everything with Angular. During this period, I also came into contact with the front-end tool Grunt (front-end changes at a breakneck pace; the tools used now are no longer this one).

Finally, I started developing an iOS client. At this point, iOS UI implementation was very different from web HTML and CSS, so I spent a lot of time understanding iOS UI concepts and converting my thinking from web development to iOS interface development.

During this period, the database also changed from MySQL to MongoDB, because the trend of those years happened to be this very shift.

Luckily, I was the only one in this hands-on technical process, so there was no one to argue with. Otherwise, I think there would have been plenty worth arguing about at every stage.

After the project I developed went live, as the complexity of operations gradually increased, I came into contact with automated operations tools like Chef and Ansible. After that, monitoring services like NewRelic were also added, and for a stable development environment, I used Vagrant.

All of this happened within only one year.

Interestingly, many times while writing the iOS client, I suddenly understood the implementation principles of HTML and CSS; while working on Rails, I suddenly thought of better iOS architecture approaches. The feeling of drawing analogies across different technologies happened every day.

In the later period, this experience made communication with different technical people very easy for me, because last year,for Miaoshi'sfilter development, I started researching openGL, and after reacquiringBlenderit, many places I previously half-understood suddenly became as simple as Hello World to implement. So I simply started playing with Unity as well. After all this accumulation, learning Unity became very easy, and it became my evening leisure project. Perhaps soon, you'll see a game I made (it might be an RPG).

I don't think full stack makes you mediocre across the board. When you're working with each technology, it can provide ideas for other technologies. And on the premise that you understand various technologies, going deep into one of them can often feed back into other technologies. On the contrary, if the technologies you understand are very narrow, that's likely the real reason limiting your potential.

Respect and Peace

In team communication, understanding the other side's technology can greatly reduce communication costs and bring respect and peace.

It's rare to see masters arguing about who should give in. On the contrary, it's usually those who have just gotten a glimpse of the field who argue endlessly all day and explode at the slightest provocation.

Although it's hard to say the level of the entire industry can rapidly change qualitatively, I think that if product requirements can be described in clear detail with the reasons explained, technical people can learn from each other and discuss patiently, and designers can respect the technical dimension and design prototypes better suited to the present, then everything will move in a good direction. It all starts with understanding the other person's work.

Author:Zhou Kaiwen

Original article URL: http://www.ifanr.com/551905