ロバート・C・マーティン著『The Clean Coder』から学んだ9つのこと

I recently finished reading Robert C. Martins' latest book The Clean Coder: A Code of Conduct for Professional Programmers (ISBN 0-13-708107-3).

Without hesitation, I can honestly say that this book has literally changed my view and thoughts on professional software developers.

While reading this book, I have been writing notes in a scrap book on things I learned and things that turned on a light switch in my head. This entry is a compilation of those notes.

I strongly suggest that any, old or new, software developer that hasn't gotten the chance to read this book yet, should take the time and do it. It provides worthwhile and interesting information on what it means to be a professional software developer.

Disclaimer; Please note, as always different people interpret different things. This my interpretation of what is said in the book.

Update: After posting this blog entry, I have noticed it is getting quite a lot Reddit users with mixed feelings posting their comments and opinions. Some agree with these 9 points, while others don't. If you are into this stuff, it could be interesting to you to read these Reddit comments as well. Maybe even letting your own voice be heard.

As a professional developer, your job is more than just reading requirement specifications and code the software. You should also know where and how the project is being used by the its users in the real world.

This means that if you are working on an accounting software, you should at least have some basic knowledge about accounting. It is not necessary to become an expert in the subject, but a little knowledge helps a big way when solving problems and coming up with solutions.

As a professional developer, you should of course be polite and helpful towards other people. When other people ask for help, you should treat them in the same manner as you wish someone would treat you, if you were stuck. You should always offer help and welcome help from others.

Also, you should not build a wall around yourself or your code. It is important to remember that you don’t own the code, but rather the team does. So instead of dismissing anyone from working in, or even seeing, the code, it should be encouraged. This will help you grow as a developer, since it opens up for feedback, but it also greatly benefits the group and the project itself.

Over time, teams slowly grows better and better as well, resulting in team members will eventually know each others strengths and weaknesses. When this happens the team becomes very efficient on solving issues as a group. Since it takes time to build up a solid team, when a project ends, it is smarter to give the team a new project, rather than disbanding the whole group.

As a professional developer, you take responsibility for your code. It is your job to know what your code does and know that all of the code works. When coding you should always aim to cause no harm in your project, by always aiming to get the error rate as close to zero as possible.

This is done by simple writing tests. Tested code gives you more confident about your work, knowing the fact that what deliver is at top class and checked against errors. Robert C. Martin repentantly says that a great goal is that the QA department should never find bugs. An entire project with tested code also gives the developers more confident to actually do something about smelly code.

Unit and acceptance tests should be done automatically (due to it is significantly cheaper than manually testing) by using a continuous integration system. These tests should be running all the time, every time a developer commits code to the project. If a test breaks, it should be fixed as soon as possible.

Robert C. Martin is also strongly for Test Driven Development. The TDD discipline forces the developer to think about good design and structuring up their code to make it test-friendly. According to Robert C. Martin, it is actually unprofessional not to use TDD.

As a professional developer, it is your responsibility to write high-quality, tested, clean code. This includes knowing design patterns, principles, methods, disciplines and artifacts.

Since the software development industry is changing constantly with new ideas and tools around the next corner, it is also equally important that you keep yourself up to date on new disciples and techniques.

You should also never lower your standards by abandoning your disciplines, even in hectic and stressful situations just to cut time.

As a professional developer, you should always remain calm during hectic and stressful situations. Instead, try and think out the best solution to resolve your situation and the inform your superiors about the situation and ask for their feedback and suggestions.

Acting on panic will most likely just result in making more errors. In emergencies, you could try and pair program with a colleague. Not only will this probably decrease the number of new errors, but pair programming is also a great source of sharing knowledge between team members.

As a professional developer, you should spend time caring for your profession. Just like in any other profession, practice gives performance, skill and experience.

It is your own responsibility to keep training yourself by reading, practicing and learning - actually anything that helps you grow as a software developer and helps you get on board with the constant industry changes.

An important note is this should be done on your own time, not on your employer's. It is not their responsibility to train you, but your own. However, do not mistake this with you should be doing your job during this time. This time should be dedicated for you and your own enjoyment only. You should do anything that interests you. According to Robert C. Martin, if you work 40 hours a week ,you should spend around 20 additional hours enhancing your own profession.

As a professional developer, you should know that being a software developer is a very intellectual and exhausting job. It is important that you don’t overwork yourself, but rather find a balance in life with your job. Being a well rested developer makes you more focused and makes you perform better at work. It also also a great receipt against writer's block.

As a professional developer, you should know the value of time. Your time is expensive and should not be wasted, meaning you should use your time wisely and know things like the the high cost of meetings. Politely decline meetings that do not benefit you, or if your present doesn’t benefit anyone.

Meetings should also have a clear agenda and a goal. If you notice that a meeting is getting boring and does not benefit you anymore, or if the agenda gets abandoned or if the meeting simple gets high-jacked, either request a new topic or politely leave the meeting. You probably have better things to do then remain seated.

As a professional developer should not be afraid to say no. If you know something is unrealistic (such as an estimation, a deadline, a requirement, etc) it is expected from you to speak up. Not most of the time - but all the time.

You shouldn’t even say you can try, as that will give a false impression to everyone that the task is doable, and maybe even worse, it turns you into a liar which can hurt your reputation among your superiors and colleagues. Instead, try and rephrase yourself and explain your concerns. Be clear and specific about the problems and dates and times.

If your superiors refuses to listen to you and does not take no as an answer, you should think about going one step higher. Even though going over someones head might feel uncomfortable, in the end it will deliver the best possible outcome for all involved parties.

According to Robert C. Martin, the definition of an estimate is interpreted by different people. For business people, estimations are commitments. For software developers, estimations are guesses, measured in probability.

You should only do commitments, when you are certain it can be done. When professional commits to something, the provide with a hard number and makes certain the job before the deadline.