Why you should try "full stack"

Programmers see the concept of "full stack", and there are probably two kinds of reactions

1. Lying trough, this is good, bunker

2. You know Mao, the whole stack is everything.

Both of these reactions are in fact biased. Because even if only to learn a technology, the level of people who are very much, and all the stack of engineers do everything, and everything is done well. Not to mention the world there is another kind of explosion-type programmer, what to do, what is fine.

Starting with my personal practice, a full-stack apprentice must have at least the following skills:

1. Web Front-end development, at least master a front-end framework;

2. Server backend development, mastering at least one backend framework;

3. Server operations, to master the construction and maintenance of Linux server;

4. Client development, IOS and Android at least one;

5. databases, mastering SQL and NoSQL databases.

The title of the full stack should at least independently a person to complete the construction of a product, and really experienced commercial operation, and, by their own stupid pit countless times.

Thus, the entire stack of the threshold is still very high, not to say that mastering the above five skills, it can be called the whole stack, at least to add an apprentice to decorate, it is because too many apprentices boast full stack, just make others think "all stack" is "everything is" synonym.

However, the title of this article is-why you should try the whole stack, so I would like to discuss is not to do the whole stack, but try.

Layman and expert

Over the past few years, I have talked to a lot of teams and found that most of the team's contradictions lie in

• Server side do not understand the client, design out an API blind BB;

• Designers do not understand the client, design an interactive blind BB;

• Client does not understand the Server, the API blind BB;

• Clients do not understand the product, the demand for the blind BB;

• Product managers do not understand the needs of the Team blind BB.

In addition to the final product manager should be burned to death, the first four contradictions are still saved.

The programmer is a god-mode occupation, and the job of the day is to create, so the job looks cool. However, because of this, the programmer will be somewhat conceited, the result of conceit is to use their own limited knowledge to speculate about the work of others how to do .

If the Server side does not understand the client, it is easy to design the API that does not conform to the client mechanism. At this time, do the client side of the programmer patiently explain, each API delayed a day or two to run-in can also, bad words will quarrel.

But the Server side of the programmer is not always wrong, the client side hope that all the data will not need to be processed, but often in accordance with the structure required by the client, some queries may take two seconds. If the client does not understand the service-side mechanism, blindly to "service is to the client service" to demand, quarrel is difficult to avoid.

If the argument between technical people is the Cold war, then if the more layman of product managers or bosses, it will be a nuclear war.

"You just change the page, 10 minutes to get it done?" ”

"How can the effect be difficult to do, I'll make you a!" ”

"Tomorrow on-line, hurry!" ”

"I don't care what your technical difficulties are, you have to give it to me anyway!" ”

And the scene, no matter which company, is almost always on.

Try to understand each other's technology

Let's talk about my technical growth trajectory.

I started using Linux from Junior High, the main system is Ubuntu, then switched to ArchLinux, and then back to Ubuntu, has been used to a freshman, these years of Linux experience has laid the foundation of the Server architecture, freshman began to try to make a product of their own.

At that time, I should write a Web version, and then write a client.

So from the back end, I started with Django, but soon I moved to the rails camp, and the agile development of rails greatly reduced the cost of development, and its convention habits allowed the rookie to fly safely through many dangerous areas.

Start to write the front end of the page, do not know that there is a front frame this thing, until after using rails to find something called ember.js, so began to rewrite with Ember.js, the beginning of the understanding or how to use Rails to render the front end, and later found that it actually introduced the front end frame The role of Rails has become an API Server.

So starting from a new perspective to consider how to design the Rails API, read a lot of API design data, how to design the front-end to use, how to reduce query time, server cache, Redis, security and so on.

The automation of Rails has helped a lot, and many of the things that you don't know about it have helped, and when you want to know it, you'll find that its implementation is so subtle. Not to mention rails ' acceptance of new technologies, so that you always have something new to play with, Coffeescript and Sass are the first front-end technologies that rails absorbs as their own framework.

Then by Ember.js and switch to Angular.js, with Angular rewrite again, during the touch of the front-end tool Grunt (front-end changes rapid, now the use of something is not this).

Finally I started to develop iOS client, at this time the interface implementation of iOS and Web page HTML and CSS have a lot of different, so I spent a lot of time to understand the iOS UI concept, the thinking from the Web page to the interface development idea of iOS.

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

In the process of this technical exercise fortunately I am a person, so no one can quarrel, or I think at all stages there are a lot of places worth arguing about.

After I developed the project on-line, with the complexity of operations gradually increased, but also exposed to chef and Ansible this automated operation, and then newrelic this kind of monitoring services, and I for a stable development environment, and then use the Vagrant.

It all happened only in a year's time.

Interestingly, most of the time I write iOS client, suddenly I want to understand the HTML and CSS implementation principle, when doing Rails, suddenly came up with a better iOS architecture, the different technology between the comprehend by analogy feel on a daily basis.

In later times, this experience made it easy for me to communicate with different technical people, because I started to study OpenGL when I was a filter for last year, and after I regained my blender, a lot of the places I used to indefinitely, suddenly became as simple as Hello world, So it's just a matter of playing unity, and after all this accumulation, Unity's learning has changed so easily that it's been my evening's leisure project, and maybe soon you'll see a game I've done (probably RPG).

I don't think the whole stack will make you full of mediocrity, each technology can provide ideas for other technologies when you do it, and in the premise of understanding the various technologies, deep into one of these technologies, often can bring back to other technologies. On the contrary, understanding of the technology if very narrow, it is likely to limit their potential reasons.

Respect and peace

When communicating with the team, understanding each other's technology can reduce the cost of communication and bring about respect and peace.

Seldom see the great god together arguing who should come to give in, the opposite is often the first glimpse of the people all day noisy, temper a little burst.

Although it is difficult to say the level of the entire industry can quickly have a qualitative change, but I think if the product needs can be described in detail, explain why, the technical staff can learn from each other, patient discussion, the designer can respect the technical latitude of things, design more in line with the current prototype, then all will be good for the direction of development, It all starts with getting to know each other's work.

Source: http://www.ifanr.com/551905

Why you should try "full stack"