Earlier this year I got to meet quite a few people who I had worked with over 20 years ago. What was supposed to be a lunch meeting for people who had kept in touch, became a huge lunch party with a lot of the earlier team members, along with their family and kids.
One of my ex-colleagues reminded me about a Programming Attitude course I used to take any new member of my team through, and that they continued to use that as a means of bringing a new developer on board in their current organizations.
That conversation brought back memories of how I used to harass (ok teach!) fresh engineers, teaching them coding practices….remember that we are talking about 20 years ago.
Problem definition: Write me a cash register program. It should take the input of a number, add that to a total, and print the new total and ask for a new number. If I press enter without entering a number it should print the final total and exit.
Sounds simple enough, everybody thought they will be able to finish this in a couple of hours. For most it took a couple of weeks…the exercise took them through.
- Input validation – dealing with wrong, junk, frivolous (yes 2 decimals are all there are in most currencies.)
- Breaking up the program into functions, instead of just putting everything into main, managing multiple source files, writing headers
- Rights and duties of functions – Designing functions, making sure functions did only what they were designed to do, no more, and more importantly no less
- Reading up about API’s and functions that were available instead of just using the functions that they already knew; not creating new functions just because…
- Automated testing – Once we had a list of possible spurious entries, we could simply run ./cashregister < testinput and all future versions of the application were tested
- Code coverage – gcov was a great way to get an idea of code coverage, with a target of 95% coverage through testing
I will always remember the look on the programmer’s face, when they show me their final masterpiece which they tested, had their friends test and knew that this time Samyeer cant find a problem with this.
And I would tell them, ok DELETE the program and all the SOURCE CODE!
The final lesson was that it is the learning that counts. If you have understood the entire process and have really learned, then you can write the entire program in a couple of hours. And they did…
Honored that they remembered; and continue to use that approach on their teams.
Samyeer Metrani 