Super Simple Rules for Becoming a Better Software Engineer (Part 1)
By: David Mogbeyiteren
Tags: Programming, Improvement, Software Development, Software Engineering

Hello, awesome people! I am starting a new series on becoming a better Software Engineer and I will just be throwing out some really short and simple principles that have helped me increase my capacity as an Engineer over the past two years.

I am going to keep them straight to the point because I believe this information is not exactly a mystery and are really common knowledge. The power, however, is in taking the simple principles of life and greatness and practising them continually until they become habits. So without further ado, let’s get this party started:

Take the time to truly understand how things work

I came from a clan of Software Engineers who have a motto of “just get it to work” and a mindset of “if it works, then all is well and good”. It was a case of if I make a POST request with some payload and the data hits the database, then we are good to go and if I can make a GET request and pass some ID and the data comes back in JSON format then hurray!

As I grew as a Software Engineer, I quickly realised that I could not make any significant impact if I continued to think like this. As much as this mindset was about quickly getting paid and finishing the project on time, it does not scale for an Engineer who will truly make a difference.

Software Engineering is about creativity to a large extent and it is extremely difficult, I dare say impossible to be truly creative and innovative without a foundation of understanding. A sound software engineer must pay the price to truly understand how tools, technologies and programming languages work.

To quickly balance this perspective, I do not advise anyone to go get stuck in some tutorial limbo or a huge computing textbook in the name of understanding how stuff works but I believe a serious Engineer should give a good deal of thought and research to find out how his code works and should be able to explain why it works the way it works. Your mind gets to understand how things work through practicals based on sound theories and not theories alone. So please make sure you get your hands dirty on some code consistently in the quest to understand.

To take some active steps towards building a mindset of understanding, I will give you a simple exercise and an encouragement. For the exercise, pick a concept you have been using for a while but know deep down you do not understand how it works. Make some research about it to understand what is going on. It could be the async-await syntax in Javascript or Joins in SQL or the aggregation-pipeline in MongoDB. Anything you are familiar with, have used in the past, probably copied some codes from stack-overflow or a blog somewhere, asked a fellow Engineer to help you code it out but you know and feel you do not understand the concept. Take that topic, concept or syntax and get some simple materials that would help you understand how it works and keep at it until you finally understand the topic. You can do this in your spare time, like a free 1 or 2 hours or when you are just plain bored.

Now for the encouragement, carry out this exercise repeatedly anytime you feel that way about some concept, tool, technology or programming language.

The way to understanding is a simple explanation and the proof of understanding is a simpler explanation.

Calm down and read the error message (Try reading it twice)

For some reasons, I believe an error message is the computer’s way of encouraging everyone to continue programming and building software. If computers could just be in the mood and not give any feedback when you left out a semi-colon in your Java code then we would be in a lot of trouble.

An error message is the computer’s way of encouraging people to continue programming and building software.

So a simple way to improve as a software engineer is to just read the error message the same way you would read a message from your angry spouse when you are trying to prove a point to him or her (just kidding).

Take some time, read the error message; you can read it a second time if you didn’t understand it the first time. Check out the files and line it’s pointing to and then try to fix the error based on the understanding you got from the message. Don’t assume you know what is wrong the same way people assume they know what you are going to say or what you mean without really listening to you. Just take some time, go through the error message before going back to the code. You already wrote the code the first time, made an error and blew it and now we all know you are not KyleXY. There is no need to prove a point anymore. Just humble yourself, read the error message carefully, fix the bug and move on to the next error. Then repeat the process until you are happy in life.

Let us hear the conclusion of the whole matter

Becoming a better engineer is a marathon, not a sprint and rushing never really helped anyone. I know these steps could become irritating and make you feel slow initially, but no good thing comes easy. Remember, the goal is to make these things an unconscious habit and a second nature so it is going to take some work on your part but the results are worth it in the long run. Thanks for reading.