First, BOOKMARK THIS PAGE! There are going to be a lot of updates and valuable links / resources to dig deeper into from here.
If I could go back to when I was starting programming, there would be some "soft skill" things I would let myself know. These are highly opinionated things, so if they don't fit with your circumstance, that's fine.
Don't feel you have to memorize the language from end to end. I have been programming for 15 years and still utilize documentation, even for basic language concepts. There's too many intricacies to know everything by heart. Over time you'll grow rusty and have to dig up docs.
What matters most as a programmer is you having enough knowledge to synthesize components, understand code, and articulate challenges you are facing so you can support researching and resolving problems by yourself. When you're on day 0, you can't even articulate what you don't understand. So we want to get you over that initial hump.
And don't feel like you have to be gifted or become a star programmer over night. The only direct correlation for how good of a programmer you are is the effort you put into practicing it. It's no different than practicing any other discipline.
If I dropped programming the first time some person raised doubts of my potential - I'd be nothing. I have a long list of people who dished me the "tough news" that I'm unteachable, that I don't get it, that I "don't listen" to their big reveal I'm a washout and have to stop trying. Whether it was family, work, job interviews, school, whomever. Often, I'd be left to writhe in agony for a time, because they had the position to get the last word.
Doubters speak in vague platitudes with utmost confidence and nothing to back it up. As humans, we are instinctively sophisticated social creatures, and don't even notice it. I'm not a psychologist, but gained some street smarts from life experience and dealing with people - I've found there's no shortage of people feeling like losers to talk a winner out of winning.
What do doubters fear? They're afraid of a person just like yourself: Someone who is willing to work hard, be realistic, humble, and surpass them the honest way. To them, your success is their failure. They do things, often passive aggressively, to plant seeds of doubt, project their insecurities, all manner of behavior to sabotage your progress.
What if we could turn their negativity energy into your fuel. If they want you to fail, double down in your efforts. Do not enable their character flaws.
That's why it feels so great to work hard over months to improve yourself. You get to rocket past all the doubters and watch them turn to specks in the rear view mirror. Satisfying.
Many job interviewers are insanely bad at gauging your technical ability.
It's so bad, the market is filled with scammers who can't code, but just interview and talk well.
The more skilled you get, the more your peers will tend to downplay your achievements (e.g. it's easy, a gimmick, luck, and so on.) Particularly when they don't have them. Countless interviewers handwave my open source software projects and contributions, even my live websites during technical interviews. Despite portfolios being the quickest and best way to establish bona fides.
Portfolios: Better than nothing
Before you try to counter argument, it's not that you have to have a portfolio of work to prove yourself. Nor is it the only indicator.
Example: You have code published that demonstrates you can perform a role well, and someone says you're not qualified to do it, you've sniffed them out.
Public proof of your ability helps keep your sense of where you stand and clueless / insincere people in-check. More so than having nothing at all.
People who get stuff done feel they're behind, having gained metacognition to understand their deficits in an area. They have no need to justify or rationalize their failure by bringing out a yard stick. They have work to do.
The best strategy to win is to keep learning, regardless of what other's are saying. If you assume you are bad, and you study harder, you don't hurt yourself if it was them all along. Due to Dunning-Kruger, you will never be able to completely discern your own shortcomings from an onlooker overestimating themselves and underestimating you. It's always better to assume it's you who is ignorant and study twice as hard.
My point with this section for beginners is you can't let people psych you out of achieving goals. Maybe you already know it and it's common sense, but I think a lot of people struggle with dramatic fluctuations in their self-worth and ability in my generation. I'd rather be safe in airing these things out than not writing it.
A caveat: Do whatever helps you. If you're on a roll and feel like you're getting results, that last thing I want to do is step in your way.
If you have not attended one: Time for some street smart wisdom.
The average bootcamp costs enough cash to pay your rent, food, and seed a startup.
If they're affordable to you, go ahead.
This book has a whole section dedicated to all the free stuff. Once you exhaust all those, you'll be better informed and wise enough to figure out what / if you want to buy anything at all.
Even those who don't see themselves using it full time in the near future, I think it's worth taking the time to learn. I'd describe it as a solid all-rounder language with sensible tooling. Cross-platform. Fast to market, basically no build times (unless your packaging CSS/JS, and even that's quicker than most other languages).
To those who only have dabbled JS, it's a good language to practice. If you haven't touched JS in a while, and feeling a little rusty, you'll be delighted by the advancements in documentation, library quality, and the updates to the language standards itself (ES6 and beyond).
There's a high likelihood if you're a programmer, you'll have a need to glue together JS.
Open source libraries are abundant, active, well-documented, and well-maintained.
The community is solid, friendly, and welcoming across all experience levels. If you want to get your foot in the door with an open source commit, this is great place to start.
It's easy to begin. The package and import system is executed well thanks to npm and packages, reuseable code components you download from the internet, go right in your node_modules/ in your project directory.
Understanding the language well can help you learn other programming languages better, since it encapsulates some OOP concepts, some functional concepts (like callbacks).
It works on the browser, on the server (node.js), and on the desktop (electron)
There are two general ways to code JS:
Both are well supported.
High quality, well-maintained libraries
High quality build tools
Headache-free package management
npm, the package manager of node.js can be used to manage build utilities, server-side, and browser dependencies like jQuery. It's all done through a package.json file that's human readable. And also, packages are automatically detected, no need to worry about complicated PATH adjustments.
Fast Fast Fast packagement
Take it another level, you can speed up your package downloads with yarn
Fast. It's faster than Python and Ruby. While it's slower than C, C++, or Java in runtime, there's no build times with JS, so your feedback loop is fast.
Language A may be the fastest language, but there's not enough momentum to ship web apps to market with it. Language B may have great type safety, but the needs of meeting market demand and need to iterate fast make type safety more of a limitation to projects. Language C has mature libraries and tooling, but is verbose and has a long feedback loop. Language Z may be popular a social aggregator, but there's plenty of languages that have buzz that bring engineering teams to their knees in wasted time.
One improvement may be to block off the voices of those who make talk about languages but can't back it up. Take a step back, meditate, and see what language out there is giving you results.
Software engineering is inherently about tradeoffs. We can't throw out the baby with the bathwater and pick languages that haven't proven themselves to ship. Look at examples of other CTO's that have succeeded and failed. If you're going to go all-in, pick a language you can ship and iterate with, fast. A language with the most vibrant and active library community.
Maybe some may argue that JS is a scripting language, so not as fast as C, C++, and so on. This doesn't really take into account the arena JS competes in.
The issue with benchmarks (like Alioth's) is they don't deal with real world development. The typical JS script completes sooner than it takes to build apps in many compiled languages. It's meant for interactive applications, API's, websites, and geared toward bringing you to the market.
Those are qualitive factors you only get when all of the elements of an application fall in place, and a mere algorithm ran over 1000 times seems insignificant. If you're doing hard mathematical calculations, JS isn't trying to win that race.
The feedback loop is so fast I can run large test suites every time I save a file. There's no laggy IDE. It's nimble, yet featureful and powerful.
And relative to other scripting languages, it is very performant. And for the user, and the types of things you'd program for JS, it's also fast. That's stuff in your web browser, server applications, and so on.
If you're making a larger application, or really love type safety (coming from Java, C++, or C#, etc.), TypeScript is there. And it's pretty mature, even Angular 2+ and Visual Studio Code use it.
JS features a low barrier of entry, while still being able to take you to the finish line. Experts use JS. Large companies use JS at scale. GitHub championed electron and Atom.
There's more potholes in terms of handling state. There's need to have good aesthetic intuition and also solid programming skills to glue stuff together and do the finishing touches.
That's a pretty bold statement, let's repeat it:
continually programming in JS enhances programmer intuition and manifest reasoning
The basal level of code quality and design choices you churn will get better as you practice. The average work you do with JS will challenge you in so many ways. Build tools, scaling code, callbacks and event binding, closures and lambdas, objects.
You're going to see the same concepts in other languages, and after the developer has done JS for a few years, that innate skill transfers other places by making acclimating to concepts in other languages easier.
JS doesn't have monads, generics, or some obscure OOP smalltalk sugar.
Some language concepts, while meritious in other languages and paradigms, don't fit in JS as well.
Node.js (server-side JS) is, even taking browser JS out of the picture, one of the most popular programming languages. Server-side JS is used in production and at scale. Netflix, PayPal, Ebay, Walmart, LinkedIn.
I think it's safe to say, they get a fair share of traffic!
Imagine being able to hire easier, iterate faster, and not having to fumble around with multiple Android, iOS, and whatever other platform codebases.
It's a language that was too big to fail, but the ship was righted by it's community, who worked through it's rough edges through ingenuity and hard work. Abstraction libraries like jQuery, frameworks like Backbone that solved the headaches of binding, functional frameworks like Underscore.js that handles functional mapping across objects, countless open source projects played apart in what would culminate in ECMAScript bringing onboard new features inspired by what the community naturally begin integrating.
With a burgeoning community of coders and thousands of projects, there comes a need to keep things confistent. To handle the nuances across projects, teams, and codebases, a myriad of standards and linting work groups and tools have materialized:
Code Standards are specifications adopted by an organization or committee and published online so the world can see them. They change from time to time in popularity and the scope of their policies. In my hay day, it was idiomatic.js, in 2017, here are the hottest style guides:
Linting tools have evolved from checking for stuff that's definitely breaks, such as trailing commas in early version of Internet Explorer, to enforcing code standards.
The concept of code utilities in general has grown from unrealiable helper tools to deterministic, reliable helpers. Even for other languages like C++, clang-format supports Google's C++ Style Guide out of the box. Of course, it doesn't introspect for things beyond formatting.
Here are some of the knowing linters for JS:
Linters have configurations to disable rules for a reason. In some cases, certain ES6 features are considered bad practice by these community standard bodies.
For one, I still don't fully understand why for...of isn't allowed by Airbnb's standards as of 2017-11-07. It's cleaner code. I found their rationale about why ES6's for...of to be a bit muddy. Something about mutability. I consider mutability in for loops a feature and not an antipattern.