Breaking down the work
Now that you have the requirements and a definition of done, you need to define some tasks and write some code. The process of task writing is an art as much as it is a science. Tasks should have enough detail so that the developer knows what functionality needs to be created.

Most of the time we find that developers on the team are best suited to create tasks. That does not mean that the developer that creates the task does the work; it just means that a developer is best for breaking down the work into smaller units of work (i.e. tasks). The tasks that are created should include all the work that is needed, such as developing, testing and deploying.

Writing quality code
There are many attributes that we can use to describe quality code. Many developers can agree that code should be readable, understandable, consistent, maintainable, testable and elegant. When you write code, you should incorporate these attributes.

Readable: All code is readable by machines, but good code is readable by human beings. All developers on your team (both present and future) should be able to read your code. Most of the time you will rely on other developers to help review your code. You will know if your code is not readable because they will start complaining.

One time I asked a “non-developer” to read a particularly important piece of code. Certainly if they read and made sense of my code, then I was relatively confident that other developers on my team could read the code too.

Understandable: Just because code is readable does not make it understandable. The intent of what the code does needs to be evident by reading the code (which means no guessing).

Sometimes it’s hard to convey intent without help. This is where naming standards and code comments help explain the intent of the code. When something is not obvious, then you should add additional information to help explain the intent of the code.

One of my favorite things to look for is variable names that don’t make sense. How many times have you seen a variable named “x” and you don’t know what it means? A simple change to a name that conveys meaning such as “numberOfEmployees” is a significant improvement.

Consistent: Imagine a novel written by multiple authors. You might not make sense of it given the different conventions and styles of each author. When you work on a team of developers, it is the same problem: Each developer has his or her own way of writing code. Consistency is needed to help the code make sense. This is where naming conventions, code standards and a style guide help.