A lot of people miss out on an excellent opportunity provided them to learn development techniques and/or how to use a given language well. Most people stick to a few things: books; school; and asking for help. I’m going to suggest that there’s a way to quickly learn that can actually be more beneficial than any of those things: answering questions.
Reading a book and receiving instruction at school are passive methods of learning. Although you have to actively look for the book, read it, and/or listen to your instructor, you are not being active in acquiring the information within. It’s the same with asking a question. Receiving an answer is a passive act and in my case, and I’m sure there are others out there, being active about your education is more effective. To be active about learning you need to seek out and solve problems. This is why books so often have exercises in them and why instructors issue homework problems.
The problem though with book exercises and homework problems is that they’re too often based simply on learning one specific issue. Often times the solution to an exercise or homework problem involves using techniques that are actually bad in real practice. For example, in learning C++ you might be required to learn the differences between pass-by-value, pass-by-reference, and pass-by-pointer. Very often this is instructed by suggesting problems that require what are called “output parameters”, parameters you pass a function expecting them to be changed by that function as its “output” rather than simply receiving a return value. This is a practice that is used in real-world problems but it is also one that is best avoided.
Another problem with homework like problems is that they do not tend to develop a wider philosophy about programming. Although there are books on design, books on idioms, etc… without applying them to real problems you won’t develop your own philosophy about what works and what does not. You won’t be able to apply these techniques to anything but trivial, homework like issues and the real world is nothing like the trivial problems given in homework and exercises.
There are a myriad of places on the Internet in which people with real problems come to get help. Very often these WILL result in philosophical discussions, even “flame wars”, regarding what is good practice and what is not. You could simply lurk these places and learn quite a bit but this is still passive participation and you won’t actually get the practice of applying what you’re learning. My suggestion is thus to get involved and to try answering questions asked in these places. You can start small by helping people answer basic homework like problems and move up, or you can jump in and try to answer hard problems. This forces you into the position of teacher rather than student.
One thing I learned both in my career as a developer and also as a martial artist is that teaching forces you to think very hard about what you’re doing. You can’t just do and expect others to pick it up. You have to consider how to take what you know and convert that into instruction material. Furthermore, you have a great desire to be correct so that you don’t teach wrong things. The more you focus on how to teach something, the more you are focused on the details that are important to a subject. For example, trying to teach someone how to apply the Open/Closed Principle requires that you understand it well enough to impart the basic principles. If you are answering a specific problem about the OCP then you have to be able to describe the reasons behind your application of the principle to the problem; you’ve now *applied* the principle in an active manner and thus learned how to actually use it.
Another important aspect to active participation is arguing your case. This is important for two reasons. First, you need to know how to convince other developers that your solution is the right one; just yelling doesn’t always work because sooner or later you’ll run into someone who’s just as willing to yell as you are. Second, you get to test your philosophies against other philosophies, gaining a deeper understanding of your own in the process and/or adopting those pieces from others that simply seem better. Passive participation in argument, just listening, may sometimes help but there may be things you miss out on because one side or another never actually got around to addressing the weaknesses in your methods because you never brought them up.
An important part of participation at this level though is sticking to your guns. Don’t just roll over because you think someone has more experience than you. Bashing your head against someone that knows more can sometimes provide even greater insight than just taking their word. You may even change their minds because everyone has something to teach, even those who don’t know they do. I’ve learned more from arguing with others than just about anything else. Although its rare that I realize I’ve been wrong during the argument, one can’t help but be changed later as the brain processes what its taken part in. Sometimes I find that I’ve later adopted an opposite position to what I’ve argued earlier without ever realizing I changed my mind. So argue away and don’t let people bully you with authority.
Some people don’t answer questions because they think they might be wrong and look stupid or something. To them I say, grow a pair! Looking stupid is unavoidable and everyone does it from time to time. Don’t be afraid! Being wrong is even better than being right when it comes to learning new things. Answering questions is supposed to benefit you at least as much as the person you are “helping”. Don’t worry about leading people astray, your peers will make sure that doesn’t happen.
So my advice to upcoming developers: Jump into the fire! Get in and get your hands dirty. Be an active participant in the developer community. Answer questions. Sit at your terminal with your stack of reference material and your compiler open and ready so you can look for and test your solutions. Practice your craft!