The Clean Coder : Practicing

Martial Arts - KataProfessionals practice their art with exercises to improve their skills. A musicians spend endless hours on their instrument between performances, athletes go to training between games. This is what we expect from professionals and we should expect the exact same behavior from software developers. It can happen that your company will give you some time to sharpen you competences and it is a perfect opportunity to learn new technologies. But what if you don’t receive this extra time ? Do you practice at home ? What are the tools that can help you practice ?

You can go to the Dojo ! A Dojo (“place of the way” in Japanese) is a place where you can gather to practice martial arts such as karate, judo, jujitsu, kendo and much more. And there are also coding Dojos where you can practice Katas (“form” in Japanese). These exercises aim to train your mind and muscle your brain by writing a specific snippet of code repeatedly. You can also practice Katas by pair using TDD, Uncle Bob calls these Waza (“Art and technique”), one is writing the tests and the other the code. There are a few online Dojos allowing you to exercise on Katas :

http://codingdojo.org/

http://codekata.com/

You can also contribute to open sources project, especially now with GitHub. It features thousands of projects waiting for help in every domain you might like and in every programming language you might consider.

But remember that practicing does not mean that you have to work for your employer you can and you should practice on anything you want to do : it should be fun !

See you next time for “Acceptance Testing” !

The Clean Coder : Test Driven Development

Red Green RefactorI’m sure you have already heard of Test Driven Development or TDD since it has been introduced in the Extreme Programming (XP) methodology in the late 90’s by Kent Beck. This development process relies on a 3 parts cycle : Red – Green – Refactor. You start by writing a unit test that fails (red) because the tested code does not yet exist. After you write the code for your application that makes the test pass (green) and then you can refactor your code to remove code duplication and others code smells.

In “The Clean Coder” Robert Martin defines 3 laws of TDD :

  1. “You are not allowed to write any production code until you have first written a failing unit test.”
  2. “You are not allowed to write more of a unit test than is sufficient to fail – and not compiling is failing.”
  3. “You are not allowed to write more production code that is sufficient to pass the currently failing unit test.”

By following these 3 laws you are locked into a cycle that force you to test every aspect of your code and to fully follow the TDD principles.

Having a full test suite allows you to have the control over the behavior of your application and to avoid any regression after a bug fix or a refactor. The other benefit of having tests is that it provides a detailed documentation for every piece of your program. Each test gives information about the behavior and the expected result of the feature it tests in a given context.

I have to admit that, when writing these lines, I don’t use TDD. Why ? I don’t really have any excuse for not doing it. But I believe in the fact that TDD is a helpful process. I have to practice it in order to absorb it into my everyday development process.

See you next time for Practicing !

The Clean Coder : Coding

codingWe are developers and by definition we code. For some of us it’s just a job, for others it is a hobby, a craft or even an art ! We spend most of our time coding and by “coding” I don’t only mean writing code I also refer to the thinking of code. This is intellectually challenging and an exhausting activity especially when we are solving difficult problems.

You need concentration and focus to achieve the 4 main goals of coding :

  1. Your code must work !
  2. Your code must solve the problem !
  3. Your code must fit well into the existing system ! This refers to the “do not harm the structure” principle covered in the Professionalism blog entry.
  4. Your code must be readable by other programmers ! For more information you can read another Uncle Bob’s book, Clean Code.

You should not work on your code when you are tired or distracted. There is a high probability that you’ll produce waste and you’ll have to redo a huge part of what you’ve already done.

For example you might consider doing a coding night for one of your project. And why not, producing code during all night, especially if you are with some friends looks appealing. But in my own experience it rarely was. I did several coding night with these ideas in mind and it didn’t turn as expected. After 2 am I became completely useless and the code I produced during the night was garbage and the lack of sleep kept me unproductive the day after. Maybe coding nights work for you but it certainly do not for me.

You should also avoid coding when you worry, after an argument for example. Because your mind is not focus on the task you’re working on, it is focus on others issues.

In the book Uncle Bob tell us to avoid The Zone. Being in this state makes you feel highly productive, you are focused and you don’t get stuck. So what can be wrong with that ? This is a tunnel-vision state and you lose some of the big picture elements related to your tasks and then you can make decisions that have to be undone later. I must admit that I’m still figuring this out. I would say that “The Zone” is good for algorithmic work and should be avoided for heuristic work (more information here).

In a noisy work environment, the developer best friend is his headphone and his music. But playing music while coding can shift your concentration toward the song you’re listening instead of your code. I think that depends on the type of music you listen, I personally prefer going for pure music (i.e. no lyrics) or you can try some focus music based on brain waves.

When coding the last thing you want is to be interrupted, your thoughts can vanish and you lose all the thinking you were doing. You should avoid distraction, for instance your can close your email software or at least turning notifications off. You won’t miss anything critical, simply because an email cannot be critical. When something is highly important, people will come at you in person. We cannot rely on email for everything, just imagine sending an email when there is a fire. If you don’t want to be interrupted by others persons you first have to explain them why it is important you stay focused, if they don’t understand they probably will not consider it. And remember that sometimes you are the person that are interrupting others.

What if you are rested, your mind is clear, there is no distraction and the code still won’t come ? Well, this is a perfect time to find a pair-programming partner to solve problems with the power of your combined minds !

There will still be times where you will struggle with your task and you will feel like you just cannot resolve it. When this happens you should walk away and come back later, don’t try to force yourself if you are in a non creative state. You might find the solution of your problem the next morning in the shower or after a break.

Coding is our main activity and we have to understand every angles of it and know how to behave as professionals.

The next chapter will focus on Test Driven Development.

The Clean Coder : Saying Yes

yesThe last entry of “The Clean Coder” was about saying NO, this time it is about saying “YES”.

This 3 letters word means a lot, especially in a work environment. Why ? Because saying “YES” is a commitment, weare giving our word to someone else. The book gives the 3 parts of making a commitment :

  1. You say you will do it !
  2. You mean it !
  3. You actually do it !

This is what we imply when we say “YES”.

We all know it and this is why we often lack of commitment maybe without noticing it. You can recognize this by the use of the following word : need / should / hope / wish and many more. Here are a few examples :

“We need to get this done” – “We should make this” – “I hope to finish this by the end of the week” – “I wish I had time for that”.

None of these is a commitment and we, at least I, probably said every one of them without doing anything to fulfill the related task/work. It might sounds fierce but I think that without commitments, there is no trust.

Am I saying that we should always say “YES” and commit ourselves ? Not exactly. You should commit yourself only when you have the full control over the task you have to complete. But in the other hand that doesn’t mean that you cannot do anything to complete this task, you might not have the full power but you are not powerless.

“We need to get this done !” So what is the next step we can make to actually do it or at least to participate to its completion ? If you want to learn more on how to do things I can recommand you the book “Getting Things Done” by David Allen.

For example you are waiting for an other team to finish their work in order to finish yours ? What do you do about it ? Do you just wait or do try to help them ? Or maybe you try to abstract their part with a mock in order to continue. There is always something you can do !

A professional doesn’t have the power to say “YES” to everything but he certainly has to power to work toward it.

See you next time for Coding !

The Clean Coder : Saying No

noThe Clean Coder” second chapter is about saying : NO !

I know that giving this word as an answer to your co-workers/bosses may sound highly unprofessional but on certain occasions not saying it can have much worst consequences.

Here’s a fictional conversion between a client and a developer to explain the concept.

Client : “Hey ! We would like to have the feature B for the next release (#5), can you do that ?”

Developer : “But we agreed to deliver it for the release #7.”

Client : “I know but this feature will help the business a lot.”

Developer : “We don’t have time to do all the development and testing for the next release”

Client : “Look, this is high priority for our customers.”

Developer : “I’ll try”

Client : “Thanks !”

What happened here ? The developer just agreed to do extra work he knows he doesn’t have time to do (he said it !). Instead he chose to avoid any conflict by saying “I’ll try” that will bring a lot of confusion in a near future. By answering this the developer says “NO” without saying it and the client understood a “YES”, this will end badly. Maybe it’s possible to meet the deadline by using the “quick & dirty” approach and by removing the tests phase. Doing that is risky for the software and is a violation of the “do not harm” principle, and the way the developer does his profession is dictated by the client.

In this example the developer should have stuck to the “NO” because he “doesn’t have the time to do the development and the tests“. Or he should have tried to switch the new feature with another one to fulfill the client request without adding a new amount of work, it can be a win-win solution .

Professionals are hired to ensure that the direction chosen makes sense and follow the right path. If you don’t behave this way you might just be a laborer.

A few years ago, I was an inexperienced junior developer and I faced a situation like this one. I did the mistake shown in this example and of course when the release came, I was not ready and the situation I had to deal with was far from pleasant.

I’m not saying that you should always say “NO”, this would be also unprofessional, but you need to know when to say it.

And you need to know to say YES as well. This is our next topic !

The Clean Coder : Professionalism

professionalThe Clean Coder” is a book for professional programmers (says the subtitle) so the first chapter is about professionalism as a software developer.

There are 3 main characteristics in Uncle Bob vision of professionalism.

The first one is about taking responsability : if you want to be considered as a professional developer you have to take care of your work and especially your bugs. You can choose to test your code or not but you have to face the consequences of your choices. You cannot be perfect by producing zero bugs but you are still responsible for your imperfections.

The second part is named “Do not harm“, do not harm your functions nor your structure. In other words it means that you should test your system and its functionalities to be sure that the behavior of these is not altered. And the structure of your system should stay highly flexible, this way you don’t have to break everything in order to apply some changes.

The third and last characteristic is about work ethic. Uncle Bob expects that a professional programmer has to work from home several hours a week. But this work is not for you employer, this work is for your career. In our field the technologies evolve quickly and continuous learning is essential to avoid becoming obsolete. We have to stay sharp !
But keep in mind that this work should stay fun and you can learn whatever you want, you are not forced to learn for your employers, learn for yourself.

To sum up a professional is responsible for what he produces and should practice its craft.

See you next time for “Saying No” !

The Clean Coder : Book presentation

I know I’m a developer but my first blog post will not be about programming.

I’ll talk about a book… Wait ! Don’t leave ! This book is called “The Clean Coder – A Code of Conduct for Professional Programmers” and it is written by Robert Martin aka “Uncle Bob”.

The Clean Coder

Uncle Bob is a software consultant known for being one of the Agile Manifesto author, a member of the Software Craftsmanship movement and  he get involved in a lot more “good stuff”.

In his book, The Clean Coder, he shares his experience to explain what is his vision of professionalism when working as a software developer.

I really enjoyed this book and I want to share the key principles exposed in it by creating a blog post for each one of these principles. This will allow me to express my thoughts about these chapters.

Summary :

1 – Professionalism

2 – Saying No

3 – Saying Yes

4 – Coding

5 – Test Driven Development

6 – Practicing

7 – Acceptance Testing

8 – Testing Strategies

9 – Time Management

10 – Estimation

11 – Pressure

12 – Collaboration

13 – Teams and Projects

14 – Mentoring, Apprenticeship and Craftsmanship

My personal conclusion of the book is also available here.