Upping Your Software Engineering Game

A Software Engineer’s prime responsibility isn’t to code, that’s something anyone can learn to do, but rather, to build products, solve problems and have business impact. Coding on its own is pretty useless unless applied to a use-case where it adds value.

This is one of those reasons why there are a lot more coders in the world, but not a lot of great Software Engineers. Coding is a base to build on to become a software engineer, but it’s not the only thing that matters.

I am going to take cues from Rahul Pandey, a software Engineer whom I admire a lot and learn from. (BTW, he has an amazing app for Software Engineers named Taro, a big part of the learning and inspiration for this post came from that. Let’s get back to the post here.

Great Software Engineering isn’t about Output, it’s about Behaviour.

The above line means that output (Or in the case of an aspiring engineer most of the time, the number of lines of code they write) does not scale well. A junior engineer can write 1000 lines of code a day, someone who’s 4 levels above them on the engineering ladder, could be expected to write 10000 lines of code every day, which is impractical and you would be disappointed if you expect that from someone.

In fact, most senior-level engineers don’t write code anymore, they serve a much more important purpose, which is to guide product ideation, creation and guiding a team through to shipping it to the end-users. In terms of business impact, the knowledge and expertise senior engineers bring to the table are much more impactful than someone who knows how to write “Hello World” in 10 languages. This is the behaviour part that is mentioned in the quote above. Great software engineers unblock other engineers, manage information and effectively communicate the scopes, depth and nuance of solving problems and building great products.

This is by no means to say that one shouldn’t code, in fact, every single engineer should know how to code. If you don’t know how to code, you don’t know why some algorithms are faster than others, and some approaches are better than others. (Shamelessly plugging in words from another great Software Engineer I follow: Meta)

In this post, I have compiled a few pointers I have noticed that great software engineers around me follow, I hope it is useful to you.

Be Resourceful

Always have techniques and resources at your disposal, a big part of what makes engineers great is the knowledge of what tools to use in order to achieve something, the reason it’s so important is that it saves you and everyone else that reaches out to you for help, a lot of time because you’re no longer reinventing the wheel. This is a meta-advise as to have great knowledge of the tools to accomplish something, you first need to spend a lot of time in the industry, but once you get in and start experimenting with technologies, more and more knowledge starts flowing in and where to use NoSQL vs SQL databases become trivial. Be knowledgeable, be resourceful.

Take Initiative

Everyone likes having engineers on their team that are ready to take initiative. Builds are slow? They’ll volunteer to check why that is and provide solutions. The query on the database is super slow? They’ll volunteer to check why that is and create indexes that solve the problem.

What I’m highlighting here is that Engineers who say “Let me check that out” and actually do so, are automatically much more valuable to their teams and organizations because:

As Engineers, curiosity should be our driver and exploration should be our forte.

Apart from that, doing the not-so-sexy work like Documentation builds a huge knowledge base for you and makes you indispensable to the organization, because, in order to do that less-than-sexy work, you would have also had to go explore the less-than-sexy code responsible, which is something not a lot of other engineers would be ready to do.

I’m not advising working extra hours or taking up ten extra things at a time, but instead to be ready to take up initiatives that lie outside your core line of work to expand your knowledge.

Have Impact

An important thing as an engineer is to have an impact, and not just any impact, but a business impact. If you can speed up production builds by 50% over your time, you can be proud production issues will be deployed twice as fast, minimizing any losses to the company. Similarly, you can provide constructive feedback that makes certain processes more efficient and effective, you can work on features that will have a high impact on the business side of things. By the Pareto rule, 20% of things you do at your job will account for 80% of the impact that you’ll have on your business, choose what you work on wisely, prioritize and always ask “What’s in it for the business? Will it be better off with this?”

Of course, some job roles don’t have direct responsibilities of building user-facing features but remember, even faster API Response times and page load times have indirect business impact in the form of better User Experience and higher conversion rates.

Be Accountable and Responsible

I have noticed multiple times where something will break on production and no one would be ready to fix it, especially if it’s a weekend, and people would just be searching for the appropriate point of contact to get the fix done.

One such incident I remember well, was when I pushed some code and it unintentionally (Of Course) broke a page on production, the fix was just a one-liner, and I was off for the weekend and had my notifications off. However, the developer that pointed out the issue in the code didn’t take any efforts to just go ahead and fix the issue and save the company from further business impact. Someone after getting tired of contacting the multiple points of contact finally got my number and told me about the issue, I had to come onto my phone, make a change from GitHub’s web app and then push the branch to be deployed as a hotfix.

Be responsible, unlike the example above, the developer who pointed out the issue is acting irresponsibly, having an “It’s not my job” attitude should not be valid in Tech especially when production is broken and the company is suffering because of it.

At the same time, be accountable, people should be able to hold you accountable for problems caused by you and you shouldn’t take it personally because everyone makes mistakes. I made a mistake in the above example and I am the one responsible for ensuring something like this doesn’t happen again and that I learn from this mistake.

Be the Unblocker

Great Software Engineers that I know are “unblockers”, i.e: They are able to help you out in case you’re stuck at something. As an engineer, it pays to be stuck at a problem for a while because there’s some learning involved in the process, but after a certain point of time, the returns from being stuck start diminishing. And that is when it is a godsend to have someone to seek help from, we all know one such engineer that can help solve most of our technical issues if not all. Be that engineer, don’t know everything, but be great at one aspect that people can truly believe that if you’re there to help in that area, nothing can go wrong!

Be Great at solving problems

When companies hire engineers, they are not hiring programmers or coders, they are hiring problem solvers.

Coding, as mentioned before, is something everyone can learn. Good problem solving, however, is something that’s subjective and takes a lot more effort to learn effectively. Coding is the beginning, but be ready to embrace complex problems and thrive on them. Complex problems not only make you a better engineer in the long run, but they also give you different perspectives to solve recurring issues and build a knowledge base in your mind that you can share with other engineers to increase the overall value you create.

Think from a product and business point of view

As mentioned earlier, as a software engineer, your job is not just to write code, but to have a business impact. A company will shell out 10x more money for someone who can have 100x the impact as a regular coder. If the job were to just write code, anyone could do it since anyone can learn to code.

How do you have a business impact? By thinking from a product point of view, where are customers dropping off your application, what are the pain points, and what’s the optimal User Experience? Just building out functionality isn’t enough as more often than not, engineers disregard how the users want to experience products, case in point, Net Banking websites, they are functional in nature, they get the job done but even I, a Software Engineer and a customer have no idea how to navigate through the jungle of options and poorly designed UI.

Have user empathy, and you’re automatically a 5x better Software Engineer!

Be great at communicating and expanding

Most of the time, you would not be working with other software engineers, but instead with marketing and product folks across the company. In such times, you would notice that explaining what is possible and what is not possible with tech is a little difficult for people that do not have the necessary tech context yet.

At this point, your biggest test is how you convey technical messages in a way that non-technical people understand you, and also have enough context and confidence to trust what you’re telling them. This is where great communication skills come in, to be able to convey things in a straight and simple manner without unintended obfuscation, to have empathy to look at things from the other person’s perspective, is a skill that is highly valued inside the industry which no one talks about. Heck, there’s a complete niche of work that involves people who are hired specifically to communicate between the tech and business side to bridge communication gaps, it’s called Program Management.

Be curious

I can’t stress this enough, but one can’t really be an amazing engineer without being curious, there are good engineers who do their job efficiently, and then there are amazing engineers who keep the drive to learn and get better at their jobs alive throughout. In fact, most of the time, they won’t even consider their jobs as jobs and would love what they do if their role involves them learning and unlearning constantly.

If you use a framework, learn how that framework works. If you are fond of a language, learn how it works underneath. Keep the curiosity alive and keep learning and unlearning.