5 Tips for creating good code every day; or how to become a good software developer

  Being a good developer is like being any othergood professional, it’s all it’s about doing as much quality work as possible.There is a popular sentence that summarises it: “Do it. Do it right. Do itright now”.

1.- Have your own to do list for the day.

Thebest approach to complete complex activities is to break them down intosimple activities. Dothis every morning by breaking down the different activities you would like tocomplete for the day and assign them a schedule. This will help you to:

·        Havea better understanding of the activity.

·        Havea focused goal for the day

·        Improveyour estimating skills. After a few days you will find that you can predict howmuch work you can do in a day.

2.- Do one thing at a time.

It’sbeen proven by different studies and published in different media (ie CNN)that it  is more productive to be focus only on one task than to domultitasking.

Workin short batches of intense work of about 25 minutes with a 5-10 minutes rest.There are popular techniques like the pomodoro technique tohelp you manage the time. There are also tools to help you measure the time youspent on the different tasks, my favorite one is CoolTimer.

3.- Do it right.

Thereare two keys to know if something is done right

1.    To beproud of the solution; it is not just any solution, it is agood solution. Itfollows the principles of the “Pyramidof the software quality“.

2.    Thesolution passes at least one review. Ask one of your colleagues that yourespect as a good developer to review your solution and for his sincereopinion.

4.- Don’t finish something until it’s completely done.

Weall know that if there’s still a glass to wash, we cannot say that we have donethe dishes, the same applies for painting a wall or driving to a destinationbut in software development we don’t do that, we say that we are done even whenwe haven’t completed all the unit tests or when we haven’t checked if theimplementation is correct with the customer, that’s a typical behavior from Hope Driven Development andthat’s evil.

Something is only done when you are 100% sure that it won’t benecessary to work at all on that solution unless the requirements change.

5.- Better late than sorry BUT better sorry than never.

Ifit’s going to take you an extra day to complete the testing of some code, or torefactor a class which is unreadable, do it, that’s an investment in time forthe future, but if you are stuck with something and you are delaying theproject too much, just find an easier solution. It may not be as elegant as theone you are implementing, but at least you will have a solution. Make sure todocument it as future risk for the project and something that will probablyneed to be revisited.