Lessons
It is fair to assume that having spent almost half a century working with computers that a computer scientist like me would have learned a few lessons along the way. Could I list them all? I wish. (There might be a book in it if I could!) Could I even remember them all? Definitely not, and I’m not sure I would want to. As I mentioned previously, I’ve been involved in a lot of technical transitions but much of my early experiences of the world of computers would now be considered historical curiosities. I learned not to touch certain parts of the innards of my CRT oscilloscope but that lesson has almost no relevance today. Leaving a few unused bytes beyond the end of routines to allow for easy patching was a lesson that was relevant for me in the early 80s, but the last time someone paid me to do a low-level fix needing spare bytes was probably ’84 or ’85 and the last time I ever did any low-level code whatsoever was probably three years later. After that, everything I did involved high-level languages. Why spend time in assembly when a C compiler will produced something as good, possibly better?
Without a doubt, most of the tech lessons I picked up along the way are now practically useless to me. In a way it feels like my head is jammed full of useless information. That’s a lot of years to spend with nothing to show.
On the other hand, I look at current developments, practices, advances and the myriad products of our technological world and realise that at a more abstract level most lessons remain relevant.
Take my oscilloscope lesson. I learned that one the hard way while trying to adjust the sweep control using an uninsulated long-shaft screwdriver. The real lesson, however, is to explore the risks in advance and take appropriate precautions. Another lesson from that experience is that knowledge alone isn’t enough. I knew about the high voltages, but I was focussed on a separate part of the circuitry and so put the nearby exposed danger out of my mind. I was touching the screwdriver shaft to steady it while adjusting something (can’t remember exactly what, a potentiometer perhaps?) when it tipped against the tube circuit. Bam! That certainly got my attention. A few kV will do that to you.
In the spirit of looking back (which is what I have been doing lately), what other high-level lessons have I learned over the decades? I have a few favourites. There’s no point in trying to put these into chronological order as many of these were learned over a long period of time and I cannot possibly remember when the lesson started. So here goes, in no particular order:
Document everything
This may seem obvious. In fact, most of the best lessons seem obvious when you look back, but were not so obvious at the time. One of the things that I discovered about myself early on is that I have a terrible memory. Or, as I like to explain to people, I have a terrible lookup system in my brain. It’s like a library that has lost its Dewey cards, or a book that has lost the index at the back. I will remember things, but first I need some clue, some hook, to get the memory back. To overcome this lookup problem I would make short notes for myself, enough to trigger the memories, but over time, having learned that I don’t know how detailed the notes needed to be, I started to take copious notes. To my surprise I found that I got a lot of pleasure from documenting things. Many, many times over the years my documentation has been key to solving problems, avoiding repetition of past mistakes and the means of educating others. Write it all down, explaining to yourself as if you’d never encountered this before. Where do you start, what are the steps, why are you doing it, what are the danger signs, how do you know you are finished… all the questions that pop into your head the first time around, get them down onto paper so that the next time around you will have the answer right there in front of you.
Another benefit of documenting everything contemporaneously is that it makes you pause to think. Imagine if I had been documenting my efforts to repair my oscilloscope; the danger of the proximity of the exposed high-voltage connectors would have been writ large, and the lesson would have been more theoretical than theatrical.
Knowing the immense benefits of good documentation it really annoys me to see the poor (or missing!) documentation of today’s technology. Indeed, some of the documentation has become a minimalist art form. Think “IKEA build instructions” or “Apple setup guides“. OK, I admit they may be suitable for a lot of people, but there is no next level of documentation in many cases. If you get stuck, your next line of support is to try to speak to a customer support person, or a bot pretending to be a person. I honestly can’t imagine any of those would be helpful.
Speed is not the only metric
During my undergraduate years it was often the case that my contemporaries would boast about their solutions being the fastest. Some problem had been posed (often by a lecturer but we’d create problems of our own too) and there would be an informal competition to come up with the best solution. The measure of success in almost every case was the time taken to solve the problem. Performance equals speed.
The kinds of problems that I eventually found myself working on presented additional challenges. Embedded systems, for example, would have a scarcity of resources, memory in particular. If I needed a solution to work in my embedded system I would not only have to consider performance in terms of speed, but also in the amount of space it occupied. Did I really need the speed? A solution that decoded the data in twice the time but half the memory might still get the job done, but the benefit of the smaller footprint far outweighed the completion time because the saved space allowed other functions to be present. Over the years I’ve found that many metrics can be applied, according to the needs and constraints of the problem at hand. Among these are the following:
- Speed. Or “time to completion”. This is the obvious one that I include here to get the ball rolling.
- Space. How much space does the solution occupy. If you had a choice of sacrificing speed for space, would that be a good idea for the problem you are solving? Always worth asking the question.
- Accuracy. Do you really need a solution that gives you a result to 100 decimal places? Maybe you only need two decimal places, in which case there might be better alternative solutions.
- Understandablility. I invented that word, but you know what I mean. If the solution you have devised is going to be given to someone else, or needs to be maintained by other people in the future, could you sacrifice some of the other performance metrics (speed etc.) to make your solution easier to understand?
- Accountability. If your solution presents an answer, can you explain why the answer is correct? A solution that relies on some magical incantations, or merely on weights from repeated pattern matching on specific samples, then it doesn’t have the necessary characteristic of accountability even if it appears to offer correct solutions. If proof is needed then all other performance metrics are irrelevant.
- Portability. Another way of measuring the success of a solution is how well it can be re-implemented in other contexts. That may mean in different programming languages, different hardware architectures, different user environments etc. A solution that relies on specific features/quirks of a runtime environment may be sacrificing portability in favour of speed, space etc.
The overall lesson here is to properly understand the metrics of success. In general that depends on your objectives and the constraints within which you have to devise a solution.
Take a break
I don’t know why (I have theories) but if you’ve been focussed on a problem for a very long time without finding a solution, put it aside for a while. Somewhere in the back of your mind things will come together and when you next approach the problem you may find that the solution is right there in front of you.
For as long as I can remember I have always problem-solved while sleeping. Like many others in the tech space I have worked through the night, sometimes alone, sometimes with a team, but the real overnight problem-solving seems to happen while asleep. There is nothing more satisfying than gradually coming back to consciousness after a night’s sleep to the realisation that you have a solution to the problem. A solution that is so unlike what you previously thought would be the solution that it seems like the real solution is supernatural. It’s not. It’s just you thinking differently.
There’s more to coding than syntax
I can code in dozens of programming languages, a consequence of having many, many years to learn them all. Nevertheless, being able to construct a syntactically correct sequence in a programming language does not necessarily mean you are coding in that particular language. I’ve encountered programs written in C++ that were obviously written as if they were C, PHP that looks like Perl, C# and JavaScript in the style of Java. Instead of the many different syntaxes it is better to pay attention to the language types, such as Object Oriented, Functional, Procedural and Declarative. Most of the programming languages can be shoe-horned into doing most of these different styles of programming, though obviously excel at certain particular approaches. C++ is intended to be Object Oriented, but contains much of the elements needed for procedural programming. JavaScript (or any of its variants including ECMAScript) can handle pretty much any style of coding and is inherently a prototype-based OO language with exceptional support for Functional styles, but the syntax (curly braces and all) provide a comfortable environment for C/C++/Java coders. This “comfort” can unfortunately lead them to writing with JS in the style of their preferred language. Is this good or bad? Hard to tell. It could lead them to concentrating only on the characteristics that are familiar from their previous language (e.g. inheritance in C++) and miss the opportunities offered by the new language (e.g. prototypes in JS).
Categorised as: LUE