Software engineering… Nowadays, it’s everybody’s dream. It has become such a desired career option due to high salaries and the benefits of big tech companies as excited by the Youtubers, such as free food, napping areas, and game rooms. But is it really that good?
While I’m writing this article, FIFA 2022 World Cup is being played, and most people are watching. There are lots of famous players like Messi, Ronaldo, Mbappe, etc. When we see such good players who are fun to watch, we want to be like them, and the salaries of those players are pretty impressive. Similarly, we can talk about the same thing in every sports field, like NBA, tennis, etc.
These premier-league players are top of the top, like Jeff Dean or Linus Torvalds of software engineering. Other premier-league players are paid a little bit less, but enough to say their salaries are good as well. For instance, in the UK, the wages of football players playing in the Premier League are around £60,000 weekly. Hence, they are getting 3 million pounds annually on average.
Generally, when we research such a topic, we look at the top 20% like this. However, what about other leagues in the UK? I will give you the statistics without further ado: League 1 players have an average salary of £88–130k, and League 2 players have an average wage of £65–78k. If you noticed, the salaries from Premiere League to League 2 decreased 38 times.
At this point, the most crucial question is this: Why are the premier-league players earning more? Because we’re watching them more. We enjoy watching those people more than watching the ones in lower leagues because they are not playing a loser’s game.
At this point, I need to explain what a loser’s game is. Charles Ellis defines it. An excellent explanation of this concept is this: Professional tennis is a winner’s game because players try to earn points with well-designed strategies and tactics. On the other hand, in amateur tennis, the main idea is different; they try to keep the ball alive and let the opponent beat himself by making a mistake. This is a loser’s game.
We enjoy watching the higher leagues because they’re using good strategies to score. However, in more amateur levels, you can see players are looking for the opponent team to make a mistake. Hence, since we love watching them more, the higher league players are getting more sponsorships and deals and, consequently, making more money.
We’ve talked too much about sports. Let’s get back to software engineering. Similar to salaries in football, the highest software engineer salaries may go up to 8–10 million $ while to lowest is like 60k$. On the other hand, if you decide to aim higher, you can become a CEO of such a company and earn more, up to 40–60 million. The difference is enormous because software engineering is also a loser’s game, similar to sports fields.
How is it a loser’s game? Why the salary differs that much concerning your level? It is because, at the highest levels, people are working on things that might change the future. For instance, let’s consider Jeff Dean. He invented a programming model called MapReduce for processing big datasets with parallel, distributed algorithms on clusters. He also worked on the foundation of Tensorflow and conducted research with Geoffrey Hinton — the father of deep learning. I’m not even talking about Linus Torvalds, who created both Git and Linux. These are the highest levels. They’re playing the winner’s game.
On the other hand, in the lower levels, we’re implementing new basic features to the software belonging to a company, which neither changes the future significantly nor increases the revenue of the company that much. However, we all want to have behaved like the ones at high levels, although we don’t deserve it by what we do. Then the question is, how can we shoot for the moon and deserve it?
Code Only if its Absolutely Necessary
When I started my career in a startup, I was very energetic to write a piece of code. In fact, sometimes I wanted to develop my own software to perform an operation even if existing software is doing the same thing. Today, I see the same behavior in all freshman software engineers.
Most investors like investing in software companies because the initial cost of founding one is meager, yet the positive revenue potential is outstanding. However, in 2000, there was a .com bubble. Do you know why it happened? Of course, there are lots of them, but one of the reasons was that the companies didn’t see the maintenance cost of their software. There was no CI/CD system good enough, no clean code, not enough architectural planning… Most of the systems were hard coded, one of the big reasons several companies were bankrupted then. Basically, this happened because the maintenance of the code was ignored.
We make the same mistake in the early career of our lives. If we code something for the company, and it will be used in the system seriously, then it becomes a liability to the company. The correct maintenance should be done periodically; like a car, you should change the oil, change the old parts and renew them, and you should adapt it to the new regulations.
As a result, you should think twice before deciding to code something and consider the cost of maintenance. If you are serious about it and it is worth all those costs, you should do it.
Consider it a Handmade Craft
Nowadays, in a regular engine of a car (oil engine, not electric ones), there are more than 10,000 pieces. There is a particular order and relationship between those parts, and every one of them is very important for making it work. If one of the pieces stops working, the car may not work as it should, or it forces other pieces harder, which causes failures in other elements.
A good mechanic (the one you want to take your car to) should know how all those pieces work, and when one is broken, this person should know how to detect which one. Before doing that, the engine should be analyzed correctly, should be disassembled with care, and you should keep the parts the same if they are not required (to prevent unnecessary costs). All handcrafts are like this. The craftsman should decide the next move carefully.
In software engineering, generally, we’re not that careful. In fact, we can try whatever we want by copying the code into our local machine. In fact, we can use a trial-and-error strategy. However, we should do it. We must consider the impact of what we’re doing, how it will affect other systems, what potential problems are in the future, etc. If we don’t think about them, they will pay somebody else to do it instead of us, which pushes us to the lower levels.
Be the Master of Debugging
In the example I gave above, the mechanic should be able to detect where the problem is because he is not the designer of the engine. Actually, the machine is not designed by one person but by a massive team of engineers. Hence, a person working on it should be able to detect if there is a problem and where it is. This is the same for us software engineers.
If there is a problem in the system you’re working on, you should be able to find where it is, which means you need to understand how to use a debugger. At that point, there is a critical part: Generally, people using interpreted languages like JavaScript and Python tend to understand this as use how to use the interpreter debugger. Yes, that’s correct, but you must also understand how other debuggers work. I want to explain the reason by giving an example.
In one of the tasks I was working on, we noticed that a base64 value was changing where the encoded binary contained some numerical values. We decoded the base64 encoding for the changed values, and the computer showed us no difference. This system was working in python, and one of the python libraries was using binaries coded in C++. Ultimately, we used GDB to attach to the process and debugged the C++ code. We also couldn’t find the problem there, but we discovered that GDB shows different instructions in a step. We researched it, and it turned out that there is no 64-bit vectorized processing ISA in several Intel processors, so they’re using the 32-bit one. This caused a difference like 1e-24, which is not that big, and the computer ignores it since it’s relatively deficient. However, it was big enough to cause a difference in base64 encoding because it changed the binary formation. We couldn’t figure it out without using a debugger at such a low level.
To sum up, you should be a master of using the debugger of the programming language you use. If it’s not a compiled one, you also should be able to debug your system by using a debugger like GDB or Visual Studio debugger because, at its fundamentals, everything works on hardware. You never know how it can affect your system.
Don’t Assume Anything
Assumptions… Small cheaters in your brain. When people implement a task, they generally assume several things, and the worst part is that we aren’t even aware of these assumptions. At the end of the tasks, because of the assumptions we made at the beginning, the feature we implemented might not work.
What is the mistake made here? The problem is sometimes we want to code as soon as possible, and often we can deal with the details at the end of the implementation. However, it doesn’t matter how fast or good we do if we’re doing the wrong thing; generally, that’s the case.
To prevent that, get familiar with thinking on paper. Put everything in your mind on paper and try to decide which assumptions you have made. However, it would be best to do this by focusing on every detail. Details are crucial, and generally, they are the critical factor in making your software elegant. In the beginning, you may miss some points, but getting more experience will make you a master developer.
Understand the Flow, the Architecture, and the Reasons
Everything we talked about was about the small tasks we implement in our daily job until this point. It’s required because if you want to go for upper levels, you first must become the master of your current status. After that, you can start learning what they’re doing at the upper levels.
If you know the hierarchical structure in big tech companies, generally, there are levels for software engineers. For instance, for Google, there are levels from L3 to L11. In the lower levels, typically, you implement what is told to you. As you go up, you will get more responsible; firstly, you have to be responsible for a feature or service. Then, you will be responsible for the team and achieving the milestones for the service you’re responsible for. At the highest, you will start deciding the fate of the company’s future.
If you want to become such a person, you have to understand the dynamics of the systems company created. It would be best if you started with the one you’re working on. Understand general aspects, the flow, and the software architecture, and most importantly, you should ask or understand why they chose this structure and research it if a better way exists. Then, you can demonstrate what you learned by asking why didn’t they use the better methods, and you can give suggestions. This will prepare you for higher-level interviews because they will ask you why you used the way you did, and you should be able to provide detailed answers.
In time, you shouldn’t stick only with the system you’re working on but also learn how other systems work and the dynamics between them. What are the dependencies? What are the problems? How good is performance? Also, you ask the same questions and do the same research for every one of them. This will prepare you for the upper levels.
When you start making the suggestions I gave above, nothing will change in the short term. You still are an ordinary software engineer. However, deep inside of you, you will start becoming more. In time, by getting more experience, you will be recognized by other companies and recruiters and interview for senior positions
