The four golden rules to be a better software developer.

Written by Alberto Gutierrez

• The research to become a better software developer is core to any good software developer. Being a better software developer reflects directly in the code you produce, the better software developer you are, the less bugs, easier to read and easier to maintain code you will produce.

  What follow are the four rules I use on my day to day work to help me become a better software developer.

  Rule number 1:  My code is crap.

  All code is crap, and that includes yours, (and mine, of course). No matter how brilliant a piece of code you think it is, there will be always better ways to implement it, and several programmers who will hate it.

  Even if you are sure your code happens to be good, force yourself into "my code is crap" mode, and ask around about improvements, be open minded and you will see soon how you will find issues in your code that you never have thought about.

  Rule number 2: Even if it's crap, I care about my code.

  It is not about creating the best code upfront, is about making it better every time you visit it. When you finish some functionality, you are not done, I haven't met any programmer that produces acceptable code on their first attempt, you need to polish it. Refactoring is then one of the main activities you should be performing.

  Rule number 3: My opinion about my own code is wrong.

  We are so egocentric that we end up believing that what we have produced, no matter how bad it is, is the best solution as possible. Never trust your own opinion, show your code to as much developers as possible and listen to them.

  Rule number 4: My manager doesn't care about my code, and he pays me.

  This rule regulates the other three, it is easy to forget that you actually get paid to get things done, your manager should also care about the code, but he is more focused in completing things on time with an acceptable quality, so be careful not to expend too much time just making sure your code is not that crap. The key is being able to balance getting things done and their quality.

  Bonus: A few tips to help you with these rules.

  Code reviews.
  Keep it simple.
  Test.
  Refactor.
  Non technical factors.