Programming is not a goal.
I did a Q&A a few days ago, and one of the questions was "How does one break the toy project / codecademy cycle?" ... I am not sure what that means, but I will take this as an opportunity to rant about something I care about that seems (to me) vaguely related.
You may be feeling like you are trapped in a cycle of just learning things, using them in a toy project and then... what? You learn something else? And do another toy project? And so on?
And you feel like that is totally meaningless and gives you no feeling of achievement, no motivation, and end up feeling like you are going to be a newbie forever?
Well, if that's the case ... listen to me.
Your toy projects feel meaningless because they are not real.
That feeling you have? It's just your inner programmer telling you to stop playing around and start proogramming for real. And I am here to tell you how to do that.
STEP 1: Find something you need your computer to do that it doesn't do
You want your Youtube videos to appear in your blog?
You want to be know how many people called Roberto were born in 1934 in Argentina?
Well, imaginary person, after you found something like that, you can move to step 2.
Let's say you have decided to implement a gadget that drives away the birds that wake you up every morning in this endless nightmare we currently live in.
STEP 2: Decide some basic details about your goal
This is what is called a project. Implementing sorting algorithms is not a project, that's an exercise. Implementing the 200th version of a chat using websockets for your "portfolio" is not a project, it's, I don't know, a boring addendum to your resumé or something.
A project is a goal. A project is "I want my computer to do THIS and in the holy name of Billy Wilder, I intend to spend the effort to make it do it!"
So: I want something that when it detects bird sounds, makes noise to drive them away.
- Listens for noises
- Decides whether they are bird noises
- Answers with a noise that is unpleasant to birds
STEP 3: Convince yourself that's a possible thing computers can do
Because, you know, computers can do a lot of things, but computers can't do everything. So, you need a quick reality check. Make it very quick, you don't want to spend more than, like, half an hour on it.
- Can computers listen for sounds? Yeah.
- Can computers make sounds? Yep.
- Can sounds drive away birds? Yes sir!
- Can a computer decide whether the noise it hears is a bird or not? Well, maybe? I have seen stranger things!
STEP 4: Come up with a semi-rational mechanism to implement it
This has to be very vague. Like "yeah, I can do that using this Google API and this piece of lint I found in my sofa". A vague idea.
- Implement something that listens for noise.
- Add something in the middle that decides if noise is bird-like
- Make noise detection trigger code
- Implement something that makes noise
STEP 5: Come up with the most stupid version of the goal you can imagine
So, you want to write a bird-detector? Try writing a noise-detector, first. Or rather, try to find something that can react when your microphone detects noise. Or even, find a library that gives you access to your microphone.
So:
- Find a library to read sound from microphone
- Detect noise
- Find library to make noise
- Make noise
- Connect both pieces
STEP 6: sit the fuck down and implement the stupid version
This should be done FAST. If you plan too much you are not going to do anything other than plan a lot. You want to become a programmer, not a PM. I wonder what the PM version of this rant would look like.
STEP 7: Show the stupid version to someone you respect, and listen
Yes, this part is scary, but programming is, in large part, about people. Showing things to people, listening to people, finding out what people really mean, and so on.
So: show it to someone. Listen. Make decisions about whether you were right in steps 3 and 4. Maybe adjust a little what yoour goal is.
STEP 8: repeat step 5 to 7 with a slightly less stupid version
Do this until you run into something you have no idea how to do. In this case that's probably going to be "decide if that's a bird's sound"
STEP 9: get help
Ask around. Again, programming is mostly about people. In this case, you will practice "getting help". You don't want someone to just tell you how (or maybe yes?) but this is the critical point.
You can run into a few scenarios.
- You figure it out.
- You figure out that it can't be done.
- You find out that it's doable but you just have no idea how.
If you figure it out, then there is no problem! Go back to step 5 and continue until you are happy with the project, and you have learned something new! Congratulations!
The other two outcomes lead to ...
STEP 10: get stuck
If you figured out that it can't be done, then you have learned about one type of problem that is currently intractable. Considering you are new to this sort of thing, that is probably not something you are going to solve, but ... if you really were interested in this project, it may point you to a whole kind of thing you want to learn about.
So, you can't decide if a given noise is a bird ... why? Is there research being done in that area? Would that involve machine learning? Hey, that sounds interesting. Usually the examples are about images... is there any interesting work being done about applying it to audio? Are there libraries? Are there datasets? Are there tutorials? Hmmm ... and now you know something you want to learn about. Have fun.
The third outcome is the complicated one. Let's say it can be done by creating a model with ML and a dataset of urban noises and a dataset of bird noises and both things exist, and it has been done, and you know about it (a little) but you have no idea how to do it.
Well, in that case ... congratulations, you have found the current limit of your competence. You just need to expand it. And that's what programming is like.
So, how does this whole convoluted process help you?
You are learning different things you won't learn doing exercises.
- You learn to decide what to do.
- You learn to ask for help.
- You learn to present your work to others.
- You learn to process feedback.
- You learn to research your problem space.
- You learn to break down tasks.
- You learn to make decisions.
And yes, you may learn a programming skill or two.
And, maybe (but it's unlikely) you will get rid of those pesky morning birds.
PS: https://github.com/karolpiczak/BADC-2017
If you are interested in a long comment thread about this, of which roughly 30% missed the point of this not being some sort of universal advice and therefore taking personal offense at it, and 50% is me responding to each and every comment, see reddit.