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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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).
Rails works great for every web task except the very big and the very small. Very small being anything you'd want to put on a Raspberry Pi.
The learning curve is reasonable, and can be made easier if you get the basics of both Ruby and MVC down by using a simpler Ruby framework like Sinatra to build out a few toy apps before jumping into Rails. Once you feel like you need more out of a framework than Sinatra can give, it's time to switch to Rails.
Ruby and the web go together like Captain and Coke.
Haha okay thanks for your advice. I'll definitely look into Ruby before building anything, then. Sounds like Sinatra might be better for me to start with if it's the simpler of the two.
Laravel is just fine for that job. If you do not have a strong reason to change, keep on learning. It has an excellent documentation, has a great ecosystem (email, search, background jobs) that you have to assemble yourself with lightweight tools such as Sinatra or Flask (Python). For a beginner the complexity of tools is overwhelming, Laravel makes smart decisions for you. Plus, Laracasts.com is by far the best learning resource I know for any language.
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.
This barely touched on what you need to become a competent front end developer and the aesthetic competency you need to have to make something look nice. This is the thing I most often see as completely stopping backend engineers from becoming "full stack".
So true. Full stack is understanding the layers of a modern web stack like basic webserver/port binding knowledge, basic unix skills, http, DNS, rest, serving apis, consuming apis, using queues for background jobs, database schema, avoiding n+1 queries, authentication mechanisms for browsers and clients, email (dkim+spf), serving assets, handling browser caching issues, the list goes on... an SPA with react is really just touching the surface.
I don't think aesthetics play very much if any role in being a effective front end developer. Look at Craigslist the thing is terribly ugly and dated but still widely used and functional. The aesthetics look like someone with no taste in design or modern UX wrote it. If someone writes the next CraigsList by your definition are they not a successful front end developer? Sure having a taste for design is nice but hardly necessary to be successful at the craft.
Craigslist has a great minimalist interface. There's a lot of ways it could go wrong, and it avoids a great majority of them. That said, I don't think a lot of development has gone into actually considering their use cases and developing workflows that prefer them.
Obviously, it's still a very useful site regardless, but I would not call it a well designed site.
Exactly. Craigslist work because it doesn't use huge images, scrolly this, flashy that. It works because it uses links as they were meant to be used. It works because it is terribly easy to navigate.
If a "proper designer" got hold of it, they'd ruin it.
I find it really laughable that companies think you can separate these things. I realize that is the popular opinion but it what has gotten us into this situation in the first place. We have all these "pretty" sites that are unusable. It's an increasingly common skillset and you might as well get a pragmatic person to handle both.
There are lots of products that don't have great design. We're on one now. But there are tons and tons of B2B products shipping from full stack developers every day that don't have great design. But they work, and because they work, they make people happy.
Good aesthetics are nice when you have them, but are absolutely not a requirement for a good piece software so long that it does it's job and the UX doesn't suck. Most real world people don't care how it looks as much as a lot of designers think they do.
Not too imply design isn't important for a real product. But if you're hiring full stack developers, then you're probably not making a ton of comps.
Was HN built today? :) In both cases, you are talking about websites were there's minimal interaction with the website and all you do is read. While that's ok for certain kinds of products, it's not for all of them. So I think we agree that design doesn't make the software, but most devs are used to having weird interfaces and interactions that aren't always clear to normal users. (I'm saying this as a full stack dev myself while looking at the colleagues that I've worked with in the past/present)
It sounds like you're talking about UX. There is quite a bit of intersect, but you can have fantastic UX and still be aesthetically gross. You can't have a weird interface that doesn't make sense and still claim to have a good user experience.
And on the other side, an app can be aesthetically beautiful and total have crap UX, which is too common with a lot of startuppy products.
Being built "today" doesn't have anything to do with it.
Although they have better UI/aesthetics, from a UX perspective, Google and Amazon famously hew pretty closely to their original product design.
What matters to these companies - and, more importantly, their customers - is delivering the content that the customer wants, at the fastest possible speed.
You have a valid point. Do you have pointers to learning Design for a programmer? I know about book 'Deisgn for hackers' and there are many resources on Photoshop/Sketch etc. but I haven't found nifty little projects like you have in programming where you design, say a toy compiler. Also Photoshop/Sketch are paid and/or platform specific. Any useful pointers would help.
Shameless request for advice - what's the simplest way of deploying stuff to a VPS?
I want to somehow set up an identical environment on my dev machine, and on a VPS in another continent (too much latency to edit files on directly). Ideally I'd then be able to deploy from a dev environment identical to my production environment. I tried docker but debugging the containers did my head in. I was thinking of trying VM images with vagrant, but I'd love to know if there is a simpler solution to this.
I use nodemon to watch /home/deploy/web/site/ for changes, which restarts the server. There are tools like nodemon for whatever stack you're using (rails, etc).
Maybe I am biased, but I agree with the other user on here that Ansible is a good solution for keeping the environments the same.
However, if you're feeling brave, you should definitely check out OpenShift (community version at http://openshift.org). OpenShift is basically Kubernetes with a bunch of cool stuff added, one especially useful feature is source-to-image.
It pulls your code from a scm repo and finds a builder image (or you can choose one) and it will build the docker image for you. You can have it pull whenever there is new code and rebuild the image and deploy if you want.
On top of that you get lots of cool docker orchestration features.
I really like Ansible. It provides a declarative framework for defining "roles" a server might have, and requires a minimal toolkit to get started- no images to deploy; just define the state the server should be in at the end of the playbook.
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.