The missing part of the software engineering job description?

A good software engineer is a creative problem solver

There are about worldwide, and this number is expected to grow to 26.4 million by 2019. Finding a good engineer out of this pool is not easy, especially when we do not have proper metrics. In interviews, we end up asking questions on thread pooling, algorithms, puzzles, and system design, and it’s rare for two interviews to give the same result. So, what is the missing part of the software engineer’s job description?

I feel that there is a misconception that the responsibility of a software engineer is just to code: the more cards you churn, the better you are. Sometimes, it’s about how well you can learn and remember algorithms. If the job of the goalkeeper is to stop goals, who is a better goalie, the one who blocks 50 goals and whose team loses, or the one who stops three goals and whose team wins?

A good software engineer solves customers’ problems. He or she does this by collaborating with people and delivering reliable and maintainable software.

I refer to anyone who is trying to solve a problem with software as a customer. When I ask a few developers why they are working on a card or feature, they say, “My manager/product/customer asked me to work on this,” or, “I got to learn machine learning.” Since developers, not the customers, build the software, it is the engineers’ understanding that gets built. How can you solve something that you don’t understand?

So, the first non-negotiable quality is collaborative problem-solving for customers. It does not mean that you merely deliver what is asked for. An example would be the following: a customer may assume that software that works for 100,000 users will work seamlessly for ten million people. I believe getting to understand even 50 percent of what the customer wants is not so easy. Collaboration is more about questioning and eliminating assumptions and understanding the problem well. Eventually, it helps the customers with creative solutions.

Customers are limited by time and cost. So, the next important thing is setting expectations. When someone tells me that he or she exceeds expectations, I drill them to check if they are clear about the expectations.

How do you exceed expectations when you cannot understand them?

Expectations change over time. First, you should be open-minded to accept the change. Then, keep the communication right. Communication is not about more or longer meetings or throwing around jargon. It is a consistent effort to keep the customer and the team on the same page. It is the comfort to question assumptions, say NO to things that cannot be delivered, proactively call out for things that get delayed, boldly say you don’t know, ask for help, give and take feedback, push back features not useful for customers, create a safe place for discussion, pay attention to details, and ask questions to make informed decisions.

You deliver continuously, get feedback, and improve continuously. Over time, the complexity of any project increases; older services are maintained and new features added, making the software less predictable in production. The usage peaks, software rots, the old license expires and the newer license requires an upgrade. Production incidents happen, especially during the planned personal time. You own the problem and solve it while managing the communication.

Keeping things simple is the hardest, especially over time.

The services you own are relatively easier to debug and faster to fix, without breaking other systems. So, a good engineer strives to reduce complexity, refactor the existing code, and write maintainable software. All this is done while managing the new-feature delivery pressure. You adopt good practices to deliver software that is reliable and cheap to maintain.

Curiosity is key. If people say they are passionate about technology, I ask about their learning, and I know if they are passionate based on the answer. Continuous learning and experimenting help in making good decisions and building better software. Further, humility about your capabilities aids in collaboration and managing trade-offs.

As the system becomes complicated over time, it is rare for one person to understand it entirely. You offload it by building the team and sharing the knowledge. And you love to work with awesome people because you learn from them, despite their experience. You are responsible for building the team. A good engineer spends time on hiring. During hiring, you spend time understanding the strengths and weaknesses that a person comes with. Understanding the existing system and team dynamics helps when customizing the onboarding of the new team member.

How can you be a good engineer just by writing code that is not used by anyone? Perfection is the enemy of progress. Just like a 30-minute workout and a balanced diet can keep you healthy looks simple, and yet is uncommon, a good software engineer is not so usual.

At a minimum, a good engineer collaboratively understands the problem and uses technology to provide creative, maintainable solutions.