3 Rules that every developer should follow

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1475

Abstract

blockquote><blockquote id="46dd"><p>B. Ask all your doubts, no matter how silly they sound, leave no room for assumptions.</p></blockquote><blockquote id="40a6"><p>C. If you see a complex module, which would need some proof of concept work then make sure you mark those modules as spike and communicate the same with your manager.</p></blockquote><blockquote id="89da"><p>D. Do not give estimates based on your gut feeling or assumptions, be very clear on what the requirement is.</p></blockquote><p id="840e">Sometimes it may happen that you may end up spending more hours than what you estimated and it’s completely fine, but do make sure you communicate this to your project manager.</p><h1 id="7d9d">2. Follow programming principles</h1><p id="eb91">The project you are coding today will be may be maintained by some other developer or in fact, it could be even you. If you don’t follow any programming principles and have spaghetti code written all over the place you will be having a hard time making code changes for simple change requests.</p><h2 id="0843">You may make a change and then an existing functionality could break causing frustration.</h2><p id="db71">Not following any programming principles can cause more work for you in the longer run, and a smaller change could take weeks to implement delaying the project release.</p><p id="a46e">So whatever technology you follow, do make sure you follow programming principles.</p><figure id="8d6d"><img src="http

Options

s://cdn-images-1.readmedium.com/v2/resize:fit:800/1*-eLqehfMHsoExfxyCi4dIw.jpeg"><figcaption>Photo by <a href="https://www.pexels.com/@thisisengineering?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels">ThisIsEngineering</a> from <a href="https://www.pexels.com/photo/female-engineer-controlling-flight-simulator-3862132/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels">Pexels</a></figcaption></figure><h1 id="a433">3. Write test cases for your project</h1><p id="0f1d">As a developer, the module you code or change has to be tested by you for all the use cases mentioned in the user story.</p><p id="ab5f">Nothing frustrates a QA more than having to re-test the entire application just because some feature is not working.</p><p id="b546" type="7">Every build that you release to the QA should be production quality with zero defects.</p><p id="bda2">You should write a unit and integration test for your application which will avoid breaking existing features and will test your code for the new feature.</p><p id="7a86">Once your test pass, run the application and manually test it for all use cases to see if everything is working fine as expected.</p><p id="fd32">I hope these three rules will help you in becoming better, if you follow any rule which has benefited you then please do mention that in the comment.</p><p id="7c4e">Thank you for reading, I hope you found this article useful.</p></article></body>

1. Be practical when you give project estimates:

Estimates are driven by project requirements, and sometimes project requirements change during development or are ambiguous, to begin with.

The problem with an ambiguous project requirement is, different people when they read it will have different ideas about the requirement and its complexity.

A bigger problem arises when developers read such requirements and provide estimates for it, so before you give the estimate here are some of the rules you can follow

A. Read the project requirement carefully.

B. Ask all your doubts, no matter how silly they sound, leave no room for assumptions.

C. If you see a complex module, which would need some proof of concept work then make sure you mark those modules as spike and communicate the same with your manager.

D. Do not give estimates based on your gut feeling or assumptions, be very clear on what the requirement is.

Sometimes it may happen that you may end up spending more hours than what you estimated and it’s completely fine, but do make sure you communicate this to your project manager.

3. Write test cases for your project

As a developer, the module you code or change has to be tested by you for all the use cases mentioned in the user story.

Nothing frustrates a QA more than having to re-test the entire application just because some feature is not working.

Every build that you release to the QA should be production quality with zero defects.

You should write a unit and integration test for your application which will avoid breaking existing features and will test your code for the new feature.

Once your test pass, run the application and manually test it for all use cases to see if everything is working fine as expected.

I hope these three rules will help you in becoming better, if you follow any rule which has benefited you then please do mention that in the comment.

Thank you for reading, I hope you found this article useful.