When he was 7, my oldest son started playing at the neopets website. I got tired of spoon feeding him HTML and eventually tossed a couple of reference books at him, thinking "knock yourself out kid". He loved it. That's the environment my second son grew up into. Both of them loved computer games and still do. Eventually, the youngest one asked to buy a package, "Dark Basic". I resisted as long as possible, but eventually caved. He spent hours plugging together graphics routines, constructing his own games. He spent last summer putting together a visual demonstration of conic sections. He's a sophomore now, cruising through a Java course. He's working on a multibody gravitational simulation and understands the power of quad-tree data structures for that type of problem. I recently asked him what his best reference for programming is and he said "searching the web". I don't know exactly how or what lit the fire, but it is burning bright. I think you have to start from the point of what the young mind is interested in.
Consider yourself a new explorer in the developing field of Software Archeology. And if you're a programmer, consider that the task is listed under the heading of "jobs for programmers". Try to make it so that the next programmer to deal with the code has a few more advantages than you.
I was the lead consultant on an industrial automation project. We replaced the old (mid 70's) hardware and assembler software with off-the-shelf hardware and all new software. I was warned at the beginning of the project that the original system was delivered three years late. The hardware was shipped to the client and the final software was completed on the factory floor, not far from a multi-ton drop press. I designed the control app to leave a trail of bread crumbs in a log file, so each time a problem occurred I could nail the cause. It took six weeks in that environment to finish the job. I knew going into the job that it is important to avoid getting "all done except for fixing the bugs." But I also knew that I had to allow for errors and practice defensive programming.
Slashdot Mirror
When he was 7, my oldest son started playing at the neopets website. I got tired of spoon feeding him HTML and eventually tossed a couple of reference books at him, thinking "knock yourself out kid". He loved it. That's the environment my second son grew up into. Both of them loved computer games and still do. Eventually, the youngest one asked to buy a package, "Dark Basic". I resisted as long as possible, but eventually caved. He spent hours plugging together graphics routines, constructing his own games. He spent last summer putting together a visual demonstration of conic sections. He's a sophomore now, cruising through a Java course. He's working on a multibody gravitational simulation and understands the power of quad-tree data structures for that type of problem. I recently asked him what his best reference for programming is and he said "searching the web". I don't know exactly how or what lit the fire, but it is burning bright. I think you have to start from the point of what the young mind is interested in.
Consider yourself a new explorer in the developing field of Software Archeology. And if you're a programmer, consider that the task is listed under the heading of "jobs for programmers". Try to make it so that the next programmer to deal with the code has a few more advantages than you.
I was the lead consultant on an industrial automation project. We replaced the old (mid 70's) hardware and assembler software with off-the-shelf hardware and all new software. I was warned at the beginning of the project that the original system was delivered three years late. The hardware was shipped to the client and the final software was completed on the factory floor, not far from a multi-ton drop press. I designed the control app to leave a trail of bread crumbs in a log file, so each time a problem occurred I could nail the cause. It took six weeks in that environment to finish the job. I knew going into the job that it is important to avoid getting "all done except for fixing the bugs." But I also knew that I had to allow for errors and practice defensive programming.