Where "things" still means "software."<p>I think a more accurate title would be "Code first, learn how to code later."<p>And you're probably right. Personally, I learned how to code in PHP because my company needed a web app for something, so I bought a basic web programming textbook that happened to teach PHP/MySQL, read it for a week or two, and then started building the app.<p>Now I have a few different "stock" scripts and applications that I've implemented, and when I want to learn a new language, I learn by studying the new syntax for a week or two and then dive right into re-implementing some of my existing scripts & applications in that language as my "homework," and just googling things whenever I get stuck. I think this is a pretty good way to learn programming outside the classroom.
Why are "things" and "build" mutually exclusive from software (addressing other comments here, not the article)? I think physical vs information is a bit arbirary (and often overlapping in true contexts of projects).<p>I think that the article's main point is learning by doing vs learning by instruction - and it applies to software as well as physical things. I tend to agree pretty strongly that this is a better - and more fun - way to learn.<p>I was on the solar car team in college. Most of the people on the team were engineering students, but without a doubt the most valuable guy was doing a graduate program in ligustics. He had no formal engineering or design training, but was very hands-on and could design and build pretty much anything. He still stands as the best "hacker" of mechanical arts I know. In contrast, most of the engineering students (myself included) were pretty useless at design until we took a more hands-on approach to it.<p>On a flip to this, I'm doing a PhD now in biomaterials engineering. Even the "exparimentalists" (myself included) in the group usually spend more time using and writing software than in the lab.
I particularly don't like this approach to programming. Building things is an important aspect while learning to program, but it should not be learnt by just googling and figuring out how to do a particular thing. I think learning to code neatly in a language and learning what a particular construct does, is really important before you start googling and copy pasting things from stackoverflow. With the above method, you can become a decent guy/girl who knows to put things together, i.e. build skins over databases(as quoted in a previous HN article).<p>If you take this approach, then you would have learnt some aspects of the language, and hence won't have the patience to go through an introductory book again. I programmed in python for a year without knowing how python variables are actually names, because I was too impatient to go through a introductory book.
I was getting ready to launch into my usual serenade of "totally agree, learn how to build tangible things if you can afford the time and money, coding is mainstream these days, hardware skills is what can set you apart". Until I realized the author isn't talking about building things at all. By "building" he really means "coding". And his point is to code instead of not code. Fair enough.<p>But seriously people, don't use the word "building" when you talk about virtual things. In your bubble writing software might be the only kind of creative work there is, but in the world at large, building is associated with the construction of tangible results. And while I am ranting: Don't use "engineer" as if software engineering is the only engineering discipline either.
Please learn how to code. Please read the old-timer's books (K&R, Pike, Unix classics and manuals, etc.). Please learn about writing useful comments, following the KISS principle, and avoiding fancy stuff just because it is fancy and happens to be a fad du jour.<p>That is, if you want to be a programmer loved by your peers and those who inherit your codebases.
I love this. This topic came up yesterday at a SXSW panel on getting young girls and women interested in programming. We think a key factor in getting more women to want to join the tech industry is to stop talking about learning to code and algorithms, and start talking about how software can be used to solve problems and to help people (building stuff!).<p>Learning something complex for the sake of leaning is appealing to some people, but not everyone. For some people, that first website can be very empowering. It can be a gateway to trying to solve increasingly complex problems with code.
I agree with most of this. What got me really going on programing was an idea I had that kind of existed, but not really, so i set out to learn how to create something PERFECT(still not there). Anyway, my point is, having a goal that you personally really want to achieve is a fantastic motivator.<p>With that said, i totally disagree with the idea that you should be able to build a functional prototype in a weekend. That's crazy talk if you're truly trying to create something worthwhile. Sure building a practice site in a weekend to get you hands a little dirty, and kind of get a feel for the way things work is a great idea, but if you start with the goal of building a prototype of your masterpiece in a weekend, you're surely setting yourself up for a fantastic failure, and probably get demotivated and quit. I think it's a better idea to dabble a bit with some fun practice and then get an idea of what you're building entails, then set a realistic goal(aka 4x what you think it'll take you) and set out to make something great.<p>Just my 2 cents.
Very nice. I totally agree. The reason why I picked up programming in the first place is not to become an 'uber geek', but simply to build cool things.<p>Apparently this same sentiment is held by Zuckerberg as well in his code.org video. "It didn't start off as this mission to learn all of Computer Science, but rather build something cool that me and my sisters could use."
I was not impressed with Codeyear last year for this exact reason (and I did it with coding skills; I just did it for interest to fill in any gaps as I'm self taught). What started as JS then moved to HTML/CSS (fair enough, they do relate to each other) … and then in the last four months switched entirely to Python! At the end I didn't know whether I was coming or going.
I love Codecademy, like, as an addict, but it doesn't teach anyone how to make anything.<p>This could probably be seen as a serious problem, but not a problem with Codecademy, more of a problem with society as a whole.<p>Codecademy DOES provide people some of the tools they'll need to make things with computers. And another tool in the kit is always a good thing. Makes us better makers.<p>We can give people knowledge, we can teach them how to think, but if they don't know how to DO anything, what are they going to do with all of their ideas?<p>In my experience people usually just need to be enabled to become makers. Tell them "You could make a thing! A Cool thing!" and if they believe you, they'll go out and prove it.<p>This article is useful in that way, it might enable folks to start using whatever they do have in their toolkits to start producing. Creating value.<p>But "Don't learn how to code"? That's just silly.
I completely agree but have a few words of precaution that might prevent somebody from falling into a trap that I did.<p>My advice is DO buy high quality books/courses that teach the fundamentals too. Scan them so you know what kind of stuff you can learn from there. When stuck making something try to learn the hard way.
Learning from blog articles/tutorials like "How to make X" that give you prepackaged answers is just very unproductive in the long run. Been there, done that.<p>Also keep in mind that when you're working with other people knowing the right jargon is very useful. It will make you better at finding the right answers on Google too. Speaking jargon is the natural language equivalent of high-level programming.
Why are there so many persons saying it's better to build something specific and be creative than to learn to code? That we should learn to code as a mean for something? I enjoyed coding that AVL tree class last week, just for the sake of it. I like solving Project Euler's problems and bash my head for hours on really complex problems.<p>I don't have to aim for something bigger to enjoy coding and I don't understand why so many people claim the opposite. When it gets to the trivial parts of a project, I just get bored and never finish them.
Absolutely. Learning to "code" by taking codeacademy lessons, is okay but you don't get a product you can maintain, tweak, and break. In my experience if you set out to make a thing and do whatever it takes to make that thing, you will learn more and have something to come back to and refine constantly. Plus it teaches you to break a problem into steps and you learn where to find good info. It may mean that you miss some fundamentals, but you can come back to those if you decide to stick with it.
This is why when people ask me how they should learn X web technology, I usually tell them to pick something they want to use, and make it. It's a ton more motivating.
I think "making things" is overrated. I think because the majority of people rely on computers to do things, from finding apartments to sorting data/information, that for beginners, it's better to "make your own life better". I guess it is non-trivial to realize how your day-to-day tasks in your professional life can be streamlined/improved by simple scripts, but no harder than it is to build a basic website that isn't amateurish.<p>And learning to code by reading a Rails book? Don't you have to <i>know how to code</i> before you build even a basic Rails app? Even average coders can't easily grasp all the concepts behind building a full-fledged web app, nevermind someone who barely knows what a for loop is.
I love to make my own web apps. I made my own system for cloud bookmarks, sharing, notes, contact, news feed, etc. I prefer making it because then I can tweak it and modify it the way I want without having to wait on some company. But I dislike coding, I hate syntax errors, or debugging code for an hour because of a dumb mistake. I could never be a full time coder. But I still love making things.
As a developer, I have great power to make things (web apps) that my internal business partners can barely dream of. I am working on using SignalR in .NET 4.5 to create some great working proof-of-concepts (MVPs as you call them). This is yet another great year to be a developer given SignalR, Meteor, Knockout/Angular/Ember/Backbone, Boostrap, etc.
Hands-on is key but after 30 years of programming I still feel the same excitement when I get my first program running in a new language as I did on my Apple ][ back then.<p>I'm sure you can learn to love it but for me programming was something I instantly knew I wanted to learn everything about.
Agreed! An MBA type at a hackathon abruptly told me that writing code (the thing I do for a living and often for fun) was too boring. I said that if you want to make something bad enough, you'll figure it out. He told me at the end of the day that he'd started learning HTML. It's a start.