Oct 12 2008
Programming as a tool
This post may be more a note to self than anything else, but it’s stuff to keep in mind.
It was inspired by a slashdot post: “How should I teach a basic programming course?” and I completely agree with the basic premise put forth by various commenters, which is, programming is essentially breaking down a process that you understand into steps that are understood by a computer. Only then do (or should) you begin writing the code that does this process. Starting with an example, like asking students to explain to you step by step, how to make a pb&j sandwich, is a great way to introduce this plodding, step-by-step thinking. Overlay that with a computer’s “shortcuts”, such as being able to repeat the same step over and over (again, an example was given on how to brush your teeth) as well as little frills with logic statements (what if you have multiple kinds of jelly? or children’s versus adult’s teeth?) and that’s programming. In that first step - outlining the process - you would use something like pseudocode - aka, not what you’d type into a program but what the process should look like. Example for pb&j, maybe, would include knowing the answers to these kinds of questions (in no particular step-based order yet):
- How many sandwiches do you want to make?
- Do you have different kinds of bread? what kinds of bread do you want to choose from?
- Creamy or crunchy?
- Grape or strawberry jelly?
- Lots more jelly, or lots of peanut butter?
- Do you have the ingredients in stock?
There’s zillions of other questions, too, of course - you have to limit your questions generally both from a sanity and a time perspective. Sometimes you need really complete answers to all factors of a process (think SpaceX projects for getting rockets into earth’s orbit). Sometimes you just need answers for a limited subet (I only really make pb&j sandwiches here, rather than a whole deli, and I have a finite number of jams and breads). The order in which you do things, of course, is important. You can’t make sandwiches until you know how many you have to make, or what’s in them, or what-not. So, a pseudo-code structure (which includes ordering your steps) for a few of the questions above may be:
- Ask: how many sandwiches?
- Figure out what ingredients you need (a variety of ways - or algorithms - for determining this may work)
- How many are wheat or white?
- For each set of sandwiches (broken down by type of bread):
- Which ones have crunchy peanut butter? (you can guess the remainder would have to be creamy if there are only two options)
- For each set of sandwiches within the bread type (broken down by type of pb):
- Which ones have grape jelly? (again guessing the remainder would have to be strawberry if there are only two options)
- Show summary of sandwiches to make
- Is anything incorrect? Go back and repeat the steps above in some format, then come back and show summary.
- Calculating cost
- Either in another data/spreadsheet file, have the costs for loaves of bread, etc. and calculate out, using something like how many sandwiches can be made from a loaf of bread, number spreadable from a 16-oz jar of pb, etc., or enter this at this time
- Show cost - end
And that was just making sandwiches! And there are totally inefficiencies in the code itself that you could write in or out of it, based on this pseudocode and the real code. For example, asking these same steps in a less-optimal order, or asking for both grape and strawberry even though you can calculate the other if you have one. Programming tends to be a lot about a little math - subtracting and adding. If you can keep that straight, you’ll do fine.
Of course, the using a hammer for a screwdriver’s job may apply here, too - if you only need to make sandwiches once, working out a program (which is what this has become) is way overkill. Or if you have the choice between typing it into a shell (think old MS-DOS command line) or having a pretty form on a webpage that dynamically adjusts as you fill it out - both of which use code - the latter is probably far more friendly, particularly if you have to do a lot of adjusting of values rather than a one-time entry of data for each sandwich batch. And this is where thinking beyond just those mechanics and pseudo-code and real code becomes really important if you want this program to be used by anyone, even yourself, without pulling out your hair.
So, enough about programming basics and onto programming and health…
From a programming standpoint, coding for data analysis and presentation/manipulation is pretty trivial. Random thought: I wonder if people who do, say, public health stuff would be interested in learning practical (and generally quite easy) programming for presenting their data in a way that is more intuitive and easy to manipulate? An extension, perhaps of the idea that gapminder/trendalyzer does. Data in general is more a state of mind with a dash of understanding what computers could do - and rather than doing it myself I’d be happy to pawn it off on others. See the examples where now I’m developing a training/collaborative calendar bit of work for NGOs here with full Mongolian Cyrillic support, or an upcoming project where it’ll generate more targeted petition-style emails with extensions possible with user-submitted talking points. Without those other bits mentioned - what you’re planning to do with it, the hammer versus the screwdriver - the coding’s pretty useless.
