Don’t be a lazy. Do things the right way even if it’s a lot of work.
Don’t give up on something just because you’re stuck. You’ll figure it out eventually.
Always track down the root cause of a bug. If a bug just “goes away”, it hasn’t. If you can’t explain what fixed the bug, it isn’t.
Write unit tests. It may seem unnecessary and a like lot of work, but it will help you in the long run.
Best practices are best practices for a reason. Don’t assume that your approach is better just because it’s what you’re used to.
Writing readable code is important.
The functions/methods you write should serve one specific goal and should be optimised.
Your code should be easily understandable by the other person.
There should be code reviewing so that you get to know where you're lagging behind, and if you review other's code you can learn from them.
No one knows everything so don't be shy to ask some help if you get stuck or you're having problem in understanding some scenario.
Copy paste will not work always.
Always be willing to learn new things, try to adapt them quickly.
If the code is repetitive try to separate it and make it a separate function.
Learn to debug your code, write test cases so that you should know the problem when testing team comes to you.
Use sonarlint or similar plugin to understand the flaws and violations in your code, using which you can improve your coding reliability.
Top comments (9)
Here’s one that I learned when I was a junior developer that has stuck with me - and I try to teach others:
When reviewing someone’s code, try to use questions instead of statements. You don’t have all the context the author did and they may have a good reason for doing something.
For example, instead of saying “you should have done it like this [...]” you could just as easily ask “did you consider using this approach?” - they might have and might have a good reason for not doing it that way.
Finally, as a bonus point, if the code works and doesn’t have any issues allow the author to reject your ideas/feedback.
wow this is awesome, at one point in time i have also used it though not so often
The opposite could be said as well. We have people breaking best practices to thank for most of the pioneering work done in technology. Don't assume someone else's idea is worse than yours only because it's a novel approach. 😅
but as long as your twist is not conflicting with the basics of the stack otherwise it code make your code not readable and easily understood by others if it deviates a lot from the known principles
It could also be a new emerging best practice.
The irony:
Communication and social skills are underrated.
Both are foundation of top-class products.
you are absolutely right, communication is inevitable in programming
Nice tips, thank you.
you're welcome you too thanks for reading