Where to get started

I'm currently learning how to do Object Oriented programming (OO). What OO is I'll no doubt talk about at a later date, but for now it's enough to say that it's a more complicated way of creating computer programs than I am used to.

It's only in the last few weeks that I've actually programmed anything in OO, but depressingly its taken me about 2 years to get to this stage. What have I been doing in all that time? To begin with I had to become aware that this method of programming existed. Then I had to realise that it was worth learning; That was a big step, because it would be much easier to pass it over. Lots of people talk about the benefits of OO, but those opinions meant very little. I can program just fine without it. Indeed it took getting stuck to make me realise that this could be a way to go.

Finally I had to work out where to start. As a programmer you pick up a lot of new programming languages. A programming language is like a spoken language. "Tickle my armpit" in English versus "Tickle my armpit" in French is the same thing: words represent objects and actions, they're just different words, possibly in a different order. The principal is the same. Ask me to mime "Tickle my armpit" or sculpt it, then I'm on a new track. New concepts are involved. OO isn't a new language it's a new set of concepts. Look at a piece of OO code and although I can make guesses at what's happening I really don't have much of a clue. Things are being done for a purpose, but I don't know what that purpose is.

Where do you start to learn? To me there seem three ingredients: examples, concepts and experiments:

An example shows you how to achieve something, but just copying an example doesn't necessarily provide any understanding of the concepts that under pin it.

Take Flat Pack Furniture (FPF, lets keep the abbreviation count up). Great stuff - I built a table the other day. FPF instruction are usually step by step diagrams proceeded by a list of the parts you should have, but probably don't. 4 x screws, 8 x wooden pins, 3 x angle bits and 7 x tapered bolt things that swivel. To begin with you look at the pieces and wonder how this collection of pointless junk could ever constitute a table. Then you build. Lets dream the dream and pretend you get it right first time. Suddenly you understood what each of those parts do. It's obvious now why you need 7 x tapered bolt things; they join the flat bit of the table to legs. You know what they do and why.

You've made the table first time. You're feeling cocky. You decide build a flat pack chair. In light of the table you expect the seat to be held on with tapered bolt things, after all, it worked for the table. But no, the chair comes with 16 reversible self lubricated "L" pegs. They do the same job, but in a different way. If your desire was to become a furniture designer you then this could be a depressing moment. Some where there is a reason behind the two different methods for doing seemingly the same thing. Someone somewhere knows something you don't.

Imagine now that you use your table and chair experiences to designing and build a shed. It's probably a deathtrap waiting to happen, that's if you even manage to get started. Reversible self lubricated "L" pegs don't grow on trees, and I doubt you'll have any idea how to select, plane and mill a piece of wood.

Lets move onto Concepts. These usually take the form of an open ended list of all the knowledge you need to understand a particular process. It can be an incredibly long and hard route.

I studied engineering at university. 4 very long years spent studying. I know (or did know) how to analyse both the static and dynamic stresses in materials under a range of loads. I know how to work out the sheering forces in a screw thread, can calculate the center of gravity of a large object, and the frictional forces exerted on a flat plane. With all that knowledge can I design and build you a table? Well yes probably. it would be 6 months of complex maths and planning. The study of wood types and selection, theories on tools and sawing. The textbooks would pile high (presumably on a table not unlike the one I was designing). The work involved would be disproportionate to the problem. It would be very boring and seemingly unnecessary to go to such lengths. (There's an Ikea in Edmonton).

Experimenting is the process where by you try and fail! Then you try and fail again. You can loose limbs experimenting. With time you will get somewhere. Often where you get has been previously documented. When your front room is full of experimental tables, not a leg of equal length between them, you do wonder would it not be better to just copy an example. The time cost of reading a relevant text book might have been worth it.

I'm probably stating the obvious: When you learn something new you need all three of these qualities.

Examples are the quick start into learning a new skill. If you want to be a comedian, watch comedy. Imitating isn't a bad way to get started. At the very least it gets you started, and that's a big step.

Experiment, find out the traps and problems. Try to do something you don't have an example for. Rearrange that which you have to find out it's limits. Write your first joke, die on stage and realise you don't get it yet. This should make you aware of your current limits. It should create questions.

When you have questions look to the concepts. Find enough to get you unstuck. Answer the questions by digging deeper to understand how the examples you already have work.

I ussualy get to a point where I cycle between the three qualities. If I'm stuck I look for examples. If they don't work. I look for concepts. If they don't work I experiment. If that doesn't work I look for other examples based on what I have discovered. From this back and forth comes something new. Creation. That's the most rewarding bit. When experimentation combines with existing knowledge be it concepts or examples - and you create something that wasn't there before.

Two observations:

Object Oriented Programming is full of concepts. Most of them hidden behind complex words that aren't really necessary. It took a long time to get my head around the concepts. I probably did too much theory and too little playing. If you want to start OO I recommend starting small. Lots of examples. Read lots and try to sort the useful information from the tonnes of words and rules. You will get there, don't be put off.

If you don't balance out concepts, examples and experimenting then you can get stuck. In comedy I have got bogged down in the theories and concepts. I stopped watching it and I don't experiment enough. That's a killer. Interesting that it's almost the same trap I got into as OO.

Long post. Hope useful to someone.