(Disclosure, reposting from my r/learnprogramming comment in 2015)
Here's what I wish I understood when I started programming, in 10 sentences:
"A computer receives, stores, and manipulates information.
Programmers refer to information as 'data'.
Data can be structured to represent concrete things - a song, a picture, a street address, an entire telephone book.
Data can also represent abstract things, such as the relationships between you and all of your friends.
Computers can only store data that can be represented as a collection of numbers.
This is where all those Zeroes and Ones come from - they are how the computer stores numbers.
Programmers write code, which is itself a kind of data, to tell a computer how to manipulate data.
Programmers break data manipulations into small, understandable steps, and then compose the steps together.
Programmers create abstractions by finding patterns in code and giving those patterns or ideas a name (and often a theoretical background).
Programmers gain productivity by layering abstractions, at the cost of not understanding or controlling the entire system."
This really helps me think about coding as the process of writing data transformers. If I can represent something as data, then I can manipulate, transmit, and store a representation of that thing. I can allow users to control how the data is manipulated through a user interface.
It also helps me gain clarity around my next steps. What data do I need to accomplish the task? Where does that data live, and where does it need to be? How can I get the data that I need from the data that I have, or from the people who interact with my code.
Perhaps most importantly, it helps me grapple with leaking abstractions - and it helps me understand that there is always some cost paid for the abstraction, whether it's a lack of control over a program's runtime environment (with garbage collection, for example) or merely a more complex compiler or interpreter.
It's never necessary to understand everything that a computer is doing, but when something unexpected happens, it is important to be able to peel back the abstraction onion and figure out where ones mental model of a computational task diverges from reality.
Also, do check out r/learnprogramming for better resources than you will find on HN.
I'm ridiculously excited about this. The original tessel was an amazing step away from the dichotomy of Arduino | Embedded Linux, allowing you to focus on what makes your project different instead of fiddling with breadboards or operating systems. Sound familiar, Rails / Django devs?
The coolest thing is that it's a fairly modular product, instead of being some custom monolith that tries to solve every problem for you. It hooks into npm and the command line, and runs JavaScript.
Unfortunately, the Tessel1 ran Colony, a custom implementation, which didn't do well with things like Bluebird promises (Q promises worked, but slowly) or generators or observables. Most hardware projects are actually reactive systems, and those are difficult to build with an Arduino. Coordinating callbacks is very painful.
I can't wait to get my hands on a Tessel2. Hardware has been needlessly hard for too long. Glad to see hardware hackers adopting more hard-won solutions from the past 6 decades of software engineering.
If you're going to make comparisons, you need to compare the ecosystems and not simply focus on specific details. Focus on being clever at the system level, not on the line of code level, and you will be considered great.
Lua's ecosystem is nowhere near as mature as JavaScript's.
Great points. I often forget how many of my breakthroughs come from careful reflective synthesis, and I forget that, in general, it's a slow process.
It turns out, immersive learning is absolutely capable of compressing synthesis time as well as knowledge transfer. One of the best parts of Hack Reactor is the time after the 'solution lecture', during which everyone gets the chance to reflect on their code and solutions and discuss macro and micro optimizations that were possible.
For general reflection, Socratic seminars are a great way of condensing the synthesis time. Those who have had small epiphanies share them, and hopefully it avalanches.
But you're correct. The deepest learning is very personal and requires effort, solitude, and time. Immersive learning gives you the trunk and knowledge of a few select branches, but if you want to see the leaves you must find them yourself, or at most with one other person. In Hack Reactor's case, only half of the course is absorbing information. The second half is left to projects, during which synthesis must occur and individuals specialize and gain deep knowledge.
500+ hours of steady research and application is nothing to scoff at, especially since it happens while connected to a huge wealth of intellectual resources (I worked directly with Neo4j peoples for a project).
(Disclosure: I'm a college dropout who went through Hack Reactor and can, for the first time, afford a comfortable lifestyle)
Hack Reactor focuses entirely on JavaScript and Web Development, after baking in the basics (algorithms, logical thinking, recursion vs iteration, introductory functional programming and TDD). And it is incredibly successful.
I think you're underestimating the difference between college and immersive learning. College is about many things, your major and focus being one of them. Immersive learning is about one thing. In Hack Reactor's case, it's becoming a competent Web Developer.
Elon Musk's response in this thread (https://www.reddit.com/r/IAmA/comments/2rgsan/i_am_elon_musk...) rings true. Almost no college is teaching Web Development, and so the students get little class based exposure to it, and stumble through many pitfalls. An immersive experience gives you the trunk and several branches, and then frees you up to go deep into whatever you care about.
And smart, voracious people who are eager to learn and better themselves quickly outclass everyone else.
Oh, and I could code competently before I went to Hack Reactor (I was a contractor). I went to gain deep web experience, work in crossfunctional teams, and have a safe place to fortify the foundational soft skills which are absolutely essential for productive software developers.
"A computer receives, stores, and manipulates information. Programmers refer to information as 'data'. Data can be structured to represent concrete things - a song, a picture, a street address, an entire telephone book. Data can also represent abstract things, such as the relationships between you and all of your friends. Computers can only store data that can be represented as a collection of numbers. This is where all those Zeroes and Ones come from - they are how the computer stores numbers. Programmers write code, which is itself a kind of data, to tell a computer how to manipulate data. Programmers break data manipulations into small, understandable steps, and then compose the steps together. Programmers create abstractions by finding patterns in code and giving those patterns or ideas a name (and often a theoretical background). Programmers gain productivity by layering abstractions, at the cost of not understanding or controlling the entire system."
This really helps me think about coding as the process of writing data transformers. If I can represent something as data, then I can manipulate, transmit, and store a representation of that thing. I can allow users to control how the data is manipulated through a user interface.
It also helps me gain clarity around my next steps. What data do I need to accomplish the task? Where does that data live, and where does it need to be? How can I get the data that I need from the data that I have, or from the people who interact with my code.
Perhaps most importantly, it helps me grapple with leaking abstractions - and it helps me understand that there is always some cost paid for the abstraction, whether it's a lack of control over a program's runtime environment (with garbage collection, for example) or merely a more complex compiler or interpreter.
It's never necessary to understand everything that a computer is doing, but when something unexpected happens, it is important to be able to peel back the abstraction onion and figure out where ones mental model of a computational task diverges from reality.
Also, do check out r/learnprogramming for better resources than you will find on HN.
(Edited to better match HN style guidelines)