[badminton1]

Being a full stack developer means being proficient on the frontend as well as backend. Unfortunately none of those tutorials prepare you to work at the backend of a production service.

To say you can do backend code because you can write in JavaScript is like saying you can write a paper on cardiology because you know English. Knowing the language is a small part of the job. There is a lot of domain knowledge that is required in addition to the language.

Learn networking, learn operating systems, learn distributed systems, learn performance and scalability, learn about databases. Then learn node.

[badminton1]

And as a small example:

Let's take a look at the "best practices" tutorial from nodeschool.io, one of the recommended tutorials.

https://github.com/excellalabs/js-best-practices-workshopper...

Can you list all the mistakes in this code?

- Using IEEE 754 floating point numbers (built-in Number type in JavaScript) for storing a balance is unsafe. Read more here: http://stackoverflow.com/questions/3730019/why-not-use-doubl...

- Your bank would never represent a balance in that way. They store transactions individually and they fold them to compute your balance.

- The input validation is extremely weak. Pass in: undefined, NaN, Infinity or some funny value and you will end up with a corrupted balance, or force "decreaseBalance" to increase, and "increaseBalance" to decrease.. The isValidAmount method should use "isFinite" rather than strong comparison with null.

And let's better stop here...

[Schaulustiger]

To be honest, I don't think that NodeSchool intends to give a primer on how to build a production-ready balance manager. They want to teach the basics of JS, that's all.

I agree, though, that those learning services give the impression that it's just about learning how to code and maybe use some design patterns. You won't find a security/authentication course on FreeCodeCamp or one about codebase maintainability, which is a shame.

[JDLongley]

This is great to show how smart you are, but what will a beginner who wants to use this resource think when they read your comment? People have to start somewhere.

[badminton1]

My point is to provide another perspective on what is the real entry barrier to backend programming.

Many people underestimate backend programming, and underestimate technologies only because they make use of a some scripting language like JavaScript, Ruby or Python.

I have seen millions of dollars wasted and jobs lost because of the harmful idea that backend development is for everyone and that anyone can do it after some simple training.

Production-strength backend development has become more productive because of better tooling, but not any easier. It still requires plenty of domain knowledge, discipline, rigor and attention to detail.

A functional prototype for a small startup might not strictly require a lot of rigor, but load test it or throw some millions of daily active users at it, or get a pen tester to see if it's secure enough or just advertise it and start receiving malicious users to see if holds up.

[majormajor]

Before really going deep into networking, OSes, distributed systems, perf and scalability, I'd say "learn monitoring, alerting, and dashboards, and then learn whatever your data indicates as issues."

Do that right and you'll have a much directed path towards what to learn next.

[badminton1]

Logging, monitoring, etc... is of no value if you do not have an intuition of what to monitor.

Monitoring is mostly reactive, to stay afloat you should focus on prevention: know your code, keep it clean, test it, do load testing... and monitor it.

[kaspm]

All of these answers are too simplistic. There's no single answer in what to learn to become a software engineer. If you have no development background, learning javascript, node, react is a way to start down the path then build your skills as you progress.

Personally, I recommend learning domain modeling and understanding entity relationships, primary and foreign keys then SQL. Great foundation for engineers at most companies.

[badminton1]

That is good enough if you are going to be supervised by a senior developer that can mentor you, but is still not enough to be an autonomous developer.

[mkalygin]

I agree. I'm mostly experienced in front-end and I like to work on back-end as well, but I can say that I feel a lack of practice on back-end side since I don't know everything you have mentioned.

What do you think is the best way to learn production best practices for back-end?

[badminton1]

First is to learn the difference between functional requirements and non-functional requirements. Usually functional requirements are explicit, and non-functional requirements are implicit. e.g: nobody asks for a service that doesn't crash, degrade or gets hacked. Those are implicit requirements.

Each one of those requirements comes with their own set of good practices. e.g: security good practices, maintainability good practices, configuration good practices, documentation good practices, etc...

Then, you don't protect a $10 bike with a $100 lock. There are tradeoffs that need to be taken into account.

[mawburn]

At the same time, it's hard for people to learn about those things in any real way without some understanding of how to put it into practice.

[nimchimpsky]

> Then learn node.

or don't bother, because its javascript.

[tannhaeuser]

Is this supposed to be a reference to churn in Javascript-land? I think "JS fatigue" is a meme of yesteryear (and frankly, something I hear only from those without any experience with it at all, or with an investment in alternate platforms). Node.js with its rich tooling and integrations is the platform to beat for Web apps (but not necessarily content-driven sites) still in 2017.

You don't have to use babel, webpack, and co.; there are (and always have been) simple make-based workflows eg. https://github.com/tj/mmake for asset management.

[badminton1]

Just out of curiosity, what do you suggest instead?

[nimchimpsky]

As a language for creating a web frontend, well there isn't anything really else. Coffeescript, typescript or something like GWT excepted.

But it will be a cold day in hell when I suggest using node for the backend.

[vinceguidry]

I personally recommend Rails. Still the best, after all these years.

[wapz]

I've talked to several back-end engineers recently and none of them recommended Rails because of the 'magic.' They have recommended Node w/express (most popular) followed by Django and for me personally (small project) they recommended Laravel.

[vinceguidry]

I don't want to get too deep into apologism here, but that's a common complaint by back-end guys who don't like the front-end. Rails is the solution for the solo developer or small team, the "magic" really helps in these scenarios.

If your project is big enough to require the skills of an experienced back-end guy, then you're so far past the learning stage that you might as well be in your rocking chair screaming at the neighbor kids.

[wapz]

Oh don't worry I'm not trying to defend the positions of those I talked to. I started learning Laravel for a small project I'm doing (I wrote some native iOS and Android apps and want to make a web interface for users to get their data). Do you recommend rails for that? I know close to no web (just basic html/css/javascript).

[badminton1]

Have you tried anything other than Rails?

[vinceguidry]

Sure, used a few other Ruby platforms, a Python one or two. What makes Rails work so well is Ruby. It's uniquely suited for building the kinds of abstractions you need to deal powerfully with the Web. The only thing it's really missing is a good UI library. I've been using Hyperloop, which puts together Opal and React, but it still needs a lot of time to mature.

[badminton1]

Because I've tried Rails, as well as Python, node, C#, Java, PHP and Scala based stuff and I find it hard to say Rails is objectively the best.