I strongly disagree with the approaches usually recommended online, which involve some mixture of sites like CodeAcademy and looking into open source projects and lots of other hard-to-motivate things. Maybe my brain works differently, but those never appealed to me. I can’t do book learning and I can’t make myself up and dedicate to something I’m not drawn to already. If you’re similar, try this instead:
Pick a thing that you have no idea how to make.
Try to make it.
Now, when I say “try”… new programmers often envision just sitting down and writing, but when they try it they realize they have no idea how to do anything. Their mistake is that, actually, sitting down and knowing what to do is just not what coding is like. I always surprise people who are learning to code with this fact: when I’m writing code in any language other than my main ones (Java, mostly..), I google something approximately once every two minutes. I spend most of my time searching for how to do even the most basic things. When it’s time to actually make something work, it’s usually just a few minutes of coding after much more time spent learning.
You should try to make the “minimum viable product” of whatever you want to make first.
If it’s a game, get a screen showing—try to do it in less than an hour. Don’t get sidetracked by anything else; get the screen up. Then get a character moving with arrow keys. Don’t touch anything until you have a baseline you can iterate on, because every change you make should be immediately reflected in the product. Until you can see quick results from your hard work you’re not going to get sucked in.
If it’s a website or a product, get the server running in less than an hour. Pick a framework and a platform and go—don’t get caught on the details. Setting up websites is secretly easy (python -m SimpleHTTPServer !) but if you’ve never done it you won’t know that. If you need one set up a database right after. Get started quickly. It’s possible with almost every architecture if you just search for cheat sheets and quick-start guides and stuff. You can fix your mistakes later, or start again if something goes wrong.
If you do something tedious, automate it. I have a shell script that copies some Javascript libraries and Html/JS templates into a new Dropbox folder and starts a server running there so I can go from naming my project to having an iterable prototype with some common elements I always reuse in less than five minutes. That gets me off the ground much faster and in less than 50 lines of script.
If you like algorithms or math or whatever, sure, do Project Euler or join TopCoder—those are fun. The competition will inspire some people to be fantastic at coding, which is great. I never got sucked in for some reason, even though I’m really competitive.
If you use open source stuff, sure, take a look at that. I’m only motivated to fix things that I find lacking in tools that I use, which in practice has never lead to my contributing to open source. Rather I find myself making clones of closed software so I can add features to it..
Oh, and start using Git early on. It’s pretty great. Github is neat too and it basically acts as a resume if you go into programming, which is neat. But remember—setting it up is secretly easy, even if you have no idea what you’re doing. Somehow things you don’t understand are off-putting until you look back and realize how simple they were.
Hmm, that’s all that comes to mind for now. Hope it helps.
I second this whole post, but especially that part.
I would add one more bit: It helps a lot to have a friend who’s already a programmer. Not so you can say “teach me how to program”, but so you have someone to go to when you don’t know what words or phrases you need to Google.
IRC channels or newsgroups relevant to the language/library/application you’re using can substitute for that but aren’t quite as helpful.
I work in programming, and I agree with just about everything you said and I want to put my biggest, boldest circle of agreement around this. I don’t think I started getting into what seems like a more advanced style of programming knowledge until I received a large enough stack of tedium that I had to automate through.
The other key step was realizing something was tedious. If you’ve only worked on a few things related to a system, then everything seems novel, but if you do the same type of thing over and over again, you’ll frequently see a tedious pattern and then you can automate THAT tedium.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
“Oh, I could probably automate this with a script...you know, I should really optimize my vim setup for script-hacking...you know, I really need a way to keep track of my vim plugins...I could probably tweak these plugins to work better with what I’m used to...”
A lot of these time investments end up paying off (e.g. you really should use vundle to manage your vim plugins), but every now and then you should push through at least a bit of tedium to make sure you have a good idea of the problem, how much pain it’s causing you, the scope of similar-enough problems which are likely to have the same solution, and exactly what you need to do to solve it.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
It depends what you want to learn. If you want to learn programming then spending time on automating stuff is useful practice.
I strongly disagree with the approaches usually recommended online, which involve some mixture of sites like CodeAcademy and looking into open source projects and lots of other hard-to-motivate things. Maybe my brain works differently, but those never appealed to me. I can’t do book learning and I can’t make myself up and dedicate to something I’m not drawn to already. If you’re similar, try this instead:
Pick a thing that you have no idea how to make.
Try to make it.
Now, when I say “try”… new programmers often envision just sitting down and writing, but when they try it they realize they have no idea how to do anything. Their mistake is that, actually, sitting down and knowing what to do is just not what coding is like. I always surprise people who are learning to code with this fact: when I’m writing code in any language other than my main ones (Java, mostly..), I google something approximately once every two minutes. I spend most of my time searching for how to do even the most basic things. When it’s time to actually make something work, it’s usually just a few minutes of coding after much more time spent learning.
You should try to make the “minimum viable product” of whatever you want to make first.
If it’s a game, get a screen showing—try to do it in less than an hour. Don’t get sidetracked by anything else; get the screen up. Then get a character moving with arrow keys. Don’t touch anything until you have a baseline you can iterate on, because every change you make should be immediately reflected in the product. Until you can see quick results from your hard work you’re not going to get sucked in.
If it’s a website or a product, get the server running in less than an hour. Pick a framework and a platform and go—don’t get caught on the details. Setting up websites is secretly easy (python -m SimpleHTTPServer !) but if you’ve never done it you won’t know that. If you need one set up a database right after. Get started quickly. It’s possible with almost every architecture if you just search for cheat sheets and quick-start guides and stuff. You can fix your mistakes later, or start again if something goes wrong.
If you do something tedious, automate it. I have a shell script that copies some Javascript libraries and Html/JS templates into a new Dropbox folder and starts a server running there so I can go from naming my project to having an iterable prototype with some common elements I always reuse in less than five minutes. That gets me off the ground much faster and in less than 50 lines of script.
If you like algorithms or math or whatever, sure, do Project Euler or join TopCoder—those are fun. The competition will inspire some people to be fantastic at coding, which is great. I never got sucked in for some reason, even though I’m really competitive.
If you use open source stuff, sure, take a look at that. I’m only motivated to fix things that I find lacking in tools that I use, which in practice has never lead to my contributing to open source. Rather I find myself making clones of closed software so I can add features to it..
Oh, and start using Git early on. It’s pretty great. Github is neat too and it basically acts as a resume if you go into programming, which is neat. But remember—setting it up is secretly easy, even if you have no idea what you’re doing. Somehow things you don’t understand are off-putting until you look back and realize how simple they were.
Hmm, that’s all that comes to mind for now. Hope it helps.
I second this whole post, but especially that part.
I would add one more bit: It helps a lot to have a friend who’s already a programmer. Not so you can say “teach me how to program”, but so you have someone to go to when you don’t know what words or phrases you need to Google. IRC channels or newsgroups relevant to the language/library/application you’re using can substitute for that but aren’t quite as helpful.
I work in programming, and I agree with just about everything you said and I want to put my biggest, boldest circle of agreement around this. I don’t think I started getting into what seems like a more advanced style of programming knowledge until I received a large enough stack of tedium that I had to automate through.
The other key step was realizing something was tedious. If you’ve only worked on a few things related to a system, then everything seems novel, but if you do the same type of thing over and over again, you’ll frequently see a tedious pattern and then you can automate THAT tedium.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
“Oh, I could probably automate this with a script...you know, I should really optimize my vim setup for script-hacking...you know, I really need a way to keep track of my vim plugins...I could probably tweak these plugins to work better with what I’m used to...”
A lot of these time investments end up paying off (e.g. you really should use vundle to manage your vim plugins), but every now and then you should push through at least a bit of tedium to make sure you have a good idea of the problem, how much pain it’s causing you, the scope of similar-enough problems which are likely to have the same solution, and exactly what you need to do to solve it.
It depends what you want to learn. If you want to learn programming then spending time on automating stuff is useful practice.