Today, I'm focusing on how to select a school. While I'll focus on Technology, this really applies to many topics. When I find a school that has the class coverage I want, I then seek information on the key instructors.
I want two things in my instructors, that they do practice what they preach, and that they view what they do as a form of art. Technology and art forms are not usually synonymous, but I'll get to that.
First, I want to talk about practicing what you preach. I don't want a teacher that studies and does a few practices on their own, but isn't expected to complete practical work. There are a hundred ideal ways to build an application, but many of them are not practical with modern management. Projects start with great aims, but change significantly and often. Not many isolated teachers recognize that in clear enough terms to prepare their students for it.
An easy example of the difference between knowing the path, and walking it, is to look at learning a new language. There are not many teachers or books you can learn from that once you've mastered their courses, you can travel to the country of origin and speak the language, without people knowing that this is a 2nd language for you. It stands out. This is the same with programming. You step out of college, get your first job, and suffice it to say, there are plenty of things you still needed to learn, like we don't actually do that here, or that's not really practical given the time constraints, or don't tell management you can do this in 3 weeks when you haven't actually built one before.
An instructor who has to work in a practical environment is something I would target. This is usually easy to figure out, as most instructors will usually have a page describing them selves, and what they do. If they have a job or run a company, aside from teaching, they'll probably list it.
The 2nd target I seek, is an instructor who really sees the art of what they do. This is a little harder to learn about the teacher, but it is really valuable to have. Some one who doesn't understand art, sees what a picture looks like. But an artist can read between the lines. They can see the feeling that was intended when it was written. This is not limited to the commonly accepted artistic fields.
This is really about reading between the lines. What does something mean that it does not clearly say? Someone might look at the Mona Lisa, and see a painting of a woman, while others who look deeper, will read subtle expressions of thought that show up through it, along with many other things.
This translates to programming as well, because the code is similar to art. If you look at it, it tells you what the developer told the computer to do, but if you read between the lines, you'll see why. Many developers don't use much in the way of style guides, and pretty much live off of the commonly out-dated Hungarian notation.
The problem with this lies in the fact that when you don't commit to a stronger style guide, the styles that do show up change from line to line, sometimes even multiple times in the same line.
In the real world, when some one programs like this, and another developer is brought in to take over, or restart the project, they often feel it would be a better idea to rebuild the entire program from scratch. It doesn't flow well, definitions aren't clear and you usually have to dig through layers of code to figure out what part of it does.
Someone who has experienced this, experienced it and grown from it, will be able to pass that on in classes, otherwise they are dooming all of their students to suffer the same fate, and pass the same problems through the work place.
If possible, find some source code, (often examples made by the teacher, or pet projects they have public on the Internet) and ask a friend who has experience to read through it, and tell you what they think of the code. A more inexperienced friend might call the code overly formatted, but typically it will be easy to read, understand, and express itself clearly.
For those of you involved in programming, who commonly find yourself wanting to rebuild your own projects after only a short while, because you've learned a new trick, or want to re-organize it, I suggest you look up Microsoft's API Design Guideline. There's a digest floating around that sums it up quite nicely.
