New to programming? It is natural (but needless) for you to be nervous
Archive - Originally posted on "The Horse's Mouth" - 2009-07-14 08:23:01 - Graham EllisYesterday, I ran the introductory day at the start of our Learning to Program in Ruby course.
Delegates come to us to learn a programming language with two different backgrounds - "I have programmed before in xxxxx and now I need to learn QWERTY" (the converters) and "what is this programming thing all about anyway" (the newcomers). The newcomers are typically nervous at their lack of knowledge, overawed by the people they'll meet who they feel are going to be much more clever, and worried about not 'getting it' in the new world of programming.
If - as a programmer - you're reading this, you'll know that the newcomers should not be nervous. The newcomer is no less bright - just less practised, and can and will pick up programming if they have an aptitude. The convertors were newcomers once, and understand very well indeed what the newcomer is going through - and want to help that newcomer. And the teacher (who was also a newcomer once) gets an immense satisfaction from helping the newcomer start from zero, and pick up some of the basic concepts and start plugging them together into usable, and then useful programs.
Don't get me wrong - the hardest courses to teach are the "complete novice" ones, but they are also so much more rewarding. I tend to end up writing brand new example code, showing the individuals on the course not only WHAT a program looks like but HOW it is reached. And each individual finds different things easy and difficult, so the examples vary every time.
The other great thing? "Get 'em early and they don't get bad habits". My "learning to program" days show not only the mechanism of programming and how it applies in a certain language, but also what is good and what is bad ... I can teach people that they should comment their code well, that they should plan what they're doing, that they should write and test in stages, that testing is important and that if they find themselves copying and pasting code they should be structuring their code ... all of which go towards making code which will be easy to maintain, which will run consistently and which will tend to be more reusable and more reliable.
During yesterday, I developed a number of examples and I have added them to our web resources this morning. Some are dinky little examples to show the basic features and principles, others are somewhat longer to say "yes - we are headed to a wonderful destination here, even though we don't arrive until later in the week". And they also say "you, dear newcomer, will see how the things you learn on the first day are going to be an integral part of your live applications".
Here are those examples:
[link] First use of variables and calculations
[link] Simplest practical program - read from user, calculate, output result
[link] An example with a loop, showing how you should plan and document your code
[link] Naming a block of code - adding in structure and re-usability, and a first introduction to local variables and why that is a good thing
And some of the demonstrations of "where are we going with this ..."
[link] Read through a file and report on all lines matching a pattern, with management summary at the end
[link] Finding and matching various lines and keeping several counts
[link] Analysis of a large data file (web access log) which reports on the pattern of matching for the last 24 hours.
At the end of the day ... the final example produced some really useful results for me; I have wondered about the pattern of accesses to our servers over a 24 hour period, and this little program give me a profile for one day, and I can go on and extend it later ... no doubt I will be doing so, when I get the time (a.k.a. a month of Sundays!)