Ben J. Christensen

The foundation of my software development skills was set between 1995 and 1998 while I worked under the direction of my friend and mentor Andre Kruger. For a long time I called it “job shadowing”, but I have come to realize that it was an informal apprenticeship.

I have found those 3 years taught me more about software, system administration and technology than most get the opportunity to experience that early in their career – as I was learning and working on the job, tutored by someone who was incredibly intelligent and had years of knowledge and experience to share. He also provide me with invaluable insights and suggestions on what technologies and platforms to follow. It was he who suggested Java (when it was at version 1.0) was what I should focus on, not C – and that has served me well to this day – when the schools were telling me to learn Pascal.

I loved it and sucked up as much as I could learn. I also built software that did real things. Now I recognize how poor the code was – it was very bad. The point was that I was learning through doing real things in an environment where I couldn’t do significant damage and could receive instruction and guidance – and eventually as I progressed I could truly understand the benefits of design patterns, object oriented design and what it meant to be “in production”. It wasn’t theoretical – or some forcefully memorized and quickly forgotten trivia – I knew it.

I didn’t complete college/university – because by the time I got there it bored me to tears, as I had spent several years being apprenticed already and learned quickly on my own through books and experimentation. If I could have, I would have skipped to 3rd year and enjoyed myself, but our society and academic programs don’t work that way.

I believe apprenticeships are the ideal way to learn software development, as I see software as a craft – not an engineering or scientific skill where rules are learned and applied the same way every time.

I wish our society and industry would look seriously at its academic and theoretical approach to training – which I feel does not work very well – and consider a model more similar to apprenticeship.

I also really enjoy mentoring others who have raw talent and desire. Some of my most rewarding work of the past 5 years has been that which has resulted in colleagues progressing and growing, such as a good friend of mine Adnan Memon.

Perhaps I’ve accomplished the “master” status in certain aspects of my work, in others I’m still a “journeyman” I’m sure. I hope to find others who can continue to mentor me as I try do so for my juniors, as I think that’s where the best talent in our industry comes from.

Last week I learned how to program on the iPhone using Objective-C and Cocoa Touch by having two 2-hour pair programming sessions with Brent Coursey and about 8 hours of my own playing around.

I am comfortable now with XCode, Interface Building and Objective-C – enough that I can build code to do what I want it to do, compile, run, debug, test and install on my personal iPhone.

I’ve connected to web services via Objective-C and built a user interface to interact with the services.

All in all it was a good experience and great way to learn – and the pair programming was very useful in speeding up the learning process. Unlike 10 years ago where I plenty of time to learn through trial and error, it was much more effective to sit and watch someone and see how everything worked together. I was able to pick it up very quickly that way.

Of course, 10+ years of object oriented programming in Java translates over well to the thinking and expectations – but the syntax and different ways of doing things were far from natural for a java programmer (especially one who had respectfully ignored the C way of doing things), so the demonstration received through pairing was immediately beneficial. (On second thought, ignoring C probably helped since I saw Objective-C as an OO language from the start – not as C)

A 2 hour session with Kent Beck sold on EBay for $405. That would be quite the experience – would love to do that and see how he or someone else at his level does their craft.

These guys are “computer scientists”.

Being a programmer, developer, architect etc does not in my opinion constitute being a “computer scientist” or working in “computer science”.

Perhaps the most general definition of science can be used for “developers” if we stretch:

- a branch of knowledge or study dealing with a body of facts or truths systematically arranged and showing the operation of general laws: the mathematical sciences.

But that doesn’t describe the whole of it like these definitions do:

- systematic knowledge of the physical or material world gained through observation and experimentation.

- knowledge, as of facts or principles; knowledge gained by systematic study.

As programmers we don’t do this – we use technology (the “applied science”) to build things and solve problems.

We may sometimes pretend to venture into “science” as we “research solutions” – but we’re just looking for knowledge and facts the “scientists” have figured out and then applying them in unique and novel ways.

Calling a programmer a scientist is like calling an artist a chemist because they use chemical compounds (paint, graphite, clay, steel, glue whatever).

Why does this matter to me?

Because by training our programmers in theoretical “Computer Science” educational programs, we are not actually creating employable or productive people. Sure, they have basic skills and theory that can then be applied through further effort – but unless they are one of the rare few to study, analyze and experiment with computer science theory – most of the knowledge gained serves little to no value in applying the techology of software development in real-world programming of software.