This seams like a pretty simple interpretation of genetic makeup. Wouldn’t a well-funded genetic mapping startup have done this same analysis?

I’m not going to talk about my job because I’m feeling overwhelmingly burnt-out and wanting.

Otherwise, I’m spending a lot of time training for my first 50M race this spring and 100M beyond that. I love running; it is the one place where I am unreachable and have time to think in depth. I don’t even have to really think, as subjects just seem to bubble up subconsciously.

Also, reading and writing about all sorts of things. Practice in writing really does make a difference and I need to do more.

Improving Rails and Ruby knowledge, including working on an app to cut-out the back and forth email when making e-introductions.

Personally, getting into Crossfit for most of 2012. Three fourths of the people are in better shape than me, but it’s about having fun and the benefits of staying active. Plus, I think more clearly when I stay active.

Day job working at Treehouse. On the side I’ve been working on open sourcing a CMS for podcasting and new features for my app, Scheduling (http://schedulingapp.com).

Curious why people down-voted this article. Because it wasn’t technically-focused? Because it referenced a lobste.rs competitor, HN? Other?

How do you think he decided on which languages to support first? In this case, it was JavaScript, Clojure, and python.

Programming Education. I got this.

I think the comment by @moses sums up the current theory about what people of the last 5 years think a good beginners' programming language is. I agree with probably none of them wholeheartedly, but I have indeed heard all of these notions over and over again. The only successful computer science curriculum for beginners I’ve seen scientifically measured is the one done by Harvey Mudd College where they present a combination of languages to exhibit theory first and practical application later. They also require all students to take the intro to CS course.

The post is biased toward people involved in the industry or aware of it in order to make decisions about learning a language that is immediately applicable. You don’t really need to do that to pick a beginning language, although you can certainly learn to code on-the-job, where such a choice is not up to you. Frankly, to properly learn how to program, it’s about intuition, and no one language is going to help you. If your goal is to be an expert programmer (is that a valid goal these days?), you’ll need fluency in at least 3 languages, so who cares which one is the first? You should not have to approach programming with the idea that you have to ‘know exactly what you want to do.’ People generally don’t have a project idea beforehand, although it would help.

If you are picking a language for somebody who has never programmed before and doesn’t know if they would like to, then the choice is critical. If they have a project goal, then some mentorship can choose the correct one, and then their learning is project based. You teach them arrays when they need arrays, etc. Mentors are rare, so how about self taught? They’ll fumble around, but eventually come to incorrect conclusions, and eventually somebody will correct them in some condescending manner, and they learn. If they do not have a goal, then essentially they need to follow programming as a study and learn from fundamentals onward.

So, about that classroom setting (or self-taught from a book/lecture videos/etc)? Well, the choice is no longer theirs, because they don’t know anything yet, so what is the best? If your goal as a teacher is to give the basic fundamentals, then you start with the machine itself, plus a little theory. Describe the bounds of what you can and cannot do. Describe what a Turning machine is. And then, after a few weeks, maybe you write some code. It doesn’t matter what the language is, because you’re at the point where you get to say ‘this is a written abstraction of that machine,’ because at the fundamental level, you must expose all magic by describing why such abstractions are necessary.

But, we need immediate feedback loops, they say. For some people that already know what they expect the computer to do, and know that it is not magic, this is good. Give them a REPL, and they can determine how best to complete a task. If they are not aware of the abstractions of a language, then you get to the point where such immediate interactions create the opportunity for somebody to simply try every combination they can think of and either 1) get the result they wanted, but do so accidentally, or 2) do not get the result and become frustrated that their idea of expressing something was not understood. You must demystify the idea that the language is not natural. That’s hard. The more expressive the language, the harder it is, dispelling the belief that this helps beginners as well.

We need a language that has a large community, they say. Well, that’s actually quite true. You see, in all of the time I’ve taught students and graded students and mentored students… there is one thing that is always true: the good ones cheat. They ask everybody around them to look at their code, to fix their code, to write their code for them. That’s against the rules where I taught, but whatever, it’s a good thing if they’re being interactive about it. And they usually will be because my written exams scare them.

What should we do as mentors, teachers, etc to promote people to learn to code?

1. Do our best to promote diversity and fight against sexism and racism and other discrimination in our tech communities especially in public spaces, but private spaces too.
2. Dispel any notion that it is difficult to learn and you aren’t supposed to learn everything.
3. Be modest about our abilities, because we’re all kinda terrible honestly, because we cannot learn everything. Especially be modest when teaching or mentoring.
4. Never discourage a question.
5. Always give a thorough answer. (I think I’m good at this one :P )
6. Promote knowledge of basic computational theory, because knowing the limits of what any programming language can do or any computer for that matter is something every programmer should know and respect. A programmer that doesn’t know basic computational theory is like a carpenter that doesn’t know that steel is harder than wood.

To end, the notion that people learn programming to ‘become good programmers’ is a silly notion. That may be true to begin with (“I want to be a pirate!” —Guybrush Threepwood) but if you continue learning to code, that original motivation must change. It must mutate into some goal that is worthwhile to the person. You might originally want to be ‘good at drawing,’ but in the end you want to ‘create a work of art.’ Because at the end of the day, nobody is a good programmer, and certainly nobody is great. The better you are, the more you realize how bad you are. We eventually taper off to become eventually good at whatever we need to be eventually good at doing. And then we create worlds one insignificant piece at a time.

Mental masturbation is fun and all, but when all is said and done, developing a culture of shipping is one of the most important things you can do.

I have to keep pushing myself to focus on results/building/shipping. I tend to get bogged down in theory of why is something a certain way and 20 minutes later I’ll find myself deeper into an issue than when I started, sometimes with less understanding than when I started.

The truth is, it doesn’t really matter what your first language is if your aspiration is to become a good programmer.

Learning to program well is something that transcends languages and platforms. Usually a community will focus on a specific aspect of solving the problems you typically solve with the language, and pretty much all of them have something to teach you. Even if they don’t, the language will.

I think that this makes sense under the assumption that learning a programming language is hard. But after you’ve learned your first programming language, you find that the next is orders of magnitude easier. Really, it’s just understanding the concepts that underly it that are hard. Really, for your first programming language, you want a good language for beginners that will teach you the concepts well, not necessarily the most powerful or expressive ones, or the ones that will still be relevant in the future, or is even relevant today.

I think that your first three points are on the mark, but the fourth is off.

1. It is important to use an expressive language that you can do real things in because it can help you to motivate yourself. However, Logo or Alice might be just as good at this, and depending upon your problem domain, something like perl might also work well. Rails is extremely expressive, but also magical. I don’t think learning Rails as a first language is that great an idea, because of how magical it is. I think Sinatra has a good balance of magic and power, although you do need to roll your own for a lot more things.

When it comes down to it, I would probably recommend python as a first programming language under this criterion, because it presents a “right” way of doing things, but is also extremely powerful and flexible. It is useful in many different problem domains, and has very good libraries. Ruby is also like this, but it is TMTOWTDI, which I think is not great in a first programming language.

1. Short feedback loop is very important. Use an interpreted language. It doesn’t really matter which one. Anything with a REPL. You can learn patience another time. Python, ruby, php, lisp, all have very short feedback loops.

2. Something with a big stackoverflow community. Python, ruby, php, java, c, etc. Easy to look up.

3. Future Relevance: learning a language isn’t a big investment after you already know one, so this is not important.

I used to think that it was important for a first language to be low level, so that you can appreciate what the computer is doing for you, but now I think it’s more important for it to be expressive, but not magical, so that you can understand the concepts, but don’t get discouraged by seeing too much of the metal.

I used to think that Ruby on Rails was a great tool for building your first web application. In 2008 it was what I used to get my first app off the ground. But either it has changed too much or I have changed to the point where I no longer believe Rails is the best educational tool.

Rails' magic can be useful, and it’s certainly “cute” in a lot of ways. But when you tell beginners that naming things a certain way or putting a file in a particular location will make their app “just work” without explaining what’s going on you do them a disservice. A perhaps unintended consequence of “convention over configuration” is that all programs start to look like configuration when you stick with all the conventions.

I’m glad to see @andrewkkirk documenting this process. For many of us the time spent learning to program is a distant memory, and I think another look at the process, even through someone else eyes, can be enlightening.

Interesting stuff. I’m new to Ruby and Rails and find videos helpful, so nice work.

First, the full screen is a bit too much to take in visually. I would zoom in more, as this could help with video quality issues. Second, I don’t the unscripted nature is bad. Yes, you can tell when you see a more finished, polished move (cuts, transitions) as seen on Treehouse, but that doesn’t appear to be what you’re going for. I think the quick, natural nature of your videos work fine.

One content suggestion, as noob I’m looking for content that’s one step above Rails 101. There are too many options when it comes to tutorials on building that first app with scaffold. I need the Rails 102 (or 201?) class. -How do I start with TDD and Test:Unit? -How do I build advanced associations/relationships between my models? -How do I create views that are not explicitly created by scaffold, but aren’t necessarily static?

Good luck!

Good stuff. I’m new and self-taught Rails developer. Always looking for articles from the same perspective.