Image via Wikipedia
Not too long ago, I had a Twitter discussion with Dru Sellers in response to an article he posted. It was really the sort of discussion we should have had properly over scotch, but we did the best we could with 140 character constraints.
The article he posted advocated teaching someone to program with a procedural language and ignore object oriented stuff, because it was an additional layer of difficulty and programmers who over-architected even small problems, which is essentially the view Dru advocated in our discussion. I took an opposing view that this approach produces people who have difficulty solving problems in an object oriented manner, and it was the late introduction of those concepts that made them so difficult for people.
I want to say at the outset that I’m totally right. Just because Dru brought up some incredibly good points that made me critique my own position doesn’t mean we should go crazy, here. In the workplace, it’s pretty rare to find programmers who are solid (heh) on Object Oriented Programming, and I do believe this is a result of their education, and I also believe they find the paradigm difficult because they’ve been taught to solve programming problems in one paradigm, and now have a very different one dumped on them. I would say that most people learn to program in a procedural (or crypto-procedural) manner, and still basically code that way even if the language is object oriented.
However, Dru brought up some very good points, and as someone who still considers himself a teacher, I really wanted to weigh them against my own thoughts and see where I might need to change to be more effective. Here are some things that came out of the wash.
The Best Teaching Method is Connected to Why You’re Teaching Something
In our discussion, Dru brought up that learning procedural programming allowed him to teach a five year old. He’s right. If I were teaching a small child to program and I had no cool graphical way to introduce OO concepts, I’d probably go procedural, too.
This is when I realized that we were approaching the question with different goals in mind. Dru was thinking about programming for the masses, and I was thinking about teaching developers. My own bias toward introducing OO concepts was because most developers need that paradigm in the work force. But when I was a kid, I learned programming like this:
10 PRINT “PHIL IS AWESOME! ”
20 GOTO 10
It occurred to me that I would actually teach programming paradigms very differently to a child being introduced to the wonders of commanding a computer and a college student aiming to become a professional software developer. Their needs are different and the end goal is different, so maybe the teaching methodology should be different as well. Maybe there is no one Best Way to Teach X, or at least, you can’t meaningfully address that question without first deciding who your audience is and what the end goal of the teaching is.
For all those of you who are currently saying, “Well, duh. You teach children differently than adults,” I’m not talking about the level of complexity or what have you – I’m talking specifically about procedural versus object oriented programming.
Programming is About Problem Solving
It occurred to me that Dru and I actually agreed way more than we differed, and one of the important areas was that object oriented paradigms are not the ideal solution to every coding problem. Some problems, for instance, are best addressed functionally.
So, once again, in terms of preparing a professional for the field, one of the things I want to make sure I impart is the ability to select the right paradigm for the problem. I do have to pick one to start by nature of the case, and I still believe starting with object oriented principles is the best pick for someone who wants to become a professional developer, but the issue isn’t really about procedural programming versus OO programming; the issue is about whether it’s enough to simply teach people how code does stuff.
The more I talked to Dru, the more I realized this was actually the issue I was concerned about: do we create professionals who know how to write code, or do we create professionals who can solve problems in the best way to meet the needs of the situation?
A carpenter could be a master at using tools and crafting things, but if she always builds two-legged tables, they aren’t actually crafting the best solutions.
And Then I Was All…
The next time I teach someone how to program, I think I might start by teaching them how to write tests in English. It’ll be an experiment; I don’t know if that will actually work well or not.
The idea, though, is that they would first learn to define problems and break them down into chunks. We could then use that as a basis to start using code to solve those problems in small chunks. You don’t have to architect a huge OO solution to satisfy one test, but at the same time, you’re operating in a larger context than just a “Hello World” exercise.
A lot of my colleagues are also teachers and mentors, and I’d really like to hear what your experiences have been.