The real issue is not learning to code, it is learning to problem solve. That is the part that is hard.
I recently overheard a guy on the train talk about why he dropped CompSci as a major to his friend. He talked about the times where he would leave out a semicolon and the program would crash. And it would take hours for him to find the culprit. Leaving out the efficiency of his debugging, what I listened to more was the tone of his explanation. It was like a diatribe. His attitude was literally that any career where you have to worry about little things like semicolons was not the type of career for him. I suspect he had gone into the CompSci program because of the material benefits. And left once he discovered the devil is in the details. Programming is like weaving more than writing. I remember that he said he had switched majors to Business and loved it. Basically, he said CompSci was torture. Because he did not revel, like many of us do, in the sometimes long and backtracking path that we go through to write code. To make something, to weave lines of code into something tangible.
I don' think that example proves your point: perhaps he loved problem solving / was an excellent problem solver and pursued CompSci for that reason, only to drop it because he disliked the formalism required by programming (or math, for example).
While coding is a formal style of problem solving, I think the sentiment that those who can't code can't problem solve / dislike problem solving is ill-founded and misguided.
I use this exact approach and have also banged out not-entirely horrible code in >=1 month. I did this when I learned Rails.
I started with a couple basic 15 minute guides and then hammered myself from all directions incrementally switching between stuff like Hartl's guide, PeepCode, Railscast, etc.
I do find that learning from diverse sources really accelerates the learning process for me. It also breaks up the monotony of pounding through exercises in a single book.
This looks like a good way to learn about coding in a month - a very important skill when you want to work with developers. But I'm doubtful it would provide any real proficiency ...
Anyone who's learned to code in a month able to say otherwise?
I don't think this question has an answer, because there is no way to precisely define "knowing how to code." Here are several reasonable definitions:
1 You know how to code if you can get a simple application to run. (No requirements as to maintainability, performance, security, etc.)
2. You know how to code if you can pick the right tools for the job, foresee and avoid future maintenance problems, avoid introducing well-known security holes, and achieve an appropriate balance between performance, cost, and programming effort.
3. You know how to code if you understand your specialty inside and out, to the point where you could write a book, teach advanced classes, testify as an expert in court, and maintain a leading blog about your specialty.
#1 can probably be attained in a month. #2 will take most people several years of sustained effort. Many programmers don't reach #3, and those who do have usually been in the game for many years and have held multiple programming jobs.
So what does it mean to learn to code? What's a good enough level of expertise to code for you own business?
Personally I consider anyone who can be given a reasonably difficult[1] problem and solve it on their own[2] as knowing how to code.
[1] reasonably difficult - something that can't be solved by finding an appropriate tutorial (in a sense, the solution has to create new knowledge in your sphere of influence)
[2] solving on one's own - not solving through code archaelogy by frankensteining a solution together from random code snippets found online and/or nontrivially stitching together othe people's API's and libraries
It takes very little coding knowledge to be able to provide massive value.
I learned to program SAS and get a job in about 2 weeks. I had a very strong Math background, but next to no programming background.
6 months later, I'd automated my job, my department's jobs, and another department's jobs.
You can argue that this doesn't count as real coding-SAS is certainly much easier than Ruby. But the point is that it was quite possible to learn enough to provide millions of dollars of business value in a couple of weeks.
Nope-the company was surprisingly good at reassigning people to areas that actually did need work. Except for me-it took them so long to reassign me that I got bored due to a lack of work and left.
|What's a good enough level of expertise to code for you own business?
I think it's very much depends on your goals and tools.
For example, you can probably design a useful business application in Mircosoft's lightswitch in a short time .And it would probably be reasonably secure ,maintainable etc. , because of MS's help.
Same can be said for using python + numpy as a front end for a lab equipment , used in your business.
I agree on the general notion is coding involves a lot more than meets the eye. Given that, it's probably impossible to claim that coding is learnable in anything less than years of work. Even then, we all know that we learned, one way or another, by doing. This course is design to get people writing actual code and accelerating what can be a slow learning experience. I have no doubt that those students will be coding in a month.
Just like learning to ride a bike doesn't mean BMX competitions, it's still a step that could lead people to anything they want to make of it. I'd expect plenty of options for next steps, including learning to do ticks on a BMX style bike. The key is that not all of these next steps are serious endeavors. Some people learn just be be enlightened.
I do hope it inspires students to take steps to learn more. We'll see how it goes and we'll also see what students think after taking the course.
I banged out a YouTube clone with user registration and voting for an intranet in less than a month after knowing nothing about Rails using the exact methods the author is talking about.
Sure it was no showcase example of Rails development but it works and people love it (it's been a few year now and to be honest, I've only made minor changes since).
Edit: I did have years of programming experience beforehand, but not in a language like Ruby or a framework like Rails. It was at times, mind-bending. I think the key difficulty was combating presumptions.
Okay, learning Rails with years of programming experience under your belt is in no way comparable to learning how to program (hate "code" as a verb) from scratch. Even if all you ever did was write device drivers in MIPS assembly, you're at a huge advantage over someone who has to wrap their head around what the heck a while loop or an assignment statement is.
Don't forget to take notes in the form of a cheat sheet (or find a cheat sheet someone has already made). It's so easy to remember what was done in a tutorial without remembering how it was done in terms of keywords, etc.
You what I'd like to see more than "learn to code" sites/posts, is "learn to design" ones. I know there have been a couple but I think more of us here know how to code than do design well.
I'm gonna try this. Coding to me is mystifying even though I started in grade school. Later I met a hardware engineer/hacker when I was 18 and I decided then to focus on the business side even though I had made a few applications. He was so good at the math and the art of it that I never wanted to waste time to learn it properly. But I was lazy with it before all that. So I should challenge myself to this.
The two best things that let me learn Django (and some more-than-basic Python) were The Django Book and IRC.
IRC is a really, really, really good resource to learn something technical, and it is better in that it provides real-time help. It is the closest you can probably get to having someone guide you live short of having a friend to help you.
A hypothetical doctor might say, "You can teach yourself to be a programmer in one month, that I can understand, but a doctor in one month? Impossible."
I recently overheard a guy on the train talk about why he dropped CompSci as a major to his friend. He talked about the times where he would leave out a semicolon and the program would crash. And it would take hours for him to find the culprit. Leaving out the efficiency of his debugging, what I listened to more was the tone of his explanation. It was like a diatribe. His attitude was literally that any career where you have to worry about little things like semicolons was not the type of career for him. I suspect he had gone into the CompSci program because of the material benefits. And left once he discovered the devil is in the details. Programming is like weaving more than writing. I remember that he said he had switched majors to Business and loved it. Basically, he said CompSci was torture. Because he did not revel, like many of us do, in the sometimes long and backtracking path that we go through to write code. To make something, to weave lines of code into something tangible.