Some lesser known facts about coding mindset that I have learnt.

<h2>Introduction</h2> <p>Working as a software engineer, I have learnt many things about coding standards, coding practices, design patterns, pros and cons of programming languages which ultimately forms a <em>“Coding mindset”</em>. Along with technical knowledge having right coding mindset is necessary. Here are few points for which I was having counter thinking when I first started working and I started to get corrected on them as time passed.</p> <h1><strong>- Write a code as you own it.</strong></h1> <blockquote> <p>“Ownness brings care and sense of responsibility”</p> </blockquote> <p>Writing a code with care is needed as you will select things which are better for your code. Consciously you will feel that what things you want to put and what not, you feel responsible and all this result into better code quality and will give overall satisfaction to you at personal level. At the other end it also gives you confidence about your own code.</p> <h1><strong>- If it is working than leave it</strong></h1> <p> </p> <p>If you found a piece of code which is complex to understand, is bad structured, not following best programming practices but it is working. What should you do? You should consider refactoring it. The more well-written code you have, the easier it is to understand the code. The more understandable your code is, the easier your job is. That's why we should <strong>not</strong> follow old engineering thinking of <em>if it is working don’t fix it. </em>As a programmer we should always remain open for changes.</p> <h1><strong>- Always try to break the code.</strong></h1> <p>When ever we make or create something, we always try to make sure that it doesn't ruin or break by us or anyone. This same thing can be applied for code but with one twist. When ever we write a code we should always try to break it by ourselves first so that nobody other can breaks it after. In order to break the code, we can at least look at following things:</p> <ul> <li>Provide a input to our code so that our code throws different exception or error than we are already excepting.</li> <li>Create a testcase which can overflows the capacity of data structure we used and see how our code behaves.</li> <li>Give our code a different type of input then we are expecting.</li> <li>Generate output which is different than what our code’s parent component is expecting.</li> <li>Look for cases or scenarios which we haven’t handled in our code.</li> <li>Create a way by which our code goes into infinite loop.</li> <li>Access our code concurrently and check for thread safeness and performance.</li> </ul> <p>And many more…</p> <p>By looking at these cases you can get crux of what I am saying, now it is possible that not all these cases can be applied to your code but you should always check for all ways you can break your own code. And then after discovering all the ways you can modify your code to mitigate those scenarios. This scenarios will help you to create robust systems.</p> <p><a href="https://medium.com/@yasheshschauhan/some-lesser-known-facts-about-coding-mindset-that-i-have-learnt-a0c2c397c89a">Learn More ;-</a></p>