Subscribe to my email list now at http://jauyeung.net/subscribe/
Follow me on Twitter at https://twitter.com/AuMayeung
Many more articles at https://medium.com/@hohanga
Even more articles at http://thewebdev.info/
To be a good programmer, we should follow some easy to adopt habits.
In this article, we’ll look at some of them and how to adopt them.
Don’t Repeat Yourself
Repeating ourselves is never good. We’ve to change things in multiple places.
So if we’re copying and pasting stuff and using them as is, then we should move them to a shared place so that we can use them by referencing them from that location.
It just makes our lives easier in the long run. Not to mention that we only have to test one piece of code instead of 2 of the same.
Refactor
Refactoring is also important. We have to clean up once we get our stuff working. This way, we know that we make everything easier to understand for everyone in the future.
We probably make some mistakes that violate the usual clean code principles as we were trying different things.
To make refactoring safer, we can run our automated tests to make sure that we didn’t destroy anything in the process.
Become Business-Minded
Becoming a developer should also think from a perspective of the business. This way, we can learn how the business we’re working for keeps getting business and we can become our own boss if we want to or be forced to.
Jobs aren’t always available, so we should prepare to work for ourselves and survive or even thrive.
There’re many examples in many self-help or business books that have an example of people with a thriving business that lost their jobs or quit, and they’re happier than ever.
The moral of the story is that don’t assume that any job will last forever or will even be there tomorrow and think about the business side as well.
Also, we’ll have more empathy towards customers when we’re on the job.
Small Commits
Small commits are important. They let us revert our code more easily if some change goes wrong.
The best time to commit code is when we get something working. This way, we know that commit has at least something working.
Also, it’s easier to find bugs from smaller commits since we can trace to where the bug was committed when we look at the commit record.
It’s hard to know what was changed from a large commit. Also, code reviews are easier with smaller commits so that the reviewers can see the progression of the code.
Keeping Our Code Consistent
Once we decided on some coding standards, then we should stick to them. We can enforce that with linters.
They can be adjusted to the standards we want and then we can stick to them by automatically linting checks.
Naming conventions should be consistent with language specifications. For instance, JavaScript specifies that variable and functions are camelCase and constructor functions and classes are PascalCase.
No Todos
We shouldn't have todo comments in our code. This is because we’ll probably forget about them if we just put a comment there and ran off.
Therefore, we should just do it now or add a task to the task tracker and do it later.
Keep On Learning
Software things change a lot. However, now that more technologies are becoming mature, changes are happening more slowly.
Therefore, it’s an easier time to learn new things since the basic paradigms have been firmly established.
Now it’s more about incremental changes. Learning is new things that make us more useful and we help people more, which makes us valuable inside and outside of work.
New opportunities will come to us if we learn more.
Plan Our Code
Planning is important. We can figure out the general procedures first and then implement the solution.
Also, if it’s complex then we probably should ask others for their opinion in case we missed anything in our planning.
Keep Our Code Simple
Keeping our code simple is a must. It’s just better for everyone. People don’t like reading a complex mess.
Everyone loves clean and simple code that everyone understands easily.
The less code we write the better. The best is no code at all. We should just write enough to do whatever we need to do.
Conclusion
We should keep our stuff simple don’t repeat ourselves.
Also, no todo comments in our code. Either do it now or put the todo in a task tracker to do it later.
Small commits are also good.
Finally, we’ve to be business-minded since we’ve to be prepared to survive without a job.
Top comments (2)
it is not so straightforward as sounds. You can and should do this only if this part of the code won't change differently for different cases, but who knows that it won't happen.
It is ok for some technical functions, but for business code, I would rather think twice.
There is no bad in duplicating code: fewer dependencies, more readable, and really not so hard to maintain as looks like.
From my perspective, a better approach is WET (Write Everything Twice).
Yes. If they might diverge, then it's OK to make a copy and change that.