Me gustaría compartir la review de otro libro que ha caído esta semana. En realidad, son es una colección de 2 libros de Robert C. Martin que te puedes comprar en formato Kindle por 15,99 € (dos libros de Robert C. Martin por ese precio ya vale la pena), el pack lo podéis encontrar en amazon. En este post (de una serie de dos) os quiero hablar de “The Clean Coder”.

El libro está genial, la verdad, es un 10 sobre 10. Creo que va a marcar un pequeño antes y después en mi carrera. En resumen, habla sobre la diferencia entre un profesional del desarrollo del software y uno que no lo es repasando todos los aspectos del ecosistema, desde el código (nomenclatura, estilo, etc.), gestión del tiempo, gestión de la carrera profesional, compañerismo, etc. Si sois apasionados de lo que hacemos, os encantará.

Os dejo una serie de ideas que he subrayado del libro y que me parecieron interesantes, o por desconocer o por la claridad de la explicación. Que lo disfrutéis y si os gustan, os recomiendo que compréis el pack (aunque no tengáis Kindle físico, os podéis descargar su aplicación para iPhone, iPad o Mac aquí).

Professionalism is all about taking responsibility.

The fact that bugs will certainly occur in your code does not mean you aren’t responsible for them. The fact that the task to write perfect software is virtually impossible does not mean you aren’t responsible for the imperfection.

It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And what code do you know to be faulty? Any code you aren’t certain about!

How can you know your code works? That’s easy. Test it. Test it again. Test it up. Test it down. Test it seven ways to Sunday!

In short: You must be able to make changes without exorbitant costs.

If you want your software to be flexible, you have it!

Professional developers are so certain of their code and tests that they are maddeningly casual about making random, opportunistic changes. They’ll change the name of a class, on a whim. They’ll notice a long-ish method while reading through a module and repartition it as a matter of course. They’ll transform a switch statement into polymorphic deployment, or collapse an inheritance hierarchy into a chain—of—command. In short, they treat software the way a sculptor treats clay—they continuously shape and mold it.

Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer. Some employers are willing to buy you books and send you to training classes and conferences. That’s fine, they are doing you a favor. But never fall into the trap of thinking that this is your employer’s responsibility. If your employer doesn’t do these things for you, you should find a way to do them yourself.

Here is a minimal list of the things that every software professional should be conversant with:

– Design patterns. You ought to be able to describe all 24 patterns in the GOP book and have a working knowledge of many of the patterns in the POSA books.

– Design principles. You should know the SOLID principles and have a good understanding of the component principles.

– Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.

– Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.

– Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Woe to the architects who stop coding—they will rapidly find themselves irrelevant. Woe to the programmers who stop learning new languages—they will watch as the industry passes them by. Woe to the developers who fail to learn new disciplines and techniques—their peers will excel as they decline.

Read books, articles, blogs, tweets. Go to conferences. Go to user groups. Participate in reading and study groups. Learn things that are outside your comfort zone.

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.

The point of doing the kata is not to figure out how to solve the problem; you know how to do that already. The point of the kata is to train your fingers and your brain.

The best way to learn is to teach.

Professionals take personal responsibility for mentoring juniors. They will not let a junior flail about unsupervised.

It is the responsibility of every software professional to understand the domain of the solutions they are programming. If you are writing an accounting system, you should know the accounting field.

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

When your manager tells you that the login page has to be ready by tomorrow, he is pursuing and defending one of his objectives. He’s doing his job. If you know full well that getting the login page done by tomorrow is impossible, then you are not doing your job if you say “OK, I’ll try.” The only way to do your job, at that point, is to say “No, that’s impossible.”

The why is a lot less important than the fact. That fact is that the login page will require two weeks. Why it will take two weeks is just a detail.

Still, knowing why might help Mike to understand, and therefore to accept, the fact.

When the cost of failure is so high that the survival of your company depends upon it, you must be absolutely determined to give your managers the best information you can. And that often means saying no.

A team-player communicates frequently, keeps an eye out for his or her teammates, and executes his or her own responsibilities as well as possible.

Professionals are often heroes, but not because they try to be. Professionals become heroes when they get a job done well, on time, and on budget. By trying to become the man of the hour, the savior of the day, John was not acting like a professional.

There are three parts to making a commitment: 1. You say you’ll do it. 2. You mean it. 3. You actually do it.

Professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make “yes” possible. When professionals say yes, they use the language of commitment so that there is no doubt about what they’ve promised.

Don’t write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.

Avoid the Zone. This state of consciousness is not really hyperproductive and is certainly not infallible. It’s really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed.

One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone.

There are times when the Zone is exactly where you want to be. When you are practicing.

So the professional attitude is a polite willingness to be helpful.

Debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good.

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.

Your work is not so important that you cannot lend some of your time to help others. Indeed, as a professional you are honor bound to offer that help whenever it is needed.

The training of less experienced programmers is the responsibility of those who have more experience. Training courses don’t cut it. Books don’t cut it. Nothing can bring a young software developer to high performance quicker than his own drive, and effective mentoring by his seniors.

In one way or another, all professionals practice. They do this because they care about doing the best job they possibly can. What’s more, they practice on their own time because they realize that it is their responsibility—and not their employer’s— to keep their skills sharp. Practicing is what you do when you aren’t getting paid. You do it so that you will be paid, and paid well.

Professional developers understand that estimates can, and should, be made based on low precision requirements, and recognize that those estimates are estimates. To reinforce this, professional developers always include error bars with their estimates so that the business understands the uncertainty.

We will define acceptance tests as tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.

You do not have to attend every meeting to which you are invited. Indeed, it is unprofessional to go to too many meetings. You need to use your time wisely. So be very careful about which meetings you attend and which you politely refuse.

Sometimes the meeting will be about something that you can contribute to but is not immediately significant to what you are currently doing. You will have to choose whether the loss to your project is worth the benefit to theirs. This may sound cynical, but your responsibility is to your projects first. Still, it is often good for one team to help another, so you may want to discuss your participation with your team and manager.

When the meeting gets boring, leave.

Professional developers learn to manage their time to take advantage of their focus-manna. We write code when our focus-manna is high; and we do other, less productive things when it’s not.

Professionals evaluate the priority of each task, disregarding their personal fears and desires, and execute those tasks in priority order.

Professionals avoid getting so vested in an idea that they can’t abandon it and turn around. They keep an open mind about other ideas so that when they hit a dead end they still have other options.

Software professionals are diligent in the management of their time and their focus. They understand the temptations of priority inversion and fight it as a matter of honor. They keep their options open by keeping an open mind about alternate solutions. They never become so vested in a solution that they can’t abandon it. And they are always on the lookout for growing messes, and they clean them as soon as they are recognized. There is no sadder sight than a team of software developers fruitlessly slogging through an ever-deepening bog.

A commitment is something you must achieve. If you commit to getting something done by a certain date, then you simply have to get it done by that date.

An estimate is a guess. No commitment is implied. No promise is made. Missing an estimate is not in any way dishonorable.

Professional software developers know how to provide the business with practical estimates that the business can use for planning purposes. They do not make promises that they can’t keep, and they don’t make commitments that they aren’t sure they can meet.

When professionals make commitments, they provide hard numbers, and then they make those numbers. However, in most cases professionals do not make such commitments. Rather, they provide probabilistic estimates that describe the expected completion time and the likely variance.

Professional developers work with the other members of their team to achieve consensus on the estimates that are given to management.

The best way to stay calm under pressure is to avoid the situations that cause pressure.

Professionals will always help the business find a way to achieve its goals. But professionals do not necessarily accept commitments made for them by the business.

The way to go fast, and to keep the deadlines at bay, is to stay clean.

If in a crisis you follow your disciplines, then you truly believe in those disciplines. On the other hand, if you change your behavior in a crisis, then you don’t truly believe in your normal behavior.

Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Following these disciplines is the best way to avoid getting into a crisis.

The trick to handling pressure is to avoid it when you can, and weather it when you can’t. You avoid it by managing commitments, following your disciplines, and keeping clean. You weather it by staying calm, communicating, following your disciplines, and getting help.

Professional programmers take the time to understand the business. They talk to users about the software they are using. They talk to sales and marketing people about the problems and issues they have. They talk to their managers to understand the short- and long-term goals of the team.

There is no such thing as half a person.

Teams are harder to build than projects. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. The goal in forming a team is to give that team enough time to gel, and then keep it together as an engine for getting many projects done.

A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.

You become a craftsman first, and let your craftsmanship show. Then just let the meme do the rest of the work.

• clean coder
• robert c martin