Connect with us


45 Coding Tips to improve your coding skills

Everything I have learned in the last years.

In this post, I leave you a series of tips for coding that complement an article I wrote two years ago. Enjoy it!

  1. Set up version control (e.g., Github, Bitbucket) and perform regular commits, even individual projects. Apply it to projects where you work alone, and you won’t regret losing data or knowing why something was working yesterday.
  2. Use descriptive names in your commits, do not use names like “Fixes” or “Refactor,” or “Minor changes.”
  3. Review all your changes before any commit. Check the logic and simplify whenever possible. Refactor if necessary.
  4. Write your code thinking in other developers and write your code for your future self.
  5. Use comments to explain why you have done something, not to explain how.
  6. Learn to Google correctly.
  7. Try to learn to copy and paste but understand behind’s scenes.
  8. Learn to debug correctly.
  9. Read the documentation.
  10. Don’t just start coding wildly or based on what you’ve seen on Stackoverflow.
  11. Try to learn to copy and paste but additionally understand behind’s scenes.
  12. First, think about what you want to do, write the test, finally code, but don’t overthink, and don’t get obsessed with testing everything.
  13. Be patient. Some days (the fewest) everything will go well, and you will advance a lot, others problems will arise. So take it in taking it easy.
  14. Use an adequate logging system. Logs are essential. If the application runs on the client, use a cloud log system.
  15. Learn the basics, then use frameworks if necessary.
  16. Prioritize libraries over frameworks.
  17. All languages and technologies have good and bad things. Do not criticize what you do not use or do not know. For example, although it may seem outdated, the SOAP protocol is proper and widely used by institutions.
  18. Learn concepts, not syntax. If you understand the concepts and paradigms of programming, the syntax of any language can be learned quickly.
  19. In this profession, you must be very tidy.
  20. You’re going to make mistakes; your programs will have bugs. Face it and try to have a good test battery and a clean and easily adapted architecture.
  21. Be curious and read about technology and software development. You don’t need to know everything, but knowing what tools exist to solve a problem is always good. A good site can be Medium or follow great software developers on Twitter.
  22. Develop a good habit of learning something new daily.
  23. Don’t get hung up on learning all the new technologies and products. Instead, focus on learning how to solve problems because the customer doesn’t care how many technologies you know or what you will do it with. They only care about the result.
  24. Every time you code, keep in mind the problem you address or try to solve and who you target. It’s not about showing off; it’s about making something simple, easy to maintain, and mainly what the client wants.
  25. Save helpful code snippets for later.
  26. As long as you follow good practices, don’t worry about what others say is the “right” way to code. Every developer can have a different idea of how to do things.
  27. During my years of coding, I have met many developers who spend all day criticizing other people’s code and think they are the best. But when I had to maintain their code, I found many botched jobs. Keep this in mind if you are going to criticize something.
  28. Once it works, commit it. Then make changes.
  29. Don’t underestimate a project. Usually, problems arise, or more things are needed than initially requested.
  30. Don’t let them score a goal; if they ask you for something new and the budget or time does not increase, you have to remove another functionality.
  31. Practice with the skills you learn every day, and little by little, you will have more tools to face any challenge.
  32. Take your breaks; if something doesn’t work, don’t loop yourself trying to fix it; take a break and wait for the next day.
  33. When you write code, write it thinking that there is no second time and that it will be audited.
  34. Learn to ask for help.
  35. Use coding style guidelines, and use the same ones as the rest of your colleagues.
  36. Refactor the code in each iteration, but don’t be obsessed with making it perfect.
  37. Use Meaningful Names, Methods, classes.
  38. Create the right work environment.
  39. Keep yourself healthy. Many people have an image of software developers who sit around all day and are out of shape. Of course, we spend a lot of time sitting, but that is not synonymous with being out of shape. Instead, take breaks and get up often and do as much sport as you can. The more fit you are, the better you will withstand the pressure, the less pain you will have, and the more efficient you will be.
  40. Multi-tasking is an illusion. Try to perform only one task at a time, I know it’s hard, but it’s one of the best things you can do to write quality code fast. Use several screens to have more space and be tidier but not do several things simultaneously.
  41. Technology is constantly changing. If you’re going to get into this world, know that you will be learning throughout your career.
  42. Simplify as much as you can: simplify the problem, simplify your methods, simplify the functionality.
  43. Learn how to use the command line. It will save you a lot of time and help you understand many concepts.
  44. Don’t post “funny” comments where you insult someone or say everything sucks. One way or another, the comment will end up being seen by the customer.
  45. If you are in an online meeting listening, try to be focused on what others are saying; otherwise, it is better not to attend. If you try to do something while listening, in the end, you will neither listen nor do well what you are doing.

Extra Tips

In 1971, Gerald M. Weinberg introduced the world to Egoless Programming. Today, these principles are still relevant. Here is the list of these ten principles:

1. Understand and accept that you will make mistakes.
The point is to find them early before they reach production. Fortunately, except for the few who develop missile guidance software, bugs rarely have fatal consequences in our industry, so we can, and should, learn, laugh, and move on.

2. You are not your code.
Remember that the goal of a review is to find problems. So don’t take it personally when a mistake of yours is discovered. Software is meant to be changed or rewritten and discarded. You are not.

3. No matter how much “karate” you know, someone will always know more.
That person can teach you some new moves if you ask them to. So seek and accept information from others.

4. Don’t rewrite code without consulting it first.
There’s a fine line between “fixing code” and “rewriting code.” Know the difference. You have the code, but you don’t have the whole picture. Please don’t act like a punisher and talk about it first with the person involved.

5. Treat those who know less than you with respect, politeness, and patience.
Non-technical people who deal with developers frequently believe that we are at best divas and worst whiners. Don’t reinforce this stereotype with anger and impatience.

6. The only constant in the world is change.
Remain open to it and accept it with a smile. Look at every change to your requirements, platform, or tools as a challenge, not an inconvenience to be fought.

7. The only real authority derives from knowledge, not position.
Knowledge breeds authority, and authority breeds respect. So if you want to be respected in an egoless environment, cultivate knowledge.

8. Fight for what you believe in, but accept defeat with sportsmanship.
Understand that sometimes your ideas will be ignored. But, even if it turns out you were right, don’t be vindictive or say, “I told you so.”

9. Don’t be “that guy in the room.”
Software development is a collaborative game played by humans. Don’t hide behind your screen. Play the game.

10. Criticize the code and not the people.
Software is meant to be changed or rewritten and discarded. Your colleagues are not.

Final thoughts

Thanks a lot for reading me. I hope this is useful to you.

If you liked this article, here is another one that I wrote some time ago that complements it:

Full Article: Kesk -*- @ CodeX