DEV Community

Cover image for Things i learnt from best programmers around me
Mugoya Dihfahsih
Mugoya Dihfahsih

Posted on

Things i learnt from best programmers around me

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)

Collapse
 
benjaminjprice profile image
Benjamin Price

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.

Collapse
 
dihfahsih1 profile image
Mugoya Dihfahsih

wow this is awesome, at one point in time i have also used it though not so often

Collapse
 
simme profile image
Simme

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.

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. 😅

Collapse
 
dihfahsih1 profile image
Mugoya Dihfahsih

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

Collapse
 
simme profile image
Simme

It could also be a new emerging best practice.

Collapse
 
madza profile image
Madza

The irony:
Communication and social skills are underrated.
Both are foundation of top-class products.

Collapse
 
dihfahsih1 profile image
Mugoya Dihfahsih

you are absolutely right, communication is inevitable in programming

Collapse
 
sargalias profile image
Spyros Argalias

Nice tips, thank you.

Collapse
 
dihfahsih1 profile image
Mugoya Dihfahsih

you're welcome you too thanks for reading