Getting Started With C++
and fundamental ways of thinking about life
There are many reasons to learn C++. With so many other popular languages like Python, JavaScript, Java, Go and many others I chose not to name. It may seem antiquated to learn C++. There are definitely benefits though, and I believe they outweigh the disadvantages.
See, the moment I started seriously learning C++ is the moment I truly learned maintainable coding. Before then I would always write and re-write code many times for a single task. As an informal programmer, I rarely got the professional feedback I needed to write. And I never thought this was an issue because my iteration time was quick. I mean blazing fast. I optimized for short-term speed. I could bang out a custom web service, design and code an embedded system or prototype a mobile app overnight if I wanted to (with a couple of red-bulls).
Unfortunately, this limited the coding team to me as I didn’t have a structured way of thinking that was translatable to English. Thought turned to code, there was no intermediary. I wasn’t following any sets of standards or conventions. Unfortunately, just a week later I’d look at my code, bamboozled at what I had concocted. The number of re-writes that occurred in the time period I wasn’t following convention was too numerous and too embarrassing to mention (I honestly just lost count a while back).
Writing C++ was the first time I was forced to think about form. It wasn’t because other languages didn’t have conventions, they did, I was never subject to following them. Additionally, I had instilled in myself that speed was the only thing that mattered nothing else. See startups were my interest and they thrived or died based on speed. Naturally following conventions and form seemed antiquated, slow to me.
But raw speed has an upper limit.
Usain Bolt has to be in the top 5 of the things that come to mind in any list of speed. When he blew the competition away in 2008 in both the 100m and 200m dashes and jogged across the finish line, he shocked spectators around the world. It was too easy for him. But, you would be mistaken to think that he has the ideal running form.
See, when sprinters run they expend energy through their muscles. But, they only want to expend enough energy vertically to keep themselves upright, all other energy should go into accelerating themselves in one direction: Forward. Any superfluous motion side to side or vertically is a waste of energy. When you see Bolt running, you can clearly see a side to side rocking motion. So as fast as Usain Bolt was, he actually could have been faster.
In the same way that form dictates running speed, it dictates coding speed. There’s a larger multiplier in that in code maintaining form helps decrease the mental overhead of future work. If you follow a system and process you won’t have to question what it is you intended to communicate. The best code is the most boring. Overly engineered and complex solutions can have unintended side-effects slowing down development in the future. This sort of technical “debt” can kill any software development project even entire startups.
For me, it meant that I had to slow down to learn the form first. It’s like a choreographed martial artist or a pianist. They learn the moves and fingerings super slow and progressively speed them up until it becomes jaw-droppingly fast.
But slowing down to me felt wrong. It felt like I was giving up, though, this was hardly the case. I was literally forced to learn the form and I resisted it with every fiber in my body. It felt unnatural, but I have to thank my mentor Nick for pushing me forward and never just saying “fuck it, it’s good enough.” Perfectionism was the standard and it had to be. If it wasn’t sushi would never taste as good as it does (some sushi chefs spend 5 years learning how to make the perfect rice, talk about slowing down). And this was the most important lesson of all:
Sometimes you have to go slow to go fast
But the question still remains, which process, what form should one follow when pertaining to coding? Luckily the C++ community, as do many other language libraries, has standards or style guides. Here’s a popular one that’s put out by Google:
The idea goes that if a number of people follow the same style guide then it shouldn’t really matter who is working on the codebase. Readability is increased, and code handoffs become much easier. Scaling the codebase is a simple matter of adding engineers who are trained in the same style guide and software design patterns. If we all use the same patterns and the same style for writing code, then we’re effectively speaking the same language. This slight overhead for each individual pays off exponentially as more engineers are added to the project.
Another argument for learning C++ is that over the coming decades, codebases are only going to get more complex. A lot of this “infrastructure” code is written in C++. And unless some major breakthroughs in AI and ML occur (which I suspect probably will eventually), humans will still be the ones maintaining this infrastructure code for some time (until the machines take over). If you want job security at a big tech company, C++ is a good bet to learn (though I could really care less, just an unintended side-effect).
Now to what really matters. C++ isn’t a language known for its speed. Well, technically it’s known for its the speed of executing code but not speed of writing it. And in a startup, you might not be able to afford writing C++ initially. You need to reach product-market fit as quickly as possible and everything else is the icing on the top (though cake without icing isn’t really that good). But the consequences of learning C++, software design, and style guides are what really make it worth the whole journey.
I think about code differently now. Even when I’m coding web-services in Go or NodeJS I apply similar coding principles. Everything is more readable, tested, documented and maintainable. It’s like cooking. When you’ve got a great foundation, you can make anything taste good.
And a lot but not all of us in the startup and hacker communities lack the requisite discipline to grow something past a prototype. We believe that technical “debt” is a term created by pretentious “corporate” engineers who are there to peddle their feudalistic ways. That system and design patterns were created to oppress creativity. Trust me I was one of the naysayers. I thought that I knew better. But I’ve been converted.
See maintaining form doesn’t mean a lack of creativity. It just means that I don’t have to mix my paint every time I decide to mark my canvas.
