Yes, I was a math major at MIT in 1969. I started taking EE classes and eventually ended up with a second degree in EE/CS. It was during this time that I took Winston's AI class. The lectures took place in the Institute's largest lecture hall; it was a popular class for good reason, Prof. Winston's class was great.
I'd had take-home tests before but Prof. Winston's were the first and only 24 hour tests that I've ever had. I remembered that he said that they had tried out the problems on some of the TA's for the class and that it would only take us a few hours to finish. For me at least, it took 24 hours and I still wasn't done.
Prof. Winston's class material was mostly in Lisp, but we also looked at Planner, kind of a DSL for AI. I was very impressed by a program presented by Winston that was capable of performing symbolic integration. Prof. Winston remarked, after we had discussed the program, that really, it wasn't a complicated system, just a simple algorithm with a data base of facts about integrals.
He also had a very funny, perhaps apocryphal, story about Joseph Weizenbaum's program ELIZA, a program that carries on a conversation with its user in the manner of a psychotherapist (like the doctor command of Emacs). Again, it turns out to be a simple program in Lisp with a small database of keywords and responses. Apparently, Weizenbaum had been working on the program on an MIT timesharing system and another professor had seen he was working late so he used the system's chat program to attempt to communicate with Weizenbaum (somewhat like the Unix talk command that lets one user contact another currently logged in user). However, Weizenbaum wasn't actually there he had gone to sleep and had just left his terminal with ELIZA still running and connected to the I/O of the terminal. The professor asked a question like "What are you working on so late?" and ELIZA responded in it's typical fashion: "Is there a reason that it's important to know why I am working so late?". The professor, a bit put off said something like "You were on the computer late and I was just curious." and ELIZA said back "Why do you feel that you are curious?" the conversations continues: Prof: "Why are you acting so strangely?", ELIZA: "Tell me more about your feelings that I am acting so strangely."
Finally, the professor is fed up with the crazy indirect answers and just calls Weizenbaum on the phone directly. At the late hour he is answers sleepily: "Hello" the professor says "Why are you acting so strange tonight?"; Weizenbaum replys "Why is that you are asking me why I am acting so strange?"
I started programming while in high school. At the time 1967, there was no way to do programming at home, there was no internet. I taught myself by reading a 1965 edition of McCracken's A guide to FORTRAN IV programming. The first program I wrote (on paper) was a program to solve linear programming problems using the Simplex algorithm which I had seen a high level description of. I punched up a program to do it on cards using the high school's data entry IBM 026 keypunch machine. I gave the cards to a friend that gave my program to someone over in the school district's administrative building to run on the school districts only computer (I think it was an IBM 1130).
Naturally, my first program didn't work. So it was back to rereading the book on programming and starting out with simpler examples. Turn around time continued to be about 3 days but I viewed programming as a hobby, a bit like being a Ham radio enthusiast. At MIT I continued to view programming as a hobby, but after a while I realized it was worth taking it seriously.
I didn't always do well in my undergraduate classes. I had gone to very bad schools growing up and everything was too easy for me until I got to MIT. I finally learned how to study by the time I got to grad school. Despite this my time there as a student was great. I remember many great professors in addition to Prof. Winston.
Also notable was 6.252 - Structure and Interpretation of Computer Languages. Prof. Dertouzos taught this demanding class. He recommended that I ask a new professor at MIT, Prof. Barbara Liskov (she later went on the be awarded the Turing Award) to be my undergraduate thesis advisor. She changed the way I thought about CS; it was a turning point in my life. I still remember asking her if knowing lambda calculus had any use, lol.
I'm now a senior citizen and next year will have been programming for half a century. I still write code almost every day. By now, I've programmed on every imaginable kind of machine, in every kind of programming language. I've invented important techniques in the field, started a successful publicly traded company, and been very happy with my career choice.
As someone who reads and writes thousands of developer resumes a year, the major problem I see is that people have a difficult time separating what is important from what isn't, and separating day-to-day responsibilities (which are typically understood from a job title) from unique and novel achievements. I don't know if this kind of tool solves that problem.
Much of my work with resume clients is extracting what they do from them and then putting it into efficient words. Many people struggle with just explaining what they do.
The other problem is that you have to understand that your reader often isn't someone with a highly technical background (or even a recruiting background), so you have to define yourself quickly in order to prevent the reader from misinterpreting who you are. If a reader is looking for a "Python Developer", it's best to refer to yourself that way on the resume.
For senior level people length is often the issue - it's a highlight reel - not a biography. Anyone can get to 1-2 pages max.
I want to echo the suggestion that several others have made, to start with a good book on just about any programming language that has a lot of sample programs in it, and learn to read that code and execute it with pencil and paper.
This will be much more productive than trying to learn to write code from scratch while also learning a language and learning how to execute the code with pencil and paper.
I would start by going through the exercise yourself: pick out a book and use one of the first sample programs, and set up a "debugger" on a pad of paper.
I used to do this kind of debugging myself: when I first learned BASIC back around 1969, I spent some time in my grandmother's basement with two pads of paper, one with my code and one for the debugger. The debugger pad had columns across the top:
Line number One variable Another variable Another one
Then I would step through my code, adding a row on the debugger for each line I executed, with the current line number in the first column and each new variable value in the other columns.
After going through this exercise with one program, send your friend the "debugger" pad along with the book, so he has a place to start with this idea. He can then go through the same example and follow along with your debugging steps.
That way he has a solid place to start when exploring the other sample programs in the book.
Please feel free to email me if you'd like to kick this idea around - address is in my profile. And I strongly suspect that everyone else in this thread would be happy to extend you the same offer.
I also heartily endorse the suggestion to read Charles Petzold's _Code_. It's a wonderful book!
