My first car was a Mazda 323. Once I got it, I kept seeing 323’s all over the place although I had barely noticed them before. I still make notice whenever I see one and thats the way our brains work, we keep noticing things we can relate to. The same goes for programming. Once you’ve seen the solution to a particular problem, you immediately recognize that structure whenever you see it. Or if you spot a bug, you will easily spot similar bugs in the future.
Recently, Karin Hellqvist and I went to Berlin for the 2016 European Certified LabVIEW Architect Summit. This is a yearly conference where all sorts of aspects relating to system development with LabVIEW are discussed among some of the brightest minds within the LabVIEW community. During a few minutes of these three days packed with information, Nancy Jones of National Instruments talked about how she needed a scripting tool to detect a common bug. The bug is not conspicuous and easy enough to make, and it took me a few seconds before I realized what was wrong when Nancy showed it.
Less than a week later I’m going through some code in one of our projects. Deep down the code I spot the same bug. It pops out and hits me in the eyes. My brain was not set in code review mode, and I would certainly not have spotted this if I hadn’t seen it before. It strikes me that this is the case for most things we handle in our daily work as developers. Spotting race conditions used to be tricky, a few years down the road you’ve come to the point where you just get the feeling “it looks like there might be a race condition here”. Unnecessary memory allocations, starvation loops, system design choices, these things once gave me headaches. After many years of implementing test, measurement and control systems in LabVIEW the challenges have moved from solving issues relating to the implementation of a system to the process of getting accurate specifications, foreseeing future changes and evaluating which solutions and hardware will be best for accomplishing the tasks.
Now that, I guess, is by definition experience. What’s interesting is that it does not necessarily need to be your own experience. As in the case with recognizing the bug Nancy was chasing, experience can just as well come from listening to what problems other people are facing and how they tackle them.
For LabVIEW developers, the CLA summit is an extraordinary chance of getting loads of experience right down your pocket in just a few days. The fact that you have to reach architect level of certification to get there makes all sessions very interesting as the presenters can expect a high level of understanding from their audience.
For further reading about the 2016 European CLA summit there are already a couple of blog posts I’d like to recommend (please add more in the comments if you find them):
Oh, and the bug Nancy talked about. The for loop will not execute if the arrays are empty, making us loose any previous errors on the error wire. Obvious once you’ve seen it but easily missed if you’re not careful.