Software Engineer - The missing manual! Recipe to be a better engineer

You must be wondering what a missing manual can be. After all, you have read many books and written a good amount of code to call yourself a software engineer. Have you ever thought why some engineers go fast over the ladder, and some take slow steps? Slow people think that being a software engineer is all about writing code and making things work. I will tell you a few things that can help you to be a better software engineer irrespective of what technology you are working on.

Think twice; write once

Do you directly jump into writing code whenever you are given a problem or do you think about possible solutions and try to refine things using mind maps? Junior engineers usually think about code, loops, variables, that awesome algo and whatnot. That’s where they are missing planning. Like other construction methods, your code/solution should follow a construction plan with everything considered before writing your first line of code.

I prefer the pen-and-paper approach. This helps me visualise all the inflows and outflows. You are more likely to catch some edge cases if you follow this path rather than hitting your keyboard for your favourite IDE.

Start Listening

Are you the person in the room who is always talking? Do you have solutions ready for every situation? Is your preferred technology the Swiss knife which can do everything? Do you cut people in between?

If the answer to most of the questions above is “yes”, you are already making a mess around you. I am not saying that you should not put your point in a meeting or stay away from your preferred tech. It’s just that you don’t listen to people around you, a good learner is a good listener, and you can’t stop learning. Here are ways to fix it.

• Listen, don’t merely jump in between to let people know the scale of your knowledge. Everyone knows something you don’t know, so keep quiet and listen.

• Accept that people around you are skilled and give them room to speak. See things from their perspective.

• If your teammate has a solution that you disagree with, don’t cut them in between. Instead, ask for a discussion. Before the discussion, evaluate their idea and look for positives and negatives.

• If you see some positives in the idea, mention them first and propose a solution you think can solve the remaining issues.

• Praise your teammates and let them know when you learn something from them.

Remember, everyone has a different journey, and engineers are sometimes biased based on their previous learnings. This keeps us in our comfort zone, and we see trying new things and listening to different solutions and burdens.

Code for the future

As beginners, we code to deploy. I mean, we want to get things done by any means like our college project where we don’t have strict coding guidelines, deployment strategies, test coverage, code reviews, and scale issues.

Most mid-size to large companies have some guidelines, and an engineer is bound to follow them. The common problem is in start-ups where junior engineers code to get things done. If that works and the output is as expected, deploy. After a few years, the company starts growing, and the core codebase is hard to change. This takes a lot of resources to fix, and here is what you can do to avoid this situation.

• Code clean, don’t believe that short variable names and nonspecific function names are obvious to other engineers. Always write self-documented code which can be read and understood at first glance.

• Follow (or establish if there is none) code guidelines that your company has. For example, have a look at Airbnb JavaScript Style Guide.

• Do a peer code review. Don’t be aggressive during code reviews; make suggestions, and have healthy discussions.

• Think about a modular approach while you code. You should be able to add or remove your module without any major issues.

• Keep scalability in mind! Modifying code for scalability at a later stage is a pain and a waste of resources. It’s better to invest some time in this at the start.

You are not there yet

And you will never be. I have been writing code for almost a decade and have seen many engineers become more humble as they grow. The more you learn, you realise there is so much you don’t know.

There is a common problem with new engineers known as “I know it all”. Because of this attitude, there is a bad feeling if their suggestions are not taken. They can’t stand people giving them some advice or asking them to ditch their favourite frameworks. Not only starters, but this problem is also seen in many senior engineers. Remember, if you think you know everything, you will find learning new things hard. As a wise man said:

You can’t fill a cup that is already full.

---

If you have found this useful, share it with others. Please feel free to share your thoughts. Comment here or reach out to me on Twitter. Happy Coding 🧑‍💻