Engineers vs. Everyone Else

A lot of people imagine programmers to be this introvert in a hoodie typing fast on a keyboard in a dark room. Another prevalent stereotype seems to be that we are socially awkward and think in terms of 1s and 0s. If you ever walk into a room full of socially awkward geeks discussing something related to system design, they might seem like social butterflies. So engineers are just like everyone else. We just happen to be a bit more confident in areas that are less commonly appreciated by people.

Code vs. Everything Else

I think part of this misconception comes from how people see code. I also imagined code to be some magical keywords you type into a black screen and then you can hack into a device kind of thing before I became a software engineer. But code is like everything else. Code needs maintenance, just like cars. Code needs planning, just like cities. Code needs care, just like cats.

Code & cars

If you work as a software engineer for a year, you will learn that you rewrite much more code than you expected. There is a reason they say you need to learn how to read code first, just like non-programming languages. Reading code well will help you rewrite code efficiently. Rewriting could come from a bug, an update of dependencies, or refactoring to make the code more readable. Just like our BMWs and Jaguars, code throws us problems at the worst times, and requires upgrades to keep working. So, code needs to be fixed and retouched over and over to maintain its quality. And this is required, as code becomes rusty here and there with new library updates, unexpected user behavior, data migration, etc. So, code requires consistent care just like cars.

Code & cities

I am horrible at navigating new places. New York City was the first city I lived in where I could navigate without Google Maps. The whole city is designed like a grid and if you just know the street number and avenue(X and Y coordinates), you can navigate with ease. And behind this grid-like structure, there was good planning. One of the requirements of good code is readability. This is both on the smaller and larger scale. On the smaller scale, variables have to be named to make sense. No more of that undergrad i, j, giraffe kind of variable names. ‘NumberOfMembersWithFullDataAccess’ would be a more acceptable name. Carefully plan how you name your variables. It will save someone’s time, most likely yours. Let’s take a step back. To be able to read and understand code with ease, you need to know which part of the code to read. And this requires more than just good variable naming conventions. The whole code need to be structured in a way that makes sense. The folders, files, and functions need to be in the right place so that just like I could navigate around NYC with ease, new onboarding members of the team can make sense of where to look for the red underling highlighting an error in the code they just wrote. So, good code needs good structural design just like cities.

Code & cats

Code needs sincere care, just like cats. And I put in the word sincere there because there is a subtle but big difference between code that was written by someone who wants a promotion and code written by someone who really cares about the code they are writing. You will hear many rules about good code like file structures, variable naming, etc, but these rules are general guidelines to write good code. I am sure a first time cat owner who really cares about their cat will do a good job even if they did not have much prior knowledge about cat care. They will somehow research enough on how to build a cat tower and spoil the cat with a nice tower. It is really difficult to put into words, but imagine those films where they put in an insane amount of care that there are so many details we only realize after we watch it N times. And there are probably more details that we still miss. Great code is like that. The person put in so much care, because they actually have the will to craft something great. Good code needs care, just like cats

There are a lot of great engineers and well-written beautiful code on this planet. But if I were to make a bet where the best code, THE BEST CODE is, it would be at a fast growing start-up that is still < 50 people. This is the place where it would meet all three of the following conditions. There are great programmers. The first joiners of a startup are much more likely to have passion in the product than most other places. They are still agile enough to change tech stacks when necessary. It looks easy, but it’s horribly difficult to get all three. Big tech misses #2, elite research programs miss #3, and rest of the world misses #1. I still have a long way to go to become a good, let alone great, programmer.

Engineers vs. painters

So, code is just like anything else that requires effort to improve. These can be houses, movies, paintings, relationships, etc. The similarity is that if you put in an immense amount of effort, it shows. And people who really care about it when working on these will put in that effort. A programmer struggling in front of his dual monitor trying to choose the right variable name, the right tech stack as they write code they care about is no different from an artist striving to put that pink rosy sunset’s reflection on the water on their canvas.