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.
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.
A few typos:
"An important note is this should be done on your own time, not on your employees" - I think you mean "employer".
"it turns you into a lair" - I think you mean "liar"
Is this a joke? This is a basic rule set for being a human being.
if i dont own the code, why should i take responsibility for it?
I'm a dev, too, and I agree 100%. These are all of the ways in which a developer adds value to a business.
Plus, as argon99 said (but in a more professional way :), you could replace "developer" with any role where one should act professionally, e.g musician, plumber, stock trader, every other job.
Some people just need this spelled out.
"Is this a joke? This is a basic rule set for being a human being." -- ha, you say that like programmers are normal human beings.
Great list, but wrt #6, you should not hesitate to practice your profession on your employers time. It is mutually beneficial for you to do this. However, you must place your responsibilities to your project before your practicing.
If you're working for someone who does not encourage you to practice your profession, start looking for another job where they do. You're not working for someone who values you or your abilities.
Sorry blokespeed, but if you aren't professional enough to take responsibility for the code on which you work and the subsystems that make up your parts of the code, then you haven't become a professional yet.
As one example, a company for whom I worked recently had a section of code for creature creation that was 1350 lines of code long... in a single function. This was due to three years of no one owning the code and it was barely decipherable. I touched it a few times and finally said "I will fix this shit if it's the last thing I do" and in my spare time over the next week, I broke it into 18 separate functions and reduced the number of lines of the main function to a little under 350. In addition, the process initially broke a few things but then fixed 6 "mysterious" bugs where creatures were not created properly.
When people decide that they don't own the code, that's when either your process is broken or you are not professional.
Nice list thanks, but aren't 6 and 7 sort of mutually exclusive? ("A professional developer keeps practicing their profession" and "A professional developer rests")...
how does this book relate to "Clean Code" the other book of Martin?
@betto "Clean Code" is like a prequel of "The Clean Coder" one.
The Clean Code book is more a book of examples; "This is bad, don't do this and here is why." about very code detailed things, such as, writing code comments.
The Clean Coder is more a guide book on how, according to the author, a professional developer should conduct.
Eventhough some people don't agree with everything he says, it's still a book worth reading :-)
Apparently a professional developer does not have children. ;)
I started to read it, and I'm really enjoying it! :)
I just searching this kind of things in search engines. My searching was ending here. Keep up your good work. I bookmarked it for general updates.