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.
And learning to code by reading a Rails book? Don't you have to know how to code 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.
"And learning to code by reading a Rails book? Don't you have to know how to code 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."
Agreed. As someone who has some coding experience (i.e. current CS student) but who is learning web dev, many parts of Rails/Django are way over my head. Rails/Django weren't designed for beginners. I've found starting with Flask which does considerably less than Rails/Django to be much more understandable. Sure I am probably often reinventing a shittier wheel but I think there is benefit in understanding what a full blown framework like Rails or Django provides before using one.
Also agreed here. I started really getting into programming on rails, and really regret it. The only reason I made it through was because I was an intern full time and had the guidance of a bunch of really smart people available the entire day.
I'm going to write a post about this specifically soon. I feel like it's this insane craze that rails is the way to go for people that don't know a single thing about programming, and it makes me sad that 99% of these people will end up dropping it because of this misguided notion.
I think a more accurate title would be "Code first, learn how to code later."
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.
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.
Its so true... Recreating apps you've already created in different languages is the best way I have found to learn a new language; its exactly like translating from English to Spanish to learn Spanish.
But, how about the people that don't know any programming language? If they had never engineered anything from the start through planning and designing and implementing, how can they begin to use a programming language they are beginning to learn? None of the tools that languages provide have a context for a new programmer, much in the same way that high school kids don't understand why math is so important.
I agree with your first statement in that "things" should mean something other than software. Maybe they should build a treehouse or a toothpick bridge or anything to get the process of creation and engineering into the mix of thinking about writing code.
I think that the most important concept that needs to be grasped when initially learning to program, is that big problems need to be attacked by breaking them up into smaller, more manageable sub-problems. If you solve each sub-problem and put them all together, you have solved your super-problem.
It's like the old saying, "How do you eat an elephant? One bite at a time."
Once someone understands this, you can show them Python or Javascript or whatever and basically go, "Here's the syntax to declare/call a variable, function/method, array, boolean test, iterative loop, etc. Now here's a real-world programming problem. Break it into smaller sub-problems and solve each of them using these tools, then put the steps together into a logical sequence to create a runnable program. Google the documentation for the language and its libraries if you get stuck."
Planning, designing, testing, etc. can be learned later. First you just need to take a problem, break it up into bite-sized pieces, and start taking bites.
This is why object-oriented programming is bad for beginners, by the way. OOP puts design ahead of problem-solving. You really don't always need to create an abstract model of a problem before you can work on solving it, but OOP forces you to do this.
Thats true, seems like that is what algebra books try to do when covering topics like factoring. You learn to factor and then, later on, you use factoring to solve a bigger problem.
You could teach in small chunks and work up to big chunks in order to illustrate to the student how the smaller chunks make up the whole, instead of starting with the whole and making little chunks out of it. It could make the process of learning to code less daunting.
I learned to program by doing the above method with Objective-C, an OOP.
Basically I made a Tip Calculator, and did it in a very functional way. Here was my thought process. I basically had one method, "didClickCalculateTip" - a button click-down. First I knew I had to take the user input as a string, and convert it to a float. Okay, Google, show me what you got. Then doing math on the float. Okay, now I have a result. How do I put that back on screen onto a label? Hmm, it won't let me set the string property of my UILabel to a float. Google: how to make a UILabel's text (string property) show a float. Okay, now print to the console to make sure it works. And voila.
So, using an OOP language isn't bad right off the bat, because I was able to plug in and figure out OOP design and principles by virtue of playing around with the language over time. I'm a pretty proficient Objective-C developer right now because I haven't stopped playing around with it over the past year and 3/4. Object-oriented design patterns aren't mystical, they make a lot of sense when you just think about them. I chose the language because my quest was to make an iPhone app I had as an idea (not the tip calculator haha) but needed to start somewhere to learn how to program. So I picked the tool that would directly translate to the product I actually wanted to make.
Objective-C is a language that has object-oriented features, but unlike Java, doesn't force you to use them. You just gave an example of a project where you didn't use an OO design pattern nor OO features beyond a superficial level (An NSMutableString object doesn't count). You used a more event-driven design pattern, which was more appropriate to the problem you solved.
Yes, obviously, but I made the point to show that shunning an OO language from the get-go isn't necessarily the best way to proceed if you want to learn programming from nothing.
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).
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.
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.
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).
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.
There are "introductory books", which can also be used as reference manuals. The beauty of them is that some of them are very accurate in their concept portrayal, but the concepts are in a order than lends itself towards learning the whole thing from the beginning.
Also, never felt the feeling of "Whoa, this is cool, I'll refactor this method using that?"
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.
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.
When you build it, it converts your source into gerber files to be sent to your 3d printer. It then physically builds the source code into a layered statue of syntax. Then you compile it, but don't ask me how, because I never got past that point.
Compilation is an advanced technique where for convenience you stack multiple silicon wafers into a single unit called a 'book' (colloquially known as a chip.)
The same goes for design when you're really talking about specifically web site design, graphics design, application design, software design or whatever.
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.
That is, if you want to be a programmer loved by your peers and those who inherit your codebases.
If you want to be a software engineer that can produce a large, complex, and high-quality product, learn to code.
If you're cranking out weekend-project websites (see author's examples) and $0.99 apps, you'll get by with a minimal knowledge of software development.
There is a difference between hobby and professional programming, but both are equally important.
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!).
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.
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.
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.
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.
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 love Codecademy, like, as an addict, but it doesn't teach anyone how to make anything.
This could probably be seen as a serious problem, but not a problem with Codecademy, more of a problem with society as a whole.
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.
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?
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.
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.
Its often said creativity fuels itself. We can all see what zero plus zero is though. The most we can hope for is to teach some tools and hope at least some people get carried away with it.
I completely agree but have a few words of precaution that might prevent somebody from falling into a trap that I did.
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.
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.
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 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.
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.
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.
I'm sure you can learn to love it but for me programming was something I instantly knew I wanted to learn everything about.
And learning to code by reading a Rails book? Don't you have to know how to code 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.