Some 20 years ago, I wrote my first line of C code. Here is my journey and how it made me develop as a software engineer.
Constrains are a good thing
We live in a time where information is at our fingertips. We carry a mini-computer in our pockets which is much more powerful than ever. Yet, we are bombarded with so many distractions that we barely take advantage of this miraculous progress.
When I was about 12 years old, my mother bought us a ‘computer’ game similar to the one in the picture above, except it was much worse. The keys were made of this bad plastic, and they would get stuck all the time. If I wanted to do something remotely productive, I had to have a screwdriver next to me to unblock them. We used it as a typical game console for a few years, but soon after I started high school and was introduced to programming, I went back to it and had a eureka moment. The main disk that came with the game had a BASIC interpreter on it! Holy shit!
I was already a bit into my second semester, and my physics teacher, “domnul Ancuța,” was already my mentor and a father figure (that’s what happens when you don’t have one around; you take what you can elsewhere). We had the most ridiculous conversation ever. I was trying to describe my game and the BASIC interpreter, and he was convinced that I actually had a Commodore 64 machine. We went back and forth for quite a bit until I gave up and said something like, “Okay, let’s say I have a Commodore. Do you have some books to help me learn BASIC?” He definitely had! He gave me three books, one with QBasic and two more with some other dialects.
They were very old books from the communist times, with yellow (more like brown) pages and a “weird” language. But I was happy to have some free resources to learn from. I went home and started to try all kinds of commands to see what works and what doesn’t. I had one huge limitation, though (apart from the shitty keyboard): there was no file system, so I couldn’t save my work. Instead, I had to write it down in a notebook and, in the next session, I had to type it all from scratch. My brother Remus told me that I was nuts, I prefer to call it passion.
Computer Science 101 usually starts with very basic concepts (no pun intended), such as variables, constants, and flow control instructions. They exist in most programming languages, so I could apply them both in BASIC at home and in C at school. The homework we were getting was pretty simple as well: say if a number is a palindrome, calculate the sum of a number’s digits, calculate the nth Fibonacci number, etc. I would write the solution in pseudocode and then translate it to BASIC to verify it on my little machine. Once everything worked, I would translate it by hand into C, on paper. I made sure that I always went to the lab early so I could get the chance to type it in and fix any syntax errors that I had made. I was constrained, but it made me grow up in a “bilingual house”.
Add (good) comments to your code
Just after I turned 17, we finally could afford to have our own PC that I would share with my brother Remus. Like any youngsters that had just gotten their hands on a powerful machine (it was a Pentium 4, quite performant for its time), we were playing games like crazy, and apart from my homework, I wasn’t doing much programming on it. Oh well, just a few months later, the graphics card went bananas. My immediate thought was that God had punished me for playing too many games and not doing something more productive with the PC. I mean, it was the graphics card that failed, something that I considered a clear sign of punishment.
After we finally got the money to buy a new graphics card, I went back to domnul Ancuța and asked for a copy of Macromedia Flash. He gave me Macromedia Flash 6 on a CD with a bunch of other things. Here I was with a new toy. I went to the library and got a book about ActionScript 2.0 and started devouring it. I loved how simple it was to make animations and control them from code. I was easily getting better at using the Help documentation instead of relying on the book. The first programs that I created were pretty basic. It was all about learning the language.
The summer break came around, and I finally decided to write something a bit more complex. I ended up choosing to write a simple tic-tac-toe game with both single player and two players. For the single player, I didn’t go for random moves but instead coded the player logic as well as I could. This resulted in the game having around 700 lines of code, without a single comment, because why not? Of course, that didn’t go so well! After a few months, I returned to the game to make some improvements, but I couldn’t understand much of it. I have a pretty bad memory, and sufficient time had passed to erase everything from my head. I tried to make sense of it, but I just realized that it was much easier to write it from scratch, this time with code comments. They were pretty simple (at times silly) comments, but they were enough to guide me around. I put them to the test when I returned for a 3rd version of the game.
Understand your limitations and find ways to overcome them
Talking about bad memory, one of my favorite quotes is “Use your brain like a CPU, not like a hard drive.” Even if I wanted to use it as a storage device, I wouldn’t be very successful. I struggled quite a bit in school to memorize poetry or almost any kind of information that I just had to take in. Maybe that’s why I was only good at maths, physics, chemistry, and computer science.
The biggest influence that my brother Remus had on me (apart from his amazing taste in music) is that he got me into Kung Fu. We’ve practiced a combination of Choy Lee Fut, Tai Chi, street fighting, and full contact fighting. We got to experience both the traditional side of it (different positions and forms), and the practical side of it, which included fighting each other in the ring. The combination of those styles has definitely helped me to develop a sense of self-awareness that I wasn’t having before. It helped me spot my strengths and weaknesses both physically and mentally.
Back in 2009, I joined Continental for a position that nowadays you’d call a QA Automation Engineer. I was part of their “Interior Body and Security” department, and my task was to automate their end-to-end tests using an XML file containing the car configuration. I would use XSLT to generate thousands of test-cases based on that input configuration and then feed those files into the testing system.
I had a huge problem, though. I would come back on Monday to work and wonder what I was up to the Friday before. Part of it was my poor skills at naming things, part of it was the lack of good comments, and part of it was my poor memory. After a couple of failed Mondays where I would need 30 to 60 minutes to remember everything that I had in mind the week before, I started keeping a journal. On Fridays, I would write down a little summary of what I’d been doing and any improvements that I wanted to bring to the templates, and then on the next Monday, I would just read it and resume from where I left. It was almost like suspending a VM in VirtualBox and then resuming it back the week after. It worked very well and helped me get those 30-60 minutes back.
This marks the end of the first part of this series. In the second part, I have covered my experience entering the workforce as a professional programmer.