It was 1981 - a time when there were no mobile phones; no email.
I had passed out from I.I.Sc. Bangalore and joined Tata Burroughs in Mumbai. Burroughs was one of the early mainframe computer makers in the US and Tatas had a tie-up.
Along with 20 other engineers, I had been posted to work in the Tata Steel Plant in Jamshedpur. Their EDP department was one of the early customers for the Burroughs Mainframe.
The computer sat majestically in surgical isolation. Each hard-disk was the size of a front-loading washing machine, with a capacity of 1 Mb. A row of work terminals lined the outside. You had to remove your shoes before working here.
I was there to develop the needed software. We developers had to work at night only because daytime was for regular EDP work.
I had been struggling for the last 3 nights. I had to port a program written in BASIC to the mainframe. It has to be written afresh in COBOL. But that is not my problem.
To make the code run fast, it should not block the whole database table when it updates. The programmer had to issue transaction control code, right there within the business logic.
The business logic worked fine. The transaction code was not working despite my best efforts. To make matters worse, the computer crashed every time the program ran. It took an hour to restart the mainframe.
Last night I sent a Telex to Burroughs in the US and their reply was back today. ‘Send us the Hex Dump after the crash’. I mulled over what to do.
Time was of the essence. Sent by air, the tape would take at least a week to reach Burroughs in the US. Resolution would be 2 weeks away. I did not have that much time.
In desperation, I picked up the heavy 3-ring binder - the operation manual - and headed out to the all-night cafeteria. The plant worked 24 hours and easy access to midnight Chai was a blessing.
2 Chai’s later - As I continued to look at the documentation for transaction control, I realized a funny thing.
I was supposed to declare two separate objects for “Begin-Transaction” and “End-Transaction” for the program to compile, but then, while ending the transaction, I must only use the “Begin-Transaction” object. The “End-Transaction” object was there only naam ke vaste.
This was unintuitive at its charitable best, but as the systems programmers back in the US would say, “RTFM (Read The F* Manual)”.
Long story short, I changed the code as the manual demanded and wow! – Everything worked.
- - -
It is easy enough being a civil engineer. You learnt structural engineering and rules of structural engineering stay constant.
This changed when computers came. Change the API and the rules for coding change. The API is only as good as what the programmer writes it to be. Therefore, the manual is the new Bible. It must be religiously read. This is a tussle that has continued for 40 years now - between those who read the manual early and those who read it to repent. Some things never change. Including the fact that you must know the rules of the game before you can play it. Familiarize yourself with these and you will do well.
- - -
Here are 5 doable actions that remove constraints to reading the documentation:
Change the modes of input - You can listen instead of reading. You can watch (YouTube, Coursera) too.
Tap non-documentation sources of expertise - Speak to friends, Experts. Tinker, Run an Experiment.
Sleep on it. When you go to sleep with an unresolved problem, the subconscious continues to work on it. Maybe that is how Sivaguru realized that the manual was his friend.
Learn together in a small group or with a buddy. Divide up tasks, later teach each other.
Reward yourself for doing the right thing. Allow yourself to go home early and read the documentation from the recliner.