Letter #2 — Novice in the jungle

Source: http://www.starwarsreport.com/2016/01/12/the-last-padawan-kanan-part-2-of-2-swbtf-192/

Dear X,

In my previous letter, I had incorrectly stated that the quarter-final event at Shashank’s place was 1992 Cricket World Cup Quarter-final. Shashank pointed out it was 1997 and I corrected the record. If this had been an actual letter, then that error would have lived for posterity (or infamy). Ah, the wonders of digital editing.

Speaking of the ability to edit, one of our labs had us entering Assembly language OP-Codes on a switch board as code. The way we completed our labs/tests were to write the OP-Codes on a piece of paper and then key it in. While doing so if we realize that we made a mistake in one or more of the previous lines, edits were cumbersome at best and impossible at worst. We had to run the restart the unit, or run the code to let execution fail; and then restart keying in the program. I still use pen+paper for a lot of logic to sketch out pseudo-code, especially some of the complex pieces.

As a developer, find a tool (early) that works for you.

During the summer of 1995, I nagged my uncle who worked in programming CNC machines to let me in and see how he worked. Punched tapes were how CNC machines were programmed then. With great hesitation, my uncle let me try my hand at punch-tape programming. If I thought op-code entry was painful then punch-tape programming was tortuous and torturous.

Put yourself in uncomfortable positions and attempt at solving seemingly intractable problems in that environment. You will be greatly appreciative of your current environment and/or available tools.

Speaking of op-codes , let me segue into something called SMAC0. For the final year of my undergraduate program, we had a textbook “An Introduction to Digital Computer Design by Prof. V. Rajaraman and T. Radhakrishnan”. Among other things, this book talks about a hypothetical computer called SMAC0 (SMAC-Zero) — an acronym for SMAll Computer 0 . SMAC0 had a limited memory and a very small instruction set —

READ Read into memory operand
PRINT Print contents of memory operand
STOP Stop of halt execution
ADD Add memory operand to register operand
SUB Subtract memory operand to register operand
MOVER Move memory operand contents to register
MOVEM Move register operand contents to memory
MULT Multiply memory operand to register operand
DIV Divide memory operand to register operand
BC Branch depending on condition
COMP Compare register & memory operand to set condition

One of our lab assignments was to build a SMAC0 simulator. To do this we needed to build an Assembler and Interpreter in C. For a Computer Science undergrad, this assignment was heaven . All students had the opportunity to put to practice thing we had learnt in theory. Things like writing a 2-Pass Compiler , Linker , and Loader . We had to write all this code on a 64K RAM computer with no Hard-Disk using a 1.2M Floppy disk. I (and a lot of others from my class) enjoyed these assignments so much that some of us geeked out . We used RAM-Disk to give the computer additional memory. Some of us went farther and used an existing Unix machine (which we had access to selectively) and used Lex and Yacc to generate SMAC0 op-codes from a C-like Language. We still had to compile the mini-C library to the very small instruction set of SMAC. Things like LOOP command needed to be translated to BC and COMP instructions. We built our own SMAC-Virtual Machine , Compiler and Interpreter on a machine with ≤ 128KB of RAM and 1.2MB Floppy disk.

Build your own mini language to get a true appreciation of what compilers/interpreters do today, that we take for granted.

For the final semester of our Master’s program we were to complete a 6 month internship at a company and come back with a detailed presentation about what we did and learnt. This was my first paid job, writing software. I got the opportunity to work for a company called Geometric Software, its current incarnation being Geometric PLM. My project advisor was Nitin Bhide. My project was to convert a text based input file for an Interior Decoration CAD/CAE Software to binary form. The software was written in Visual C++, with most of our code leveraging MFC . For our college courses, we wrote programs in Windows 3.1 SDK, with me keeping Charles Petzold’s book by my pillow at night hoping to learn the SDK via osmosis. Here, I kid about the osmosis part, but not actually keeping that book by my bedside.

Working with Visual C++ on Windows 95 was extremely exciting. The original Serializer/Deserializer of the product, was implemented to read/write files in text format. The whole object tree was stored in a text format. The list(s), tree(s) and all related object pointers were stored in text format. Nitin’s idea was to use the binary serialization/deserialization function that existed within MFC. Once we implemented that change, we got a file size saving of over 60% in many cases.

Binary trumps plain text for persistent storage and transport

We started celebrating the reduction in size and then realized that while serialization reduced size greatly, the deserialization was buggy. As we dug deeper in to the code, deep inside MFC we found that MFC does not serialize the same pointer twice. Looking into the Object graph, we realized that in were trying to serialize the complex object graph the code made multiple serialization attempts for the same pointer. We addressed this bug, but still ran into the same issue of MFC rejecting duplicate serialization attempts of the same pointer. Turns out Nitin had built a memory manager which reused allocated memory by overriding new and delete to NOT release the memory back to the OS, instead hold on to the object in a pool so that memory allocation/deallocation did not cause fragmentation. He had also written some form of garbage collector as well that I have trouble recalling details about. Nitin had done all of this around the same time James Gosling was popularizing Java, JVM, Garbage Collection, and its ilk. That code for Memory Manager was a piece of marvel that leaves me in wonder even today.

Side-effects for injected features/optimizations are inevitable

During my internship at Geometric, I had struck a friendship with 3 other interns. We had an enjoyable time writing code and going out for chai . Towards the end of our internship, the company conducted interviews with the interns to decide who gets a job. To my dismay, I did not get a job. I was shocked because I felt I did a good job, and also felt good about my interview. The rejection stung, and almost in tears I walked out to head home. As I got to my Hero Puch to head home, I ran into Nitin. He seemed surprised at my rejection as well so he went back and got me a second chance at interviewing. Unsurprisingly, I still did not get the job. It was heartening to see my adviser/mentor trust me enough to get me a second opportunity to prove myself. For a very long time, I was baffled as to why I did not get the job at Geometric. About 10 years later when I was mentoring some interns, an epiphany struck. My work ethic at my internship was not up to snuff compared to the person who got the job. This realization was painful and embarrassing at the same time, but I would have greatly appreciated this feedback instead of just saying “You are not good enough technically”.

Have a strong work ethic

Takeaways

Technical Takeaways

1. Go deep:
   - With all the available frameworks/IDEs combined with need for instant gratification/MVP-Urgency, it becomes easy to accumulate blind spots to your understanding of technology
   - If you are a NodeJS/Java/Python developer, build a compiler/interpreter of your own. It does not need to be exhaustive, but the sheer thrill you get when you build one, is worth it. You’d understand the need for appropriate data structures and also come to deeply appreciate all the optimizations that the interpreter/compiler does for you implicitly
2. Work in a constrained environment:
   - Learn to use vi.IDEs are great, but vi is greater, and is almost ubiquitous while being light-weight on resource consumption. vi today is very sophisticated and provides some excellent language specific features.
   -Memory and hard disk are not infinite. This may not seem true today with abundance of memory/disk available in cloud environments and advanced hardware. But learn to build software with limited resources.
   - Pick up an Arduino or a Raspberry Pi Zero to see what a truly resource constrained environment would look like in today’s tech world. Things like multi-threading or multi-core, that we take for granted are limited/non-existent in these environments
   - Build a SMAC0 computer and define your own DSL to translate the code to run in a SMAC0 simulator.

Leadership Takeaways

1. Work Ethic: Doesn’t matter if it is your 1'st job or your 10'th job, have a strong work ethic. It doesn’t matter if you feel you are underpaid or unappreciated, if you feel you are being treated unfairly, quit. But never do a half-assed job while you have one. You owe it to yourself, your teammates, and to your company to do the best you can.
2. Ask for feedback: Rejections from interviews hurt, especially when you felt you did a good job in the interview. Do not be shy about reaching out to the recruiter or to someone from the interview panel asking for feedback on what you could do better. You may not get a timely response, or may not even get one. But if you do get feedback, it is invaluable and store it for posterity.