4 ms·

Code is useless if it is for nothing. Don't write code just to write code, write code to solve a problem you are having. If you're having 1 problem per month, t

Code is useless if it is for nothing. Don't write code just to write code, write code to solve a problem you are having. If you're having 1 problem per month, then write 1 project per month. If you encounter 50 problems in one month write 50 projects in 1 month. If you encounter 0 problems in one month, write 0 projects that month.

ebbv 10y ago
> Don't write code just to write code, write code to solve a problem you are having. What if the problem I'm having is that I don't know Haskell? It's totally fine to code exercises that don't serve any useful purpose. Just like it's fine for me to make terrible songs on the guitar that nobody would ever want to hear.
- atonse 10y ago
  My take with the analogy here is that you're still playing the guitar to make songs (an end product), instead of just learning how to pluck strings for the sake of plucking strings and testing how different strings of different materials feel for the heck of it.
  - ebbv 10y ago
    But that latter thing is still something guitarists do. You might throw some new strings on and noodle around for a day with no particular purpose in mind. Likewise it's fine to write code with no bigger goal other than to play with a library or a language.
- gravypod 10y ago
  There is a different between prototype and project. If you're experimenting with features you're not making a project. If you're making a project (I hope) you're not experimenting with features. That should be done in a prototype.
  - nickpsecurity 10y ago
    There's overlap. Most FOSS or personal projects are prototypes for something built for fun or learning. Something can be a project without it needing success, money, or quality. I believe Fred Brooks got famous pointing that out although it was unintentional for who he wrote about. ;)
kolbe 10y ago
This is right when you're already at a certain level of competence. I would be pretty disappointed to hear John Carmack was taking on this challenge, but it's a good one for people who need to just put some pencil to paper to get the practice.
- gravypod 10y ago
  There's a big difference between learning how to program and starting a library/project every month. If you want to learn how to build something, which is what programming is, there is a straitforward way of learning how to do so. Phase 1 is where you learn what programs look like. Pick any language. Learn all of the syntax and and meanings behind everything. Get to the point where you can start a project and write some code down and get a simple solution to a 1-step problem. Phase 2 is when you pick a long term goal. Something you want to build. Maybe a game, maybe a website, maybe automate some portion of your life. After that, you write out all of the things that go into making that happen. An itemized list of absolutly every feature you want to include. Then you go to phase III Phase 3 you break every goal into sub-goals, and those sub-goals into further subgoals so you have a tree. Stop breaking into sub-gaols when your goals are something like "Read config from file", "Grab user from database", "Render N many objects sequentially to the screen", "Wait to hear from clients wanting to connect". Phase 4 is when you read up on how everyone else is doing all of the things you want to do. Make a huge list of mappings from sub-goals to stack overflow links on the topics. Phase 5 every day, pick one of your sub-goals and implement a little prototype doing that sub-portion of your code. Phase 6 reduce your tree. Go through every sub-goal and merge it into it's partent subgoal's prototype. If you get to the point where the code is messy and hard to follow abstract, optimize, and clean your solution as needed. Do not proceed to the next sub-goal until you are completely happy with how your current sub-goal looks. Phase 7 test, test, refine, refine, clean, clean. Doing this may take a year to get 1 project done but it will be the cleanest, most organized, and probably gest example of how you can write code. I think this one project would be worth more then 100 other projects where you "do it live".
  - kolbe 10y ago
    That's certainly a good way to learn, though it's by no means the one and only best way. I personally think the best way is to go to MIT and do an EECS major. But we all have our different ways of approaching education, and I respect yours as much as I respect a person who learns based on building simple applications the can relate to and engage with better because they're more interesting.

ebbv 10y ago

> Don't write code just to write code, write code to solve a problem you are having. What if the problem I'm having is that I don't know Haskell? It's totally fine to code exercises that don't serve any useful purpose. Just like it's fine for me to make terrible songs on the guitar that nobody would ever want to hear.

atonse 10y ago
My take with the analogy here is that you're still playing the guitar to make songs (an end product), instead of just learning how to pluck strings for the sake of plucking strings and testing how different strings of different materials feel for the heck of it.
- ebbv 10y ago
  But that latter thing is still something guitarists do. You might throw some new strings on and noodle around for a day with no particular purpose in mind. Likewise it's fine to write code with no bigger goal other than to play with a library or a language.
gravypod 10y ago
There is a different between prototype and project. If you're experimenting with features you're not making a project. If you're making a project (I hope) you're not experimenting with features. That should be done in a prototype.
- nickpsecurity 10y ago
  There's overlap. Most FOSS or personal projects are prototypes for something built for fun or learning. Something can be a project without it needing success, money, or quality. I believe Fred Brooks got famous pointing that out although it was unintentional for who he wrote about. ;)

kolbe 10y ago

This is right when you're already at a certain level of competence. I would be pretty disappointed to hear John Carmack was taking on this challenge, but it's a good one for people who need to just put some pencil to paper to get the practice.

gravypod 10y ago
There's a big difference between learning how to program and starting a library/project every month. If you want to learn how to build something, which is what programming is, there is a straitforward way of learning how to do so. Phase 1 is where you learn what programs look like. Pick any language. Learn all of the syntax and and meanings behind everything. Get to the point where you can start a project and write some code down and get a simple solution to a 1-step problem. Phase 2 is when you pick a long term goal. Something you want to build. Maybe a game, maybe a website, maybe automate some portion of your life. After that, you write out all of the things that go into making that happen. An itemized list of absolutly every feature you want to include. Then you go to phase III Phase 3 you break every goal into sub-goals, and those sub-goals into further subgoals so you have a tree. Stop breaking into sub-gaols when your goals are something like "Read config from file", "Grab user from database", "Render N many objects sequentially to the screen", "Wait to hear from clients wanting to connect". Phase 4 is when you read up on how everyone else is doing all of the things you want to do. Make a huge list of mappings from sub-goals to stack overflow links on the topics. Phase 5 every day, pick one of your sub-goals and implement a little prototype doing that sub-portion of your code. Phase 6 reduce your tree. Go through every sub-goal and merge it into it's partent subgoal's prototype. If you get to the point where the code is messy and hard to follow abstract, optimize, and clean your solution as needed. Do not proceed to the next sub-goal until you are completely happy with how your current sub-goal looks. Phase 7 test, test, refine, refine, clean, clean. Doing this may take a year to get 1 project done but it will be the cleanest, most organized, and probably gest example of how you can write code. I think this one project would be worth more then 100 other projects where you "do it live".
- kolbe 10y ago
  That's certainly a good way to learn, though it's by no means the one and only best way. I personally think the best way is to go to MIT and do an EECS major. But we all have our different ways of approaching education, and I respect yours as much as I respect a person who learns based on building simple applications the can relate to and engage with better because they're more interesting.