DHH: How do I learn to program? | Hacker News Reader

DHH: How do I learn to program?

37signals.com

145 pointspietrofmaggi89 comments

This is more a description of "how to type in code that appears to solve today's problem". But that's not programming, that's code monkeying.

To learn how to write real programs, you need to read real programs. Is Emacs bugging you? Open the source and see how it works. Web server crashed? Read the source and fix the bug. Not sure how to configure cron? Take a look at its config parser!

Many "programmers" spend their entire life treating everything as a black box. Take a look inside the box! That's how you really learn to program.

nice strawman.

If you have a real concrete goal, and your web server crashes, you'd try to fix it just like you say.

Actually, I don't believe that was what DHH meant. Everyone is going to write a spaghetti mess starting out. The only way to learn from that is to write more and more code(that you'll need to maintain) and teaching yourself what well designed code is and why it matters.

Definitely this. I got a BS in Computer Science and started along the path of Software Engineering while working towards my Masters. Learning some good fundamentals helps, but my code was still a mess. Writing code that you'll actually have to look at again is the best way to become a good programmer.

You could disagree with anything if you tried to. But can you see any merit to the 'need a goal to guide your learning' point of view?

That wasn't the point of his counter-argument. That a stance has some merit does not raise it above criticism.

To tell someone new to programming to open the emacs source and start reading it is not really friendly.

I'd start with something considerably lighter than that, but I do agree that reading code is a really important part of really learning how to program (well).

As for 'code monkeying' not being programming, I disagree with that, programming is the creation of specific instructions in order for a computer to reach a certain goal and I couldn't care less what the goal was or the way in which you arrived at your program. I'd definitely not go so far as to demean anybody that got in to coding that way, just like not everybody can be Michaelangelo we can't all be Peter Norvig.

From Excel to LISP and everything in between, it's all programming.

No, I agree. Looking at a large program can be a college education. Looking at toys is what the article complained about: you learn how to make toys.

You can't begin to understand something the size of emacs before you've taken a bunch of steps in between, and looking at 'toys' makes you understand how toys are put together as well as gives you the skills you need in order to appreciate what makes stuff tick one 'level' up from there.

When I was a kid my 'toy' programs would be a few hundred lines of assembler or basic, rarely beyond that. Then the first time I hit a thousand lines (a score editing program) I realized that my old techniques didn't work any more and I discovered structured programming. This worked well for a while until the limits of organization for a single file were reached and I had to start splitting up the code in to large chunks that 'belonged' together in separate files and so on.

And that's just the organizational stuff, never mind the actual code or data structures.

To throw someone in on the deep end of that and saying 'Swim!' is not going to work except for a very few people that are genius level. The GGP might be one of those but for the rest of so (let's say ordinary mortals) that's not how you learn the fastest.

Of course, once you're ready for a 'big' program (say 50K lines and up) it really will be a great step forward, once you've mastered to read (and work on) a program of that size it will be a huge achievement.

I've never met someone that learned how to code out of the gate by studying emacs though.

And don't underestimate how much you can get done with 'toy' bits of code, libraries are so easy to tap in to that a few hundred lines will go a long way if all you want to do is solve some problem.

Check out some of the more involved 'R' programs that float around here for good examples of that.

I disagree; you don't need to understand all of Emacs to read the source code. You type "C-h k", press a key, and then the source code for the key you just pressed is displayed. It's written in a simple procedural style. Now instead of guessing how that works, you know.

You might be adventurous and read the rest of the file. Now you know how a whole major mode works.

Before you know it, you are applying those techniques to your own code without realizing it -- and now your code works like the rest of Emacs.

Show me any Emacs extension on the Internet, and I can tell you exactly how the author learned Emacs Lisp -- that's how different "I learned everything myself" and "I read the Emacs source code" methods of learning are.

You can change this now to be about a single small module in emacs, but originally you wrote:

> Is Emacs bugging you? Open the source and see how it works. Web server crashed? Read the source and fix the bug.

Both emacs and web servers are major programs, and analyzing them 'from the source' for debugging purposes is a different thing than analyzing how a single minor module works in it's normal environment. Debugging can have you rooting around in the basement fairly quickly, which is more than likely to overwhelm a novice.

Sure, emacs is built that way, but Lisp code isn't quite as easy to understand and debug as you make it out to be (judging by the number of people that hack around in emacs vs those that don't) and you have to keep in mind that you are very good at this, so it may be a bit hard to put yourself in the shoes of someone just starting out and maybe not at your particular level of genius.

What's easy for me may not be easy for you and vice versa, and hacking emacs as a start - at least to me - seems to be a bit much.

Plenty of people have trouble getting slime working, let alone hacking around on the guts of emacs without an experienced hand around to guide you.

If you say, "it's too hard", it will be. (You don't have to be productive on day one. But some day, you should at least take a look.)

Plenty of people have trouble getting slime working, let alone hacking around on the guts of emacs without an experienced hand around to guide you.

If they read the source code, the magic would become understandable. The problem that people have with things like SLIME or monads or pointers or classes is that they build a mental model that's a lot more complex than the real thing. Take a look at the real thing, and your mental model becomes simpler and more in line with reality.

It's funny you mention Excel. Without actually meaning to, that's where I started programming.

I ended up building all of my reports using MVC, before I even knew what a design pattern was.

I know several people that started their programming career in excel spreadsheets, it's actually quite scary how far they got with their stuff before they ran in to the limits of excel. The natural follow up to that was visual basic and then more and more 'mature' environments.

One of them got so successful with his VB program formerly spreadsheet that he ended up making a very impressive fortune with it.

One of my earliest jobs involved Lotus macros. When I got to port them to VBA-Excel it was a joyful thing.

Haha - yea me too. I've actually wanted a gEdit plug-in to text highlight for huge cells. I actually love programming in Scheme because the parenthesis are so like Excel's sort-of functional style.

Excel is the world's most popular functional programming language. To bad it's only of zeroth order.

>I'd start with something considerably lighter than that, but I do agree that reading code is a really important part of really learning how to program (well).

I am interested in well written code that falls into the light to read category. Can you provide examples?

DHH is saying "do" rather than "try".

You can memorize every line of the emacs code base, but unless you have a problem with emacs itself that you'd like to solve, it isn't going to get you far.

On the other hand, if you can't find a web-app to manage projects that works for you, and you decide to code one, you will learn much, much more.

I disagree. I would say I've learned about 40% of what I know about programming by typing stuff in and seeing if I like it. The other 60% I've learned by reading other people's code and stealing the techniques I like.

For example, I learned C by myself when I was in middle school. The memory management technique I developed independently was "the library allocates, the application frees". No errors in valgrind, and my app works.

Then I started reading other people's C code, and switched my technique to "the application allocates, the application frees". Now C is a lot easier to write!

Assuming that you're the smartest person on Earth only gets you to a local maximum. To get to the global maximum, you have to interact with other people.

The way you interact with programmers is with source code.

I think you've possibly hit on a fundamental difference between learning styles that people have.

I've learned probably 95% of all my programming from doing.

I do take issue though with the idea that the learn by doing crowd is somehow less accomplished. It smacks of baseless elitism.

Isn't thinking that others have little to offer to you a form of elitism as well? It seems neither option is particularly humble.

It's not that others have little to offer, it's a different style of learning. Just like some people are visual or auditory learners, some are kinesthetic learners.

Seeing other people's code does little for me because I miss all of the reasoning that went into it's creation. However, when I've fought through the same problem myself, I understand very thoroughly the traps, pitfalls, and solutions the task entails. When I reach this level, I can read other people's code and clearly see why they did what they did, and how it's better or worse than my method. I have to take a crack at the problem myself first, though, in order to learn well.

Reading other people's code is, for me, a way to refine and reinforce my techniques, not to learn entirely new things. I learn much less effectively when I try that.

I read a lot of books, but tend to forget most of them as well.

Learning to program well is a complicated bootstrapping process. You can't start out writing full-fledged, high quality apps (because you won't have the skills), nor can you start out by reading production code (because most of it'll just go over your head).

Just curious, how much bigger did it make your e-penis to type out programmers in quotation marks?

At the end of the day, it takes all types to make software. Those who build the boxes, those who peer into the depths and improve or maintain the boxes, and those who use the boxes all work together to make great software.

Speaking as a non-programmer, this is spot-on, for me. I've tried to go through various tutorials and start learning to code over the past few years (all the while wishing I'd gotten a CS degree rather than finance), but could never force myself to get through a whole book and really start to understand what's going on. Recently, though, there's been a need within my business for a small, (theoretically) simple application to handle part of our workflow. I finally have a concrete end goal in mind, and have been flying through a PHP book (Head First PHP and MySQL, which I quite like so far), because I actually want to learn enough as quickly as I can to put together a working version of this application. Granted, I'm still following the tutorials in the book and going through the admittedly hokey examples, but now I can see how each of the different elements I'm learning will actually help me build something useful. It's a whole different experience for me, learning to code when I actually know what I want to build.

> all the while wishing I'd gotten a CS degree rather than finance

That's interesting, the prevailing opinion here on HN seems to be that being in 'finance' is better then in CS.

Why is that different in your case?

I don't get that sense from posts.

But even if being in finance is better than being in CS, in places where performance is rewarded being in finance with a CS degree is better than being in finance with a finance degree.

Just one sample:

http://news.ycombinator.com/item?id=1613347

There are many more besides it.

>That's interesting, the prevailing opinion here on HN seems to be that being in 'finance' is better then in CS.

I strongly disagree, as to HN's "conventional opinion". I think most participants and probably most lurkers, would say that finance is probably, on average, a more lucrative field, but a CS degree from a no-name university would probably be better for getting into finance, the field, than an equivalent finance degree. This assumes you're working for someone else.

A finance degree is less useful for a technology/coding business/startup than a CS one. This is the raison d'etre of the forum. I would also contend that for getting FY$, personally financially independent rich, a startup is probably at minimum equivalent to working in finance. As such, neither is a bad choice, but the CS degree has better options.

I work in finance and have an undergrad CS degree.

It's common for folks in finance to have undergrad technical degrees (e.g., physics, math, CS) and graduate degrees in something more closely related to finance such as an MBA or MS in quantitative finance. (Although the pure quants will usually have a PhD in math or physics.)

But frankly if you're a technical person IMO finance is a ghetto: once you're in, it's hard to get out. In no other industry can you make as much money to do work that generally speaking is substantially behind the curve technically (e.g., pre-STL C++ is the standard development language and mindset, and most of the time you're just moving stuff to and from CSV files and databases). But if you're disciplined with your spending it's a great way to save seed capital if one day you want to jump ship and try a startup.

RFI: What do people think of quant finance Bachelors and Masters? Obviously it depends on the programme and school, but what do Ph.D. mathematician or pfysicist quants think of them, and otoh, what do traders and such think of them?

I don't get the sense from HN that being a finance major in school, especially as an undergraduate, would be better than CS. As someone who is doing both finance and CS courses as an undergrad currently, the jobs for finance majors all end up being analyst positions. A CS degrees gives you much more, better options if you're good at it, and allow more flexibility if you want to go out on your own. Finance is only glorious if you're one of the handful of people who get a potentially soul-crushing i-banking job as an Excel drone with opportunity to move up or do an Ivy MBA.

It's not from the glory point of view, not even from the interesting work angle but simply from a money making perspective.

It's different in my case because the traditional finance career bath does not appeal to me. I went to a large state school in a (relatively) small city, got married, and stayed here, which doesn't bode well for a career in finance. I got a job at a small regional bank in commercial lending, right when the credit crisis was hitting its stride. Stayed there for about 6 months, then left to start a company with my wife. My finance education has come in handy running the business, but I feel like I would have also benefited from some CS education as well. A half CS/half finance program may have been a good fit for me (not that something like that exists where I went to school).

I hope that makes some sense. Obviously it's hard to say where I'd be if I had gotten a degree in CS (or if I'd have made it out alive!); hindsight is of course 20/20.

That makes perfect sense, thank you!

You bet. It's very much an individual thing, but I also think that with a CS background, you're more likely to be able to create a "sky's the limit" situation for yourself financially. More potential for knocking something completely out of the park, if that makes sense. Of course, the very best people in finance will also be able to write their own ticket. I think the real focus should be on what makes the most sense for an individual given their personality, learning styles, and situation.

It seems many simply wish they had gotten a different degree in general. It may just be a "grass is greener" scenario. Or like somebody who learns a lot of math knows: when you finally understand something and look back it seems trivial. Following that, worth less than some not understood problem.

You need smallish goals and little projects that you actually care about. Start with javascript for some UI effect for your blog, for example. Starting with a whole PHP/MySQL site may be too much at once. And let's face it: the first few sites you create are going to barely work. I am a database expert but it took me a really long time before I understood SQL well enough to be comfortable with it, and a really long time after that before my skills could gel enough to really take off quickly. But along the way I had a continuous need to use databases.

After time your smallish projects get increasing ambitious. Javascript can't do something you need, move up to PHP. I "learned" languages by reading books or even taking classes but I have long since forgotten everything that I never actually had a need to use in the real world. I "learned" C but I remember things from javascript that I learned 12 years ago because I've actively used javascript on and off since then.

You need a CS degree to answer some programmer interview questions and as a quality indicator for kids right out of school, but plenty of really solid developers started learning by taking up smallish web dev tasks that became increasingly and increasingly ambitious over time. To get really good it takes years and years of doing this though.

Disaster can also be a great teacher: Long ago, I started work at Oracle with 2 cohorts. We were asked to install the product locally as a sandbox to work in and learn. The install went flawlessly for my 2 buddies. My install was a disaster, and it was the best possible thing that could have happened. I learned more over the next 2 days of frantic troubleshooting than most learned over the course of 6 months. My cohorts laughed at the time, but they never caught up.

Two things come to mind for me.

Flash 6 was how I learned programming. I realized I could create visual patterns and animations through code that I could never do by hand. The visuals were my goal, coding was what I had to learn on the way.

Copying and stealing is the best way to learn for me. Whatever I need to do, somebody has done something similar. So before I start, I find a code example or tutorial. First thing is to get it to run, then I make small changes until it does what I need it to.

This second approach works great for other things than coding, too. Taking apart and imitating successful designs, for example, is a great learning experience.

What made it click for me was programming in anger. Programming because I needed to. Programming because I gave a damn about what I was writing and I wanted it done sooner rather than later.

What made it click for me was programming in fear. Programming because I needed to. Programming because I gave a damn about my customer being satisfied and I wanted to get paid sooner rather than later.

I don't understand anyone who doesn't learn because they're curious. Because it's fun. Because they enjoy it. Intellectual curiosity.

It must be very odd programming 'professionally', only as a job and not as something you love first and foremost.

The problem with learning anything IMHO is when you don't enjoy it enough to want to learn it. And maybe that's a good signal that you shouldn't. Things are so much easier when you love what you do.

Yep. Same here. I waited tables and coded on my break for fun. Didn't even think it could be a career, since I was self-taught.

Learning to program is pretty darn fun. Learning brand new paradigms is pretty awesome. Building things in new, better, easier ways as you get knowledge and experience is wonderful.

Learning how to program in a language with a similar amount of power to one that you're already intimately familiar with is pretty darn frustrating. It's hard to be intellectually curious when you're just learning new rules for the same game.

It must be very odd programming in your spare time, not getting paid for something that is inherently laborious and valuable. There are too many other people, places, and things that I love first and foremost to list programming for free as one of them.

> " There are too many other people, places, and things that I love first and foremost to list programming for free as one of them."

This is something I think that is a great sign of someone who you should/shouldn't hire. The best interview question is "So what side projects are you working on out of hours?". If they shrug and answer 'none', politely show them the door, yet it's surprising just how many programmers don't seem to have/want side projects - I guess they're doing it for the money rather than the love of it.

Definitely, life's about balance - spending time with family, living, eating, sleeping, etc but it seems like real hackers genuinely enjoy hacking, and want to play - even out of hours.

...and now you're a discriminatory hirer.

Don't get me wrong. I love to build things. I love writing programs that improve my life in some way. I love that I can see a difficulty in someone else's life and tangibly improve it (for free if it's easy and you're a friend, or for a fair fee otherwise). Programming is fun.

What is not fun is the mental masturbation of keeping up-to-date on all the latest-and-greatest languages and frameworks. What is not fun is building something with no tangible benefit. What is not fun is being insulted and dismissed by people who expect everyone to have the same interests and motivations as themselves.

In your list of "balance", not once do you mention friends. I have a few groups of friends (totaling probably 30-40 people) in my city that I hang out with a couple times a month, some of them a couple times a week. I have more friends from my hometown that I visit once every month or two. I have other friends in other cities that I see a few times a year. If you subtracted all of that from my life, I would probably have an extra 50 hours per week to spend hacking. No deal.

Just because I don't like spending my leisure time hacking doesn't mean that I don't genuinely enjoy the time that I do spend hacking. It doesn't mean that I don't have grandiose plans for things that I want to build (and make money from!). Your attitude about what constitutes a balanced life and a good hacker is very shortsighted and frankly offensive.

I have several friends who are musicians. A couple of them make up one of my favorite bands, having a really cool and unique sound. In my time hanging out with them, we watch movies, grab something to eat, lounge around, party, and generally enjoy each other. We don't spend much time at all playing music just for fun. When they are "doing music", they are either writing a new song, improving an old song, recording, performing, practicing something new and useful, or rehearsing for an upcoming gig. All of their musical work leads to money in some form. Why do we expect hackers to work for free in their leisure time?

> "...and now you're a discriminatory hirer."

Damn right. I hire based on who will be good at the job.

> "What is not fun is the mental masturbation of keeping up-to-date on all the latest-and-greatest languages and frameworks. What is not fun is building something with no tangible benefit. What is not fun is being insulted and dismissed by people who expect everyone to have the same interests and motivations as themselves."

Couldn't agree more.

> " Your attitude about what constitutes a balanced life and a good hacker is very shortsighted and frankly offensive."

Sorry, but you're kinda proving my point. The fact you don't want to spend more time on hacking rather than spending time with friends, means you'd make a bad employee for a startup.

> "Why do we expect hackers to work for free in their leisure time?"

I didn't say that at all. And FWIW, I play in a band as well. But I also spend an hour or so a day just playing for fun - because I enjoy it.

> Sorry, but you're kinda proving my point. The fact you don't want to spend more time on hacking rather than spending time with friends, means you'd make a bad employee for a startup.

When did we start talking about startups?

I only know about hackers and startups. I have absolutely no idea how drone programmers behave/get motivation/work.

So yes, my original comment is talking about hackers. Not "Systems Analysis Architect"s or whatever.

> I have absolutely no idea how drone programmers behave/get motivation/work.

Very nice resorting to name-calling. Because you can't conceive of someone who likes and is good at programming, but who enjoys other things in his leisure time, you again try to dismiss him with a low-ball insult. Nice work.

I don't know who you are, but you'd do yourself a lot of good to try to understand others better instead of insulting them and writing them off for being different.

I can't begin to try to understand someone who works in a cube filling out TPS reports however much I try.

Anyway.... I think you'd do well to lighten up and not take everything as a personal insult.

My original point: It's better to hire people who love what they do, rather than do it just for the money.

"I only know about hackers and startups. I have absolutely no idea how drone programmers behave/get motivation/work"

That is the most absurd false dichotomy I have read this year. You sound like the "artistes" I know who think that anyone who isn't raging against the machine is a pawn of The System.

You could say the same thing about music, architecture, wood-working, painting, cooking, writing, etc. In general, people who have a heart-felt passion for the art are likelier to be better at it than others.

If all of the software in the world that was created out of passion and love for the craft suddenly disappeared overnight the world would be a much worse place.

> If all of the software in the world that was created out of passion and love for the craft suddenly disappeared overnight the world would be a much worse place.

That is a problem in my opinion. If someone is creating that much value, that person should be getting appropriately compensated.

> If all of the software in the world that was created out of passion and love for the craft suddenly disappeared overnight the world would be a much worse place.

It would also be pretty bad if we suddenly lost all the software that was created primarily for money.

Conversely, I have a tough time understanding anyone that spends inordinate amounts of time tinkering away on nothing, just because.

You can "love" to program but that doesn't mean you want to do it all day long. The love can come from the act of solving a problem, not the act of admiring how elegant the code works.

You need to disassociate the enjoyment from the purpose; they are not linked.

Suppose I rephrase this, with a twist:

"You can 'love' to paint but that doesn't mean you want to do it all day long. The love can come from the act of solving a problem, not the act of admiring how elegant the results are."

Many people are drawn to hacking as others are drawn to painting or playing music (and these groups often overlap).

Many people do in fact love music or painting though specifically because of the admiration others give them for it.

You're getting awfully close to a "no true Scotsman" fallacy. I know I'm not going to evaluate whether the guy who paints for himself or the guy who paints for a spot on the museum wall has a higher degree of "pure" love for an action.

It's irrelevant, really.

"I know I'm not going to evaluate whether the guy who paints for himself or the guy who paints for a spot on the museum wall has a higher degree of "pure" love for an action."

Right. There are no Scotsmen here, true or otherwise. My point is that some people do assorted things for the sake of doing them, for some intrinsic reason, not to solve some specific problem or address some external need.

Few people seem surprised when this is what motivates people to paint or play music, but when people say they feel that way about writing software, eyebrows go up.

Programming is like making windup toys, or kinetic sculpture, or children. Once you're done, they come alive and entertain you! Unlike most art for instance, that just sits there.

This doesn't just apply to programming. You need to have a concrete goal when learning anything. That's what'll motivate you to actually spend the time learning.

That's how I learnt to speak French. It wasn't because I wanted to speak French, it was because I needed to. And you can only learn something by doing it. That applies to coding and speaking a foreign language.

As DHH said, that's not true for everybody. Some people are really just curious, and aren't afraid to "waste" the time it takes to play around with it. I'm exactly like you though.

From 2000-2004 I was kind of a dabbler in the web dev world. Built crappy sites for many clients that really didn't go anywhere, and so I concentrated on doing things as cheaply and as fast as possible. Then the whole Digg thing happened. I learned about scaling "in anger." And keeping up with programmers that were smarter than me at the task at hand. I probably learned more in 2 years than I had in the 20 years before that. Now I find myself dealing regularly with programmers that didn't go through that experience (and managers who embrace that "cheap and fast" ethic). I try to control my disdain.

I've just left a workshop at our CS department, where we discussed new and old issues with teaching programming. Tutorials and assignment, based on completely made up cases and requirements, are still very much at the core of introductory programming courses. This is in sharp contrast to what DHH says in the post, as well as comments here and elsewhere.

May I be slightly selfish, and ask a question to all of you who have a CS degree? Did you learn programming as part of your CS education? Regardless, what's you opinion about the way programming was taught?

The best CS classes I had drove a single project through a semester, with the lessons applying to the next development tasks you needed to undertake. By the end of the course, you had a reference project that you could carry forward, and even continue to work on if you wanted to.

I studied CS at the University of Toronto in the early 90's and in hindsight I'm amazed that we never formally taught how to program. (The one exception I can recall is a "theory of languages" course that gave us a brief exposure to half a dozen languages, but it was an optional course and wasn't part of the core curriculum.) We were basically given assignments by the profs and it was assumed that we would pick up programming in the tutorials with a little help from the TAs!

Personally I had the benefit of having done a fair bit of programming in high school and on my own (Amiga AMOS FTW!) so I survived but I know it was very difficult for students who hadn't had any programming experience prior to university, and the drop-out rate from the CS program was very high (> 50% IIRC).

That's very interesting! With that hindsight, can you identify any quick wins that could have lowered the drop-out rate, or helped your personal understanding of programming?

I think the key is to lower the barriers to creating minimal, working, useful, hopefully interesting programs as much as possible.

E.g., start with a minimal implementation of the Unix 'wc' command in Python, walk through it explaining how it works, and then assign as homework adding the '-l' line counting option. As a professional it's trivial, but if you know nothing about a programming it can be very difficult to get started doing anything. It's too easy for us professionals to forget how much we know now.

Focus more on the performance characteristics and design trade-offs of core algorithms and data structures (e.g., binary search, quicksort, dictionaries, vectors, lists) and less on the nitty gritty of implementing them.

Starting with interactive languages like Python that handle garbage collection and have high-level containers built in is also useful. Noisy stack traces when something goes wrong are also much more accessible than a C or C++ core dump.

Another thing that irked me was the expectation that we were already emacs or vi experts! For beginning programmers, Notepad or Gedit is perfectly adequate.

By the time I started taking classes, I'd already been programming for fun for a while. I continued self-teaching; it was both necessary and entertaining. In class, I was taught the basics of Java, LOGO, MIPS assembly, C++, Scheme, and Prolog, and course material also used BASIC (which my father had taught me), C, and x86 assembly (which I taught myself). The earliest classes spent a lot of time teaching the language, whereas later classes assumed that students either had prior knowledge of it or would learn it on their own (except for Scheme and Prolog since these were expected to be students' first exposure to functional and logical programming). I think the expectation of some self-teaching is really necessary to ensure that students learn to do so before they graduate. Putting together simple building blocks given on lecture slides only takes one so far; eventually, you'll have to do something you didn't learn to do in class.

    May I be slightly selfish, and ask a question to all of
    you who have a CS degree? Did you learn programming as 
    part of your CS education? Regardless, what's you opinion 
    about the way programming was taught?

I learned about programming (aside from some casual observations) as a freshman EE student. After my first year I decided that the heavy math and physics requirements of EE would kick my ass, and that I much preferred the opinionated reality offered by writing software. So I changed my major to CS.

Programming per se was poorly taught. There was little emphasis on long-term code management, and only moderate emphasis on writing clean modular code. So I learned better coding practices from more skilled developers while school taught me language syntax and concepts.

All through college I was fascinated by cellular automata and artificial life, so every time I had a new language class I went off to write CA code, trying to make them run faster, cleaner, and provide nicer options. Pscal, Fortran, C; never got around to doing CA in COBOL though; dropped out of that class. :)

I was a self-taught programmer (with a little parental help) long before I took a programming course in school; I started when I was about 9 years old.

I breezed through the college freshman-level programming courses (and pretty much all of the later CS courses too) because I already knew most of what was being taught. My friends (most of whom had minimal previous programming experience) were much worse off; I don't think I would have done even as well as they did if I were starting from scratch as I entered college. I had a 9-year head start on them, although I learned at my own pace and on a self-directed, meandering path without any structured classes or tutorials.

Most of those friends graduated with a CS degree while still not fully grasping concepts like how malloc() works (this particular example comes from one of my friends who invariably showed up at my door looking for debugging help near the deadline of every C project, complaining that malloc was breaking his program). I feel like I probably missed out on some useful tidbits because I mostly tuned out the CS classes, since I felt like I "knew it all" already (obviously not true, but close enough that I could do well on the finals), but I am certain I knew more about practical programming than most of my friends who studiously applied themselves in those same CS courses.

If I hadn't had previous experience programming, I doubt I could have become an effective programmer in just four years of academic instruction (I certainly didn't fare so well in my non-CS courses in which I had no previous experience). Observing my friends, I could tell they were having a rough time with the way programming was taught, but I don't know whether that is a solvable problem within the time constraints.

I doubt my approach to learning programming was the most effective possible, but I think it's worked reasonably well. I learned to program because it was fun, not because I wanted to make anything useful, and I enrolled in CS because it looked like a way to continue that fun. In the end, I was disappointed by the (lack of) depth in the CS courses I took and the amount they rehashed things I already knew, but I suppose it's not feasible to tailor undergraduate courses to people who are already programmers. Perhaps with the growing accessibility and popularity of programming, there is a place for "CS for programmers" that would skip the introductory content and get into the real meat earlier than the third or fourth year. Certainly the courses I took met neither the needs of myself (too basic) nor my non-programmer friends (too advanced too quickly).

"Programming in anger" is a very odd way to put it. I think it's best to say "programming because you need it".

let me add a little something

programming is about languages and tools, whatever is your anger or need, some are more approachable than others

my dark beast for 10 years have been C and by extension C++, got this kind of stupid idea that to be a "real" developer you have to know how to program in C

and true for 10 years I tried to learn C/C++, just learning it for fun or curiosity, and for 10 years it went nowhere, could not wrap my head around it

I was just giving up after a couple of weekends, losing interest, and that was to blame on the fact I was just trying to learn it for the sake of knowing it, I didn't really needed it

and then on a somewhat big open source C++ project I found a little bug (really a shit of bug that can be fixed in 2sec), I could compile the project but not really write C/C++, but still could fix that bug

that's what I would call "anger", knowing that this stupid little bug can be fixed in no-time by someone like me (being a total noob)

but from this "anger" came a very unexpected thing

on my day to day work, wether it's ActionScript, Java, PHP, Python, etc. I can code it in my sleep, sure there are still some bugs and complexities, but still nothing that I can consider impossible

because trying to add features to that big C++ code base, was something very hard to do for me and to some extend "impossible" or "how the hell I gonna do that", it ended up being extremely rewarding and a kind of an obsession

so my little contribution would be to add: it's not only about the anger and the need, it is also about how hard it is for you to do it

yep, hard is fun

the harder the better ;)

Exactly. You can't program by "ok, let's learn the syntax, now let's move onto strings, now objects..." you need a project, and then it's 100x easier to learn what you need to know. You'll never know everything, but that wouldn't have happened if you went the other way anyways.

Even after a year of iOS programming, I still consider myself a beginner, and I probably always will be. There's nothing wrong with that. :)

I guess I took that for granted. I never read things expecting it to teach me to program. I read things to figure out how to do what I currently wanted to do.

Now, I read things to see what new ideas and libraries are out there... But it when it comes time to learn them, I use them.

My first, my very first C++ project, started in Year 9 - coming from VB6 - was a 3D graphics engine. Yeah, that failed. It failed 5 times (fun fact - the fourth rewrite occurred moments after exclaiming "oh those are references!"). But the 6th one was pretty neat! I'd written a file-loader for 3D Studio Max, an event system, input, etc. The seventh rewrite would have gotten rid of the hardware T&L and used shaders instead. I was in Year 12 by then. Then I went to uni, studying CS, and afterwards got a job at a video games company, implementing a 3D graphics engine.

Honestly, sometimes you just have to do it, even without any training. Maybe do it six times.

I feel the same way. Though I wouldn't call it angry. I really wish I could learn out of intellectual curiosity (I'm trying to do so with Haskell at the moment) but I can't help feeling like it's a waste of time. I'd rather do something useful. Or at least interesting, as an end. I love reading about new languages, I just can't seem to take enough interest to learn them. I'm going to try to do my next non-critical project in Haskell, see if that works.

Intellectually curious for the sake of it. I envy you.

Is this really that rare? I think I've always been that way.

Powerpoint was how I got into programming. I tried to make an adventure game out of powerpoint slides and hyperlinks, see, but when I hit the limit of powerpoint "programming" I started on BASIC, which worked much better.

Learning to program is a function of interest, need and willpower.

It is fun to dabble and be curious, but curiosity will not get you through some of the minutia that it takes to build a real app, and thats when need and willpower get you through to learning.

One breakthrough for me was realizing that programming is now a social activity. You have to meld with the hivemind to really get anything done, and while its good to have a mental framework of whats under the hood (I recommend the book 'code' by charles petzold for those without formal engineering training) it's more important to realize how to model all the abstractions that are part of modern software.

As paradoxial as it sounds, understanding abstractions is often works out to be alot like 'code monkeying' than theoretical computer science.

He might want to adjust the grammer of the title so that it is past-tense

Or he could leave it and I am sure a screenshot of it will pop during a flame war about rails :) (or somebody will respond 'Try PHP, David')

Well, sound a lot like Peter Norvigs "Teach Yourself Programming in Ten Years". Enjoy: http://www.norvig.com/21-days.html

That is exactly what I tell everyone who asks me that question!

Why is this post receiving so much attention, just because DHH wrote it? It has basically no content and is extremely fluffy. I find the 37signals blog in general is often like this.

Sometimes I wish HN stories could be downvoted.

Good question - HN doesn't usually go all weak at the knees for 3 paragraphs.

I learned to program to solve problems or create things. I don't enjoy learning a new language for its own sake; I might invest some time doing proactive learning because it will help me solve problems down the road, but that's it.

I think this is generally true of anything not involving mortal danger. If you want to learn how to do something, just do it. You will always fail at first, but you will learn.

Reply on news.ycombinator.com