I had no intention of writing about this meme because I'm biased by the fact that we're building a platform to allow programmers to teach programming, but then Jeff Atwood wrote his "Please don't learn to code" post. I'm sitting at home, grumpy because I'm ill, so this was all the excuse I needed to get this off my chest.
Frankly, I don't care if Mayor Bloomberg should learn to code, mostly because I don't live in New York. For me, what's important is the fact that he will never learn to code non-trivial programs by going about it in this manner. Much of the hype on the internet misleads people into assuming that by writing a code snippet a week, they're going to become programmers. That's like assuming if you solve a Sudoku problem once a week for a year, you will become a mathematician.
Learning programming is not easy. It's easier than many other disciplines because you can learn through experimentation, but to be a good programmer, you need to make the effort to understand how computers work.
The less you understand, the less effective you are as a programmer.
You see, any non-trivial software program depends on dozens or hundreds of abstractions. For the non-programmers reading this post, an abstraction basically hides a complex mechanism or concept behind a simple interface. A real-world example of an abstraction would be the remote control of a television - you don't need to know what goes on in the circuitry of the TV to switch channels; you know that hitting that button makes it happen, and all of the underlying complexity is "abstracted away" from you, the user. This is ok, because you are not in the business of designing and building TVs.
You can certainly write many trivial programs without looking under the hood, but for bigger pieces of software, some understanding of how all the abstractions in your system work is essential. Memory management, threading, storage and scheduling are just some of the areas one needs to be familiar with before you can understand why your program behaves in a certain way. Once you get into production software you need to understand networks, packets, routing - I could go on like this for five minutes. Without understanding all of this, the behaviour of your program is a black box to you. When something goes wrong - which it will - you will have no idea why it happened. And you will not be able to fix it.
Getting the basics sorted would easily take six to twelve months of serious study. Without this, you're just messing around doing building "Hello world" programs that provide gratification to you and little else.
Long story short, there's nothing stopping anyone from becoming a kick-ass programmer, but remember, programming isn't an exception to the 10,000 hour rule.
Frankly, I don't care if Mayor Bloomberg should learn to code, mostly because I don't live in New York. For me, what's important is the fact that he will never learn to code non-trivial programs by going about it in this manner. Much of the hype on the internet misleads people into assuming that by writing a code snippet a week, they're going to become programmers. That's like assuming if you solve a Sudoku problem once a week for a year, you will become a mathematician.
Learning programming is not easy. It's easier than many other disciplines because you can learn through experimentation, but to be a good programmer, you need to make the effort to understand how computers work.
The less you understand, the less effective you are as a programmer.
You see, any non-trivial software program depends on dozens or hundreds of abstractions. For the non-programmers reading this post, an abstraction basically hides a complex mechanism or concept behind a simple interface. A real-world example of an abstraction would be the remote control of a television - you don't need to know what goes on in the circuitry of the TV to switch channels; you know that hitting that button makes it happen, and all of the underlying complexity is "abstracted away" from you, the user. This is ok, because you are not in the business of designing and building TVs.
You can certainly write many trivial programs without looking under the hood, but for bigger pieces of software, some understanding of how all the abstractions in your system work is essential. Memory management, threading, storage and scheduling are just some of the areas one needs to be familiar with before you can understand why your program behaves in a certain way. Once you get into production software you need to understand networks, packets, routing - I could go on like this for five minutes. Without understanding all of this, the behaviour of your program is a black box to you. When something goes wrong - which it will - you will have no idea why it happened. And you will not be able to fix it.
Getting the basics sorted would easily take six to twelve months of serious study. Without this, you're just messing around doing building "Hello world" programs that provide gratification to you and little else.
Long story short, there's nothing stopping anyone from becoming a kick-ass programmer, but remember, programming isn't an exception to the 10,000 hour rule.
6 comments:
So, what you're saying is that Everyone (who is going to write code that someone else will use/read/change) should learn programming(?)
I'm saying that everyone that wants to program for a living should realise that it's a non-trivial exercise.
Agreed. After I read Atwood's post I was just thinking that a distinction needs to be drawn between computer-literacy, software-literacy and programming-literacy and scales thereof.
I find it funny how everyone talks about programming and coding. Programming and building software are two different things. To me the difference is like writing a sentence or a short story and writing a novel.
Resources like Rubymonk, Codecademy, Learn .* the hard way, etc seem to be great for helping people understand the foundations of programming and logic.
I was really interested in programming and would be able to complete the basic stuff when I was in high school. But only after three years of rigorous learning and working at a professional level, I've only been able to scratch the surface of one small sub-sect of software. There's just so much more to it than just writing the business logic.
Turns out the hard part is never programming. It's dealing with other people's programs. APIs, Best practices, security, Browsers, Scaling issues, dealing with bottlenecks, understanding common pitfalls - all can never be taught comprehensively by a book and have to be experienced first hand.
In fact, the main fear I have from resources like Rubymonk, etc is that it will cause people to believe that they can take on large challenges (especially with the fact that it's "hip" to do a startup) without understanding how big a challenge it is.
I personally know a significant number of people who say "I just learned learned programming through X and I'm going to build the next $EXISTING_SUCCESSFUL_PRODUCT"
I hope everyone makes their killer app, but I'm skeptical of any course that says "Learn web development/kernel hacking/etc in one week" there's a trial by fire and everyone has to go through with it.
Good points, it is difficult to really get in and become an exceptional programmer.
Once you understand the basic logic of development, with the knowledge that there is a lot of work and studies up ahead, what steps come next?
Post a Comment