In 1997, I was an apprentice engineer in a Tire company in India after finishing my degree in mechanical engineering . One evening, a machine broke down in the line and I quickly figured out that it’s just a broken spindle that needs to be replaced . I did some quick calculations and figured a 10.2 mm diameter is what the replacement should have . I could see the confusion in the eyes of everyone around me . Someone quietly went to the store and got the replacement and work progressed . The next day – my boss took me back to the machine , and showed me there was a panel with clear instructions there on parts – and the standard size replacement was 10mm . There is no such thing as a 10.2mm . He was sympathetic – he coached me that 90% of the time , you don’t need to worry about actual calculations and have to just follow the manual . He never gave me an example of the 10% when I will need to know the calculations 🙂
The next episode happened in Colorado in 2000 . I was a young programmer struggling with a massive old C program that started misbehaving after I added some functionality needed for my project . I didn’t change any existing code – and my code would compile without error and execute when I did it as a stand alone program. I went to the team leader – a long time veteran of HP-UX and probably the best programmer I have seen in my life . He casually asked me “Anything odd with the assembler code?” . I am not a CS major – and while I thought I was a really good programmer in C and a few higher level languages , I didn’t have the faintest idea on how a compiler actually worked or even how to read assembler code . Well, I was given a 30 mins tutorial and a manual for instruction set architecture . I struggled for weeks and eventually figured out what was wrong . I will spare you the details – but I walked away thinking that all mission critical code should be compiled without Optimisations turned on . I also learned to my horror that compilers can actually have bugs . Till today I don’t know if the compiler I used had an issue – but to be honest , I have never felt confident enough to blame a compiler even once when my code fails .
I wrote my first BASIC program in 1986 and first C program in 1989 . Till this episode in Colorado in 2000, I had never thought about the need for understanding what happens at a level below (N-1) what I needed to learn for everyday use . And in general I would say I had spent more thought on higher level abstractions (N+1) from where I am operating from .
My father was a very talented mechanical engineer . He used to tell me when I was in college that an engineer’s job is to make sure that whoever used the output of an engineer’s creation should be able to take it for granted – a lamp should switch on , a car should run when ignition is turned on and so on – without the operator knowing how it happens . And when it doesn’t work – most of the time the operator should know what’s wrong , and quickly decide if it needs expert help . By his definition – I wonder if he would have agreed that software is a real engineering discipline 🙂
If the episode in 2000 with Assembler had not happened – I doubt I would have developed an interest in N-1 thinking as my learning philosophy at all . It did help me quite a bit as moved into more business leadership roles later in my career . As I wrote recently about scaling a business , the ability to go to N-1 is critical when rethinking the building blocks . Otherwise we routinely get stuck in status quo and at best some incremental progress . Equally important is the fact that the moment you have solved things at N-1 , you need to zoom out to N+1 to pick up speed .
Keeps life interesting , doesn’t it ?
And Vijay Says... 