This is the second article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the second chapter.
Professionals speak truth to power. Professionals have the courage to say no to their managers. But how do you say no to your boss? After all, it's your boss! Aren't you supposes to do what your boss says?
No. Not if you are a professional.
Adversarial roles
Managers are people with a job to do, and most managers know how to do that job pretty well. Part of that job is to pursue and defend their objectives as aggressively as they can.
By the same token, programmers are also people with a job to do. If they are professionals they will pursue and defend their objectives as aggressively as they can too.
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 it's impossible to be done by tomorrow, 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".
But don't you have to do what your manager says? No, your manager is counting on you to defend your objectives as aggressively as he defends his. That's how the two of you are going to get to the best possible outcome, which is the goal that you and your manager share. The trick is to find the goal, and that usually takes negotiation.
High stakes
The most important time to say no is when the stakes are highest. The higher the stakes, the more valuable no becomes.
This should be self-evident. 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.
Being a "team player"
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. A team player communicates frequently, keeps an eye out of his or her teammates, and executes his or her own responsibilities as well as possible.
A team player is not someone who says yes all the time.
Trying
Yoda is right. Perhaps you don't like that idea? Perhaps you think trying is a positive thing to do. After all, would Columbus have discovered America if he hadn't tried?
The word try has many definitions. The definition I take issue with here is "to apply extra effort".
The promise to try is an admission that you've been holding back, that you have a reservoir of extra effort that you can apply. The promise to try is an admission that the goal is attainable through the application of his extra effort; moreover, it is a commitment to apply that extra effort to achieve the goal. Therefore, by promising to try you are committing to succeed; This puts the burden on you. If your "trying" does not lead to the desired outcome, you will have failed.
If you are not holding back some energy in reserve, if you don't have a new plan, if you aren't going to change your behavior, and if you are reasonably confident in your original estimate, then promising to try is fundamentally dishonest. You are lying. And you are probably doing it to save face and avoid a confrontation.
The cost of saying yes
Most of the time we want to say yes. Indeed, healthy teams strive to find a way to say yes. Managers and developers in well-run teams will negotiate with each other until they come to a mutually agreed-upon plan of action.
But, as we've seen, sometimes the only way to get to the right yes is to be unafraid so say no.
Is good code impossible?
Every feature a client asks for will always be more complex to write than it is to explain. Clients and managers have figured out how to get developers to write code quickly (not effectively, but quickly):
- Tell developers the app is simple
- Add features by faulting the team for not recognizing their necessity
- Push the deadline. Over and over
In this dysfunction, it isn't only the code that will suffer.
Professionals are often heroes, but not because the 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, you are not acting like a professional.
Saying yes to dropping our professional disciplines is not the way to solve problems. Dropping those disciplines is the way you create problems.
Is good code impossible? Is professionalism impossible?
I say no.
Top comments (1)
I made this account just so I could complain about how unbearably distracting the amount of GIFs in this article are.