In this “uncertain world,” everyone’s clueless about how AI will or will not replace their jobs. Arguments ebb and flow like the tide, yet there are basic principles that you can follow to keep yourself in demand.

What is software engineering?

First, let’s understand what software engineering is. Without this, you’ll not know what value you’re adding or can potentially add.

The most visible part of software engineering is code. It is one of the few things that beginners and experts, tech and non-tech folks, agree on. Because it’s visible to both of them. However, that’s not the whole story.

These are some other aspects of software engineering which is seldom seen:

1. Problem Domain: Understand the problem domain is required before you can even think about improving a situation within that domain. It doesn’t mean you have to be an accountant to improve accounting, but you do need to understand what’s important to an account and why.
2. Computer Science: Engineering is an application for science. To apply science, you must know science. Your goal need not be forwarding science, but forward the application of science. Most engineers who feel programming is a repetitive job and there’s nothing unique about it are usually grossly misinformed about computer science. This includes, but is not limited to, the knowledge of mathematics, algorithms & data structures.
3. Architecture: Or we can also call this design. When a “computer science eye” scans a “problem domain,” you get “technology solutions.” Why? Because knowledge is the lens through which opportunities are seen.
4. Engineering Management: Managing an engineering project typically involves aligning different teams onto a common goal, especially when those teams don’t understand each other’s work that well. The architecture is used as a basis to align them.
5. UX: By UX, I don’t just mean the visible aspects. The entire experience of using the product comes in here.

There’s a lot more, but even with just the above, you’ll find little agreement between a beginner / expert, or a tech / non-tech person. Because what’s visible to a software engineering expert is often not even visible to others, let alone agreeing on them. So others take the most convenient route; they pretend these broader things don’t exist.

Just like a doctor is not the same as the medicine he is prescribing, so is software engineer not software itself. The software we use is the end-product of software engineering. The end-product can be easy to use and concise, yet the process to arrive there riddled with complexity.

The 3 mistakes of programmers

I call these the 3 mistakes of programmers and not software engineers, because acting like a “programmer” is the common denominator of all these mistakes.

1. Focusing on coding rather than MAKING

Note that we said that software is the end-product of software engineering. It’s not “code.” That’s the mistake a “programming mind” makes. It thinks that some working code is the end-result of good software engineering. In truth, code might just be a small part of the bigger solution.

2. Not bothering about the problems being solved

As long as the test cases pass, who cares how the program or code be used? In especially B2B settings, you’ll be surprised how many programmers don’t even understand the software they’re creating. They just follow the “guidelines” of the Product Management team and make sure everything’s up to spec.

They do not know if the software they’re creating is good or bad; right or wrong; useful or worthless. The only thing they know is that it works (most of the times) as per some arbitrary specification.

3. Not focusing on the core skills

In my early career, when I used to interview programmers, most of them could not even write a few lines of simple logic! Either they were misguided as beginners, or they only focused on the management aspects of software engineering, completely forgetting how to even use the most basic tools.

Even while in college, the general trend was for people to look for shortcuts to answer certain questions quickly. Although this strategy worked well during examples, where the scope were often limited, it didn’t generalize well to the real world. Memory is no substitute for understanding.

Most of the times, even after breaking into a good software company, people just stop learning. They stop keeping themselves updated. They’re allergic to any kind of improvement that threatens their status quo. And just with that attitude, they slowly start becoming outdated.

The 3 steps to a highly-paid engineer

Now let’s move to the positive side. What is it that highly-paid engineers do? I’ve seen quite a few of them. But nothing beats the experience of actually being one of them.

I still remember getting my first appraisal in just a mere 6 months, because I exceeded all expectations, and more. Moreover, I got to work on increasingly important projects because of my reliability, which gave me access to even more important projects, and so went the positive loop.

Let’s see those 3 steps to becoming a highly-paid engineer.

1. Brush up your MAKING skills

When you learnt programming, you would have loved building real-world stuff. Even today, forums are littered with questions by new beginners on “what to create next?” We innately love being creative. So what happens to all that positive attitude?

Well, a “startup” happens. Where you’re asked to become more and more “specialized.” Gurus online say you either are a generalist (bad at everything) or a specialist (bad at everything else except one). And you really cannot be good at two different things at the same time. I laughably don’t agree with any of those sentiments.

The advantage of having very specialized functions is that it de-risks each role in a startup. If you leave the company tomorrow, there’s still just a small hole to fill back in. But if you were a rockstar, that’s going to be far more difficult to replace. The end-result is that you need a team of 10 to even put a button up on the website and ship it to the end-user.

It’s very important to not forget your other essential skills even while working in specialized roles. That’s what MAKING is all about. The ability to MAKE the end-product, and understand everything that goes into making it. The end-product is a working piece of software that users will love to use. Don’t ignore the bulk of the important steps.

This includes everything from requirements gathering, to technical & UX design, to actual implementation, to deployment, and finally customer support and feedback. That’s what it takes to create software that works well.

2. Become better at LISTENING TO PROBLEMS

Software engineers, for whatever reason, don’t like “people” or social interactions in general. I’m a software engineer who has been that way. But I changed. And a lot of my growth came because I changed.

We create software primarily for people to use. Because we care about contributing to the world. And part of that is being able to have conversations with others, regardless of whether they’re technical or not. That’s how you’re going to know what their problems are.

As a software engineer, you’re a master of solutions. All you need are real-world problems to tackle. And there are plenty of them. Not everything worth building is a “SaaS CRUD App.”

By just talking to sales, marketing, or account management folks at your startup, or even by lurking in forums and communities of other professions, you get valuable insights into how you can be more valuable. Many skills of yours which you take for granted can be extremely useful to someone else in the right context. You just need to find them.

3. Improve your CORE SKILLS

Computer science is not programming. And you also know that coding is not the hardest part of software. Improve your core skills, so that you can meet problems head-on with innovative solutions.

I’m a strong believer that knowledge is the lens through which opportunities are seen. You can have the making skills to deliver any project, or the listening skills to know the actual pain points of the user, but it only becomes an opportunities when you can think of a solution to build. And it’s not as easy as it sounds.

Many are proud of claiming that ideas don’t matter, only execution does. I believe that good ideas matter. It’s just that people call random scraps of thoughts “ideas” and that inflicts a bad reputation on the whole concept of “ideas.” Without good ideas, we don’t have calculus, or the aircraft, or the thousands of inventions that make our lives better. Just like not all patents are granted, not all ideas are good. But that doesn’t make the good ideas any less valuable.

In order to have good ideas, you have to focus on your core skills. This could be computer science, aspects of software engineering, or learning a framework in depth. But it is really important to have a good foundation rather than “programming by mimicry.”

Conclusion

Remember this equation ⇒ PROBLEMS + SKILLS = VALUABLE SOLUTIONS. That has been the essence of whatever I’ve conveyed above. Whatever happens, make sure you’re always doing these 3 things:

1. Improving your MAKING skills
2. Becoming a better LISTENER TO PROBLEMS
3. And improving your core skills

That’s the key to becoming someone who is valued a lot, and also paid accordingly.