Alexandre Lim

The Clean Coder is an excellent follow-up to Clean Code. This book is less technical but touches more on skills other than coding. Yes, software development is much more than just the ability to write lines of code. It's about attitude and a long journey of dedication to a craft.

Notes

Professionalism is a marker of responsibility and accountability. When a professional makes a mistake, he cleans up the mess.

You must be able to make changes without exorbitant costs. If you want your software to be flexible, you have to flex it! Always make some random act of kindness to the code whenever you see it. What is dangerous is allowing the software to remain static.

Your career is your responsibility. Woe to the software developer who entrusts their career to their employer. Professionals spend time caring for their profession.

Professionals practice. True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.

Professional software developers make a special effort to program together, practice together, design and plan together.

Professionals take personal responsibility for mentoring juniors.

It is the responsibility of every software professional to understand the domain of the solutions they are programming.

Your employer’s problems are your problems. You need to understand what those problems are and work toward the best solutions.

Programming is an act of supreme arrogance. Professionals are confident in their abilities but stay humble. They will never ridicule others but will accept ridicule when it is deserved and laugh it off when it’s not. They will not demean another for making a mistake because they know they may be the next to fail.

Professionals will pursue and defend their objectives as aggressively as they can. They know to say no and search for the best possible outcome. Explaining why is a lot less important than the fact. Providing too much detail can be an invitation for micro-management.

The most important time to say no is when the stakes are highest. The higher the stakes, the more valuable no becomes.

Being a team player means playing your position as well as you possibly can and helping out your teammates when they get into a jam.

Healthy teams strive to find a way to say yes. But sometimes, the only way to get to the right yes is to be unafraid to say no.

There are three parts to making a commitment.

There are very few people who, when they say something, they mean it and then actually get it done. We should look at the language we use when we commit to doing something, as the telltale sign of things to come.

The real truth is that you, personally, ALWAYS have something that’s under your control, so there is always something you can fully commit to doing.

Real commitment sounds like this: I will ... by ...

If you can’t make your commitment, the most important thing is to raise a red flag as soon as possible to whoever you committed to.

Professionals know their limits. They know how much overtime they can effectively apply, and they know what the cost will be.

The key to mastery is confidence and error-sense.

When you cannot concentrate and focus sufficiently, the code you write will be wrong. If you are tired or distracted, do not code. Dedication and professionalism are more about discipline than hours.

Sometimes the code just doesn’t come. The solution: Find a pair partner.

Creative output depends on creative input.

Software development is a marathon, not a sprint. A marathon runner takes care of her body both before and during the race.

When you are stuck, when you are tired, disengage for a while. Give your creative subconscious a crack at the problem.

You will be late. It happens to the best of us. It happens to the most dedicated of us. The trick to managing lateness is early detection and transparency. Regularly measure your progress against your goal, and come up with three fact-based end dates: best case, nominal case, and worst case. Do not incorporate hope into your estimates! Hope is the project killer. Hope destroys schedules and ruins reputations.

Do not be tempted to rush. Reduce the scope.

You should not agree to work overtime unless you can personally afford it, it is short term, two weeks or less, and your boss has a fall-back plan in case the overtime effort fails.

Programming is so hard, in fact, that it is beyond the capability of one person to do it well. No matter how skilled you are, you will certainly benefit from another programmer’s thoughts and ideas.

Remember, just as you are honor bound to offer help, you are honor bound to accept help.

The tests you write after the fact are defense. The tests you write first are offense. For all its good points, TDD is not a religion or a magic formula. There are times when following TDD is simply impractical or inappropriate. No professional developer should ever follow a discipline when that discipline does more harm than good.

Professional programmers often suffer from a lack of diversity in the kinds of problems that they solve. It is not uncommon to be unprepared for the changes that periodically sweep the industry. Solutions: Open source and practice on your own time.

The role of the professional developer is a communication role as well as a development role. One of the most common communication issues between programmers and business is the requirements.

Both business and programmers are tempted to fall into the trap of premature precision. But, the more precise you make your requirements, the less relevant they become as the system is implemented.

Professional developers understand that estimates can, and should, be made based on low precision requirements, and recognize that those estimates are estimates.

The purpose of acceptance tests is communication, clarity, and precision. Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code.

Acceptance tests are written by the business for the business. They are formal requirements documents that specify how the system should behave from the business’ point of view. The audience is the business and the programmers.

Unit tests and acceptance tests are documents first, and tests second. Their primary purpose is to formally document the design, structure, and behavior of the system.

There are two truths about meetings.

The person inviting you to a meeting is not responsible for managing your time. Only you can do that. When the meetings get boring, leave. (There’s no need to be rude)

One of the most important duties of your manager is to keep you out of meetings.

Stand-up meetings:

Technical disagreements tend to go off into the stratosphere. The only thing to do is to go get some data. But sometimes, the best alternative is to simply flip a coin to choose one of the options. Some folks will be passive-aggressive. They’ll agree just to end the argument, and then sabotage the result by refusing to engage in the solution. Never, ever do this. If you agree, then you must engage.

Blind alleys are a fact of life for all software craftsmen. Sometimes you will make a decision and wander down a technical pathway that leads to nowhere. The real skill you need is to quickly realize when you are in one, and have the courage to back out.

Nothing has a more profound or long-lasting negative effect on the productivity of a software team than a mess. Nothing.

Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound. Professionals draw a clear distinction between estimates and commitments. They do not commit unless they know for certain they will succeed. They are careful not to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible.

Professional developers are calm and decisive under pressure. As the pressure grows, they adhere to their training and disciplines, knowing that they are the best way to meet the deadlines and commitments that are pressing on them.

The way to go fast, and to keep the deadlines at bay, is to stay clean. Professionals do not succumb to the temptation to create a mess in order to move quickly.

Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Don’t change your behavior when the crunch comes. If your discipline are the best way to work, then they should be followed even in the depths of a crisis. When things get tough, trust your disciplines.

Most software is created by teams. Teams are most effective when the team members collaborate professionally. It is unprofessional to be a loner or a recluse on a team.

It’s good to be passionate about what we do. But it’s also good to keep your eye on the goals of the people who pay you.

One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around their code and refuses to let other programmers touch it. This is a recipe for disaster. The team should own the code, not the individuals.

The most efficient and effective way to review code is to collaborate in writing it.

Programming is all about working with people.

Teams are harder to build than projects.

You can’t convince people to be craftsmen. You act as a role model. You become a craftsman first, and let your craftsmanship show.