Regarding programming there are a lot of different formal
methodologies for how you should go about it. But a lot of those assume
you are already knowledgeable in the programming language and coding
task at hand.
There's also a lot of differing ideas on how to best learn things. But most of these are geared for pure learning, and don't really address the situation of a busy person who just wants to learn enough to get something done, for which there may not be examples, documentation, or mentors.
The most effective method I've seen for this kind of situation I picked up from some mathematician/programmers on one of my projects, which they called "Toy Driven Development". I've adopted that style with my own personal projects to good effect.
Starting from zero, you think about the general goal you want to get to, and identify one or more problems you think you'll need to solve in order to get there. Select the simplest sounding problem that isn't something you already know. Do some research (via google) to see if anyone's already done it (or asked about it on StackExchange!), and if so snag the example, take it apart, study it, master it, and tweak it into something more closely resembling the project ahead of you.
If there is no such thing, then you have some experimenting to do. Find out what you can via manuals or whatever and get hacking. If you get stuck, ask for help or to bounce ideas off others. But keep your goal simple. You may realize that the single problem is often several; if so pick one and write the others down to work on later. Don't worry to much about proper code formatting or writing tests or documenting interfaces or any of that (unless it helps you think), just focus on the specific problem you're trying to sort out. Once you've solved the problem, do tidy up the code to get rid of superfluous scaffolding or test code to make your toy clearer. You want it short, something that makes a good example. If you can get the toy to do something useful by itself, that's perfect. Use the toy in various different ways to see if you can break it or find bugs.
Next, whether you found an example or made one yourself, put it in an Experiments folder, and move on to the next problem you want to have done. Keep iterating until you have a handful of these toys.
Then, shift gears to "integration". In this phase your coding should stick to things you already know well. Assemble a good solid infrastructure for your code, documenting and writing tests for each bit as you go (or write the tests and/or documentation first!) Don't cut and paste your toy code directly into your project, but instead use it as a reference as you re-write the code properly. When you get to a point where you're just not certain how to properly do some new feature, that's your signal to go make another toy.
Anyway, the point is to keep the (fun) experimental work separate from your project. This helps you control the balance of time you spend learning vs. implementing, and helps you shake bugs out of new code ideas before they infect your main codebase.
Same approach when reading a programming book. Read a little, run the examples and do some experiments to solidify what you've learned. Then go back and read more. But if it's something you already are relatively comfortable with (like learning your 5th programming language) then just read straight through.
There's also a lot of differing ideas on how to best learn things. But most of these are geared for pure learning, and don't really address the situation of a busy person who just wants to learn enough to get something done, for which there may not be examples, documentation, or mentors.
The most effective method I've seen for this kind of situation I picked up from some mathematician/programmers on one of my projects, which they called "Toy Driven Development". I've adopted that style with my own personal projects to good effect.
Starting from zero, you think about the general goal you want to get to, and identify one or more problems you think you'll need to solve in order to get there. Select the simplest sounding problem that isn't something you already know. Do some research (via google) to see if anyone's already done it (or asked about it on StackExchange!), and if so snag the example, take it apart, study it, master it, and tweak it into something more closely resembling the project ahead of you.
If there is no such thing, then you have some experimenting to do. Find out what you can via manuals or whatever and get hacking. If you get stuck, ask for help or to bounce ideas off others. But keep your goal simple. You may realize that the single problem is often several; if so pick one and write the others down to work on later. Don't worry to much about proper code formatting or writing tests or documenting interfaces or any of that (unless it helps you think), just focus on the specific problem you're trying to sort out. Once you've solved the problem, do tidy up the code to get rid of superfluous scaffolding or test code to make your toy clearer. You want it short, something that makes a good example. If you can get the toy to do something useful by itself, that's perfect. Use the toy in various different ways to see if you can break it or find bugs.
Next, whether you found an example or made one yourself, put it in an Experiments folder, and move on to the next problem you want to have done. Keep iterating until you have a handful of these toys.
Then, shift gears to "integration". In this phase your coding should stick to things you already know well. Assemble a good solid infrastructure for your code, documenting and writing tests for each bit as you go (or write the tests and/or documentation first!) Don't cut and paste your toy code directly into your project, but instead use it as a reference as you re-write the code properly. When you get to a point where you're just not certain how to properly do some new feature, that's your signal to go make another toy.
Anyway, the point is to keep the (fun) experimental work separate from your project. This helps you control the balance of time you spend learning vs. implementing, and helps you shake bugs out of new code ideas before they infect your main codebase.
Same approach when reading a programming book. Read a little, run the examples and do some experiments to solidify what you've learned. Then go back and read more. But if it's something you already are relatively comfortable with (like learning your 5th programming language) then just read straight through.
Nice, all info in this blog very useful
ReplyDeleteUpcoming IPO