I’ve been programming in multiple languages on multiple platforms for forty years now. As an idle thought, I have contemplated a particular thing I would like to teach the next generation of programmers.
It’s a very simple setup.
Every participant is given a very old school ball point pen with cap. The old old style, where there is an awful plastic cap that has a trailing edge for no reason.
Before you, you have a pen. It has a cap. Your mission is to balance the pen on the cap. The cap is point up, the pen is point down. If you need a demonstration of what that looks like, I will show you.
You have 5 minutes to formulate a plan. After those 5 minutes, you have 1 hour to execute that plan.
The idea is to give a crazy task, with a time limit, and let the students formulate their plan and execute it. There is no right answer. The point is to demonstrate that ingenuity is key. Whether you hot glue it, construct LEGOs, or something else is irrelevant.
Now that you’ve all had some time to formulate a plan and execute it, I will ask a simple question. What is the one thing that all of your solutions have in common?
The common thing is you. You all found different ways to approach this task. It didn’t matter the tools you used to approach the task, all you thought about was the goal, the end state. Sometimes you use tape, sometimes you used string, or some other crazy contraption. The tool isn’t important.
It’s the same thing with programming. You are given a start state and an end state and you need to figure out how to get from here to there. We, as social animals tend to self identify with particular solutions, but that’s not what we should be doing. Instead, we should think about the best tool for the job at hand. The number of programming languages I have mastered and forgotten far outweighs the ones I can program in today. Because the language is not important, what’s important is the solution. The solution to the problem in front of you can be quite unexpected.
What I want to teach you is that the tool is not as important as the user of the tool.
I too have had idle thoughts about what lessons to pass on and what was lacking in my own formal education.
My elevator pitch is to have a semester long project broken down by feature. You get a couple weeks to develop, but after each one is complete you have to trade code bases with someone else in the class. It’d teach both how to work in an established code base, and how to be kind to some future maintainer (who might be yourself).
In theory, that’s a great Idea. The problem would be that many code bases would be very difficult to work with, and inheriting one would put some students at a real disadvantage.
Perhaps if the instructor culled the worst ones, and made sure that no one gets their own code base back.
I feel like there would be some logistical challenges, but it could probably be worked out.