In my opinion, a coder can be guilty of two things. Either we over-engineer i.e., try to solve everything in one go, instead of following an iterative approach, OR we under-engineer, i.e., just code without understanding the impact. What we need is to attain the ‘middle ground’.

Here are 7 guidelines to ensure we are always in the ‘middle ground’:

1) Don’t just code the requirement. You must understand the problem fully. You’re a Data Person, you should care about the problem from the data’s perspective. Building complex code is cool, but spend more time understanding and analyzing the requirements from the data’s point of view. That is more important than what tool, language, or technology you are using to process it.

2) Unit Testing is part of coding, not a separate exercise. Dedicate 25-30% of development time to Unit Testing. As an example, if it takes 8 hours to code, you should allocate a minimum of 2 hours to Unit Test that code. In my opinion, 75-85% of testing coverage should come from Unit Testing and the rest from Test Automation. Remember, SIT (System Integration Testing) is not for testing one piece of the puzzle (your code only) but the entire puzzle board (all integrated code). So don’t rely on your best friend on the QA (Quality Assurance) team to figure out what you did last summer. Spend time thinking about the test cases, for example, a data integrity check before and after processing, or code performance metrics. If you are NOT clear on the unit test cases, then don’t start coding. Seek more clarity until you can visualize the output. Keep in mind, Unit testing is not just checking if the code runs but checking if it generates the right output in the specified time.

3) Don’t use a hammer to crack a nut. You don’t need to consider all possible edge cases in the world while designing. Perfect code that sits in your machine has no impact, whereas merely “okay” code in production adds value. Keep your design simple but ensure the code is nimble; you can always increase complexity later if needed. Question the design. One of the most common reasons for poor design is NOT understanding the underlying technology enough and trying to solve every need with a custom approach. For example: if you have more supporting custom tables to hold your code processing information than actual data tables, then you are either not using the right tools for processing, OR not using the out-of-the-box features efficiently. This design is neither sustainable nor scalable.

4) Don’t let your experience take over your imagination. Very often we refuse to see the problem with fresh eyes and always try to tie every new problem back to problems we have solved earlier. That’s the wrong approach. Keep in mind, we are living in an age where technological advancement occurs rapidly. Do your due diligence and see what’s new before dusting off your old toolbox.

5) Asking for help and using Google (now ChatGPT), is the most powerful skill. There is no point in spending days trying to solve a problem yourself when someone has already done it or can do it for you within minutes. However, before asking for help, document the logical steps you’ve followed with pseudo code and summarize why you think it’s not working. This logical breakdown not only helps an expert to make a resolution faster but also helps you search for the right content.

6) Reusability is the key. Make sure your code is well documented, clearly comment your code, make it modular (break your code into logical units that can be tested individually), and make it configuration driven. Anyone (including you) should be able to easily understand (remember) what you did a few months or even years ago.

7) GIT is your best friend, NOT some annoying Ex from your past. So, please stop treating GIT as an ”extra” task! Once you make using GIT a habit you will realize how it makes your life easier. Follow some basic rules of thumb: Take a feature branch approach, always pull before push, push daily (and encourage others to do the same), merge feature with dev only after the feature is tested, and do not push to master. Trust me on this, you will thank me later. Code Repos are invented to help developers, not the other way around.

In the end, it’s all about having fun. Keep in mind, the code you write, whether small or big, easy, or complex, is your unique creation. It’s your legacy, so treat it well. Otherwise, what’s the point?

If you have any thoughts, comments, ideas, or feedback, please reach out at soumen.chakraborty@freshgravity.com.