AW-704244340
top of page
Writer's pictureNicky

You don’t need to be a great programmer to be a great programming teacher!

I know, sounds strange right?


Let me explain...


My Programming Background

I used to be a programmer. I worked for a small software house in a little village in Essex and we created software that could be used in colleges to teach NVQs. Quite a niche.


We used a terrible programming language called Authorware, which we dubbed “Awfulware”. I should point out this has since been bought out by Adobe so I am sure the current software is much better than the original version I was using in the 1990s.


Don’t get me wrong, working in the company was fun, it was just that the programming language we were using would drive us all nuts. I worked with one of my best mates and were paid to go to the pub to play on their “Crystal Maze” game to get inspired for activities we could use in our own software. We played loud music all day and got to work with some amazing people. It didn’t give me the work ethic I have now, but it showed me how to think like a programmer and how creativity is a huge part of successful programming.


I was introduced to other programming languages and expanded my repertoire, but I will never forget those giddy days where I first learnt the trade. It was exciting and I loved that I was able to solve problems and be creative. We were just thrown problems from the course writers and left to solve it somehow.


You want a game where students work through a maze but you want it educational, leave it with me.”


Oh, you need to create a puzzle where they move parts around the screen, I’ll get right onto it.


“It has to have some sort of quiz element and you don’t know what it will be but you want it different to anything else that is out there, I’ll see what I can do.”


Loads of creativity and loads of problem solving, lovely.


I shudder at the memory when I went too far one day. I was trolling through the vast image folders we had access to, looking for an interesting photograph of a medical condition for the Hairdressers NVQ software that I could use. I came across a photograph of a cyst on the top of somebody’s head. A large angry looking boil thing that was poking out of the hair.


What else could I do as a 23-year old who has been given far too much leeway than was good for me? I made it wink when you click on it, obviously.

Obviously

I only told my friend, expecting to get into trouble. It went through final testing and documenting and nobody came back to us and said “What on earth do you think you are playing at?” So I guess they never noticed and that little Easter egg is out there somewhere, I wonder how many students discovered it?


I digress, back to the story…


I’m Not A Great Programmer


The reason I was telling you this is because I freely admit I am not a great programmer. I’m a good, solid programmer and understand the basics and how to apply them but I am by no stretch of the imagination a great programmer.


And yet:

All this is possible even though I am not an exceptional programmer.


All you need is A BASIC UNDERSTANDING OF A FEW SIMPLE RULES AND AN IMAGINATION TO APPLY THEM.


Really, read that line again. All you need is “a basic understanding of a few simple rules and an imagination to apply them”.


What Makes A Good Programmer?


Programming is not about finding the correct answer straight away: it is about thinking creatively, a lot of the time learning from our mistakes and applying what works well in other ways.


On my first day at the software house I was given a programming problem and told to fix it. I sat down and started writing a flow diagram (as I had been taught) and pretty soon my manager came over and asked what I was doing. When I started to explain the top down approach I was using, he gave me a withering look and said “Just get typing, we can sort out the documentation afterwards”.


This was a revelation to me. It was not the way I was taught to work at university but from talking to many other programmers, it is certainly the way that most of them seem to work.


If it is a complex problem, programmers may sketch out a very rough drawing to help them (I still do it myself from time to time) but generally flow diagrams are used as a debugging tool or in the documentation that is written after the program is tested and finalised, to explain it to others.


Most programmers start by just typing in the bits they know and then have a stab at filling in the blanks later. They test, adapt and retest small sections until they get that bit working and then have a go at another small section until eventually the whole beautiful program is working together as it should. If they had created a flow diagram first then the final program will probably have very little resemblance to it once it is finished anyway.


Nobody, and I repeat NOBODY, documents the entire program first. It would be a waste of time as the program grows and adapts like a living being as it is developed.


It would be the same thing as writing an autobiography when somebody is still a new-born baby. There is no way that programmer will know the detail about the program to write pseudocode with any real meaning. They can create a basic structure diagram, and often do, but any more than that is pretty pointless.

Why Do We Force Pupils To Program In Such An Unnatural Way?


I see too many teachers on my Python training courses who tell me that they ask pupils to create a flow diagram and pseudocode of EVERY program before they start typing it. They often tell me this proudly as if I would congratulate them. As if I would be pleased, they have managed to remove any spark of creativity or spontaneity in their students.


NO, No, no.


I say let your students fly. Let their imaginations work to their advantage and let them see programming as a problem-solving, creative and therefore enjoyable exercise rather than a chore of paperwork and admin.


Sure, it is important to show your classes how to create flow diagrams, structure diagrams and pseudocode but don’t use it for EVERY program they do. 95% of the programs I give students are a challenge that they can just crack on with and only occasionally specify if I want them all to create a flow diagram or write the pseudocode first. And that is really so I know they can and to remind them how to create them. But, students certainly don’t need to do it for EVERY program they write, unless they want to.


I use flow diagrams much more when students are stuck. Flow diagrams make a great debugging tool so encourage their use in that area if your students need help.


That said, some pupils find it easier on more complex programs to draw a structure diagram first, either in its entirety or just for the bit they need to be able to visualise. Leave it up to your pupils to decide which way works for them. We know our students are all individuals and will approach the problem in their own way, so let them.


Don’t stifle their creativity, let them enjoy Python and they will become better creative thinkers and thus become better programmers.


All any programmer needs in order to be a good programmer is:

  • a grasp of the basics and

  • the imagination to apply it to different situations


Too many teachers are held back because they have failed to grasp the basics so when students “overtake them” they don’t know what to do next. They often feel scared, unsure how to help when students ask for assistance.


All you need is the grasp of a few Python rules and some simple tried and tested techniques up your sleeve and you can be a great programming teacher.


Anyone can learn how to be a good programmer and you can learn how to be a great programming teacher.


Click Here To Discover 3 Simple Tricks To Immediately Improve Your Programming Lessons Today!




342 views

Comments


Featured Posts
Recent Posts
Archive
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
  • Pinterest Social Icon
bottom of page