When I first learned to program back in early 90s, I thought that knowing the grammar of the programming language is what I need. It took me excruciating week till I could use all MSDOS commands, “for” and “while” loops and some other grammar. I was ready to program! I decided to write a racing game. For cars I would draw boxes, I could use keyboard presses for “left” and “right” signal – I was ready! The game kind of worked – there were some boxes that I could move on the screen, but it was so depressingly hard to write, boring to play and utterly useless that it took several years till the next time I wrote more a program longer than 50 lines of code.
When someone who is not a programmer thinks about learning a new programming language, they think about grammar, maybe some infrastructure classes one needs to remember. You can use whatever memory methods to do that [for example loci]. However for a programmer, this is about 5% of the task. What constitutes learning a new programming language for me?
Step 1: Understanding design paradigms. When someone writes a programming language, there is a very good reason to do this. This reason is implemented in subtleties of the language grammar and infrastructure. For C# it is managed vs unmanaged memory, for C++ it is classes and polymorphism, for functional C it is working with pointers, for Java it is “write once test everywhere” concept and so on. These concepts are often language-specific, not very transparent for a newcomer, and they require some focused reading on the philosophy of each language. In this sense, working with a different sort of processor (CPU vs GPU vs DSP) is similar to learning a new language, but with penalty of learning hardware architecture that requires such language.
Step 2: Learning your IDE. Integrated development environment is the screen where you spend 80% of your time when programming. Some, like XCode and VisualStudio are fun to use. Others, like Eclipse, are annoying after being spoiled by more friendly platforms. The development platform comes with a vast array of tools for creating new projects, managing code versions, debugging, searching within the code etc. The training is usually hands-on and effort intensive, since the documentation is not very clear. Each time I encounter a problem, I look online for others who faced the same problem. Almost always I will get either a YouTube video or a detailed blog explaining how to solve the problem.
Step 3: Writing simple stupid code. Before writing any useful code, it is nice to generate several training projects, exploring various pars of the larger project in a very simple and transparent form. This hands-on training is the most important part of learning. For example, the hardest part for me in PHP is the annoying “.” operator for sting merging. These projects will not be perfect, but at least they will generate the intuition required for the actual project.
Step 4: Facing the unknown. When writing the actual project, some problems are harder than others. When facing functions that are hard to implement I put skeleton of a function with comment to myself “Here I do ABC”.
Step 5: Debugging. Eventually we all face bugs that are extremely hard to solve, solving them makes us face the next level of bugs. It is very useful to have a buddy at this point – someone willing to listen to you and say what he has to say. We are so locked in our own ideas, that simply telling them to others we find where we went wrong and can fix it. Do search a lot – if you face a problem someone probably faced it before you.
Step 6: Design patterns. Each programming language comes with design patterns and some frequent algorithms. You do not know C if you cannot build a singleton and write bubble sort code. You are not a web programmer if you do not use AJAX. If you work with GUI, you should no MVC paradigm. Make your code more efficient and more beautiful using design patterns and common infrastructures.
Step 7: Rewriting. For me this is the hardest part. After writing the code for a while, we start to understand what a good code would be. At that point our own code looks like a battlefield with our ignorance. We need to rewrite the code from scratch the right way with documentation. But we are tempted to reuse our previous code and mistakes, stressed by milestones, and generally tired after facing our own ignorance.
Step 8: Mastery. It takes many successful projects till we master new programming skills. It is always worth to know that an hour spent on good design may save four hours of implementation and a day of debugging. Do invest more effort visualizing the code and all use-cases. PAO and mindmaps are probably very useful here. Once your code gets to your clients, each mistake has a very high price tag. Try to fix your mistakes as early as you can.
When I learn a new programming language, I usually need to learn several disciplines. Mostly hands-on. I write a lot of simple sample code, and then I throw everything and start from scratch. Each time I tried to short-cut I paid a price… Learning grammar is easy, learning to design the code properly is harder. It always helps to have a good experienced software guru or architect near you… All programming languages are somewhat similar to each other. The more you know the easier it gets to learn.
