As a long-time programming hobbyist, I have thought that an ability to code well would be quite helpful for my “day job” as an ergonomics/human factors academic – whether in experimental design, data collection and analysis, or the creation of teaching resources. But, while I have tried to learn a few different languages, I have not yet mastered any of them.
Those who, like me, want to progress from a basic knowledge of coding to more substantive skills in this area are often advised to choose a programming project to motivate their development. That is how, a few years ago, I found myself trying to recreate a simulation of memory retrieval that was described in a widely-cited monograph on human error . The simulation was originally written in Prolog, but had not been published. Using some very rudimentary knowledge of C, I managed to implement part of the simulation, but eventually ran out of inspiration to complete it.
Fast forward to the 2022 Research Software Camp, which brought the opportunity to receive mentoring on this project from a Research Software Engineer.
With the help of my mentor, I have been going back over the previously written code and working it up into a functioning program. Along the way, my mentor has provided me with valuable advice about good coding practice: how to design a program in the first place; how to ensure the code is efficient, reliable, and readable; how to test and debug code; and why it’s a good idea to become acquainted with code libraries. He has also shared his wisdom about the planning and management of a coding project, such as the things that need to be factored into any estimate of the time required. These insights will be helpful if I ever end up doing something that is larger in scale in the future!
Lessons learned and next steps
So, what are my takeaways from this experience? One is that it pays to plan out your project in high-level terms. What would you like it to do, and how will you make sure that the code does what you need it to? Pseudocode and data flow diagrams (both of which I had vague memories of from A-level Computing) are quite useful exercises here. But another point to consider is that coding is an art as well as a science. Implementing your code – creating the functions, data structures, and algorithms that make it up – presents you with a few choices and trade-offs. Do you want your code to be easy to understand? To be easy to modify? To read nicely? To run efficiently? Or just to work? Do you want to do it all your own way or reuse code that others have already created for the same task? What can you do given the time and resources that you have?
One further thing to note: for a few reasons (amongst others, because it was what I had used to start the project) I wrote the program in C. I found this a good learning experience, given that C works at a slightly lower level than more modern languages such as Java and Python, and so gives you an insight into what is happening behind the scenes of those languages. However, it also showed me why I should probably consider something else as a “daily driver”; those other languages take on some important computational work that you would have to sort out yourself if using C. While it might be necessary to do that for certain applications (or just plain fun for those who like that sort of challenge), it incurs a cost in terms of the effort required to get the program working correctly. For the kind of coding projects that I envisage doing, a higher-level language would likely get the job done more efficiently, while C libraries can be borrowed or created when there is a need for them.
So, next on the agenda is to refine my version of the simulation, and then see whether it provides any useful insights for my own research. Whether or not it does, I can take the learning experience into other projects that need a program to be written. My longer-term learning objective is to learn more about other coding topics and languages, such as Python.
Finally, many thanks to my mentor, Bernard Ogden of The National Archives, for his patience and enthusiasm, and being so generous with his own knowledge.
Reason J. Human Error. Cambridge University Press, Cambridge, 1990.