A Coder’s Legacy: 7 Guidelines if you work in the Data Management space

March 9th, 2023 by Soumen Chakraborty, Director - Data Management

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fresh Gravity Celebrates Nine Years of Success and Growth

We are thrilled to share that on April 8th we celebrated the ninth anniversary of Fresh Gravity’s founding. It’s an incredible milestone that wouldn’t have been possible without the hard work, dedication, and unwavering commitment of the Fresh Gravity family. We would also like to thank all our clients and partners for trusting us. Thank […]


Reflections on the Pharma Industry for 2024

Pharmaceutical companies are at a significant crossroads in terms of how they engage with customers, innovate, and adopt digital capabilities. On one hand, there is an increasing demand for personalization of drugs, while on the other hand, global inflation and uncertain market trends are causing challenges for the industry. These factors, in addition to a […]