Albatta kerak bo`ladi !
Tip 4
Provide Options, Don’t Make Lame Excuses
Before you approach anyone to tell them why something can’t
be done, is late, or is broken, stop and listen to yourself. Talk to
the rubber duck on your monitor, or the cat. Does your excuse
sound reasonable, or stupid? How’s it going to sound to your
boss?
Run through the conversation in your mind. What is the other
person likely to say? Will they ask, “Have you tried this…” or
“Didn’t you consider that?” How will you respond? Before you
go and tell them the bad news, is there anything else you can
try? Sometimes, you just know what they are going to say, so
save them the trouble.
Instead of excuses, provide options. Don’t say it can’t be done;
explain what can be done to salvage the situation. Does code
have to be deleted? Tell them so, and explain the value of
refactoring (see Topic 40, Refactoring).
Do you need to spend time prototyping to determine the best
way to proceed (see Topic 13, Prototypes and Post-it Notes)? Do
you need to introduce better testing (see Topic 41, Test to Code,
and Ruthless and Continuous Testing) or automation to prevent
it from happening again?
Perhaps you need additional resources to complete this task. Ormaybe you need to spend more time with the users? Or maybe
it’s just you: do you need to learn some technique or technology
in greater depth? Would a book or a course help? Don’t be
afraid to ask, or to admit that you need help.
Try to flush out the lame excuses before voicing them aloud. If
you must, tell your cat first. After all, if little Tiddles is going to
take the blame….
The Pragmatic Programmer kitobidan olindi
Tip 4
Provide Options, Don’t Make Lame Excuses
Before you approach anyone to tell them why something can’t
be done, is late, or is broken, stop and listen to yourself. Talk to
the rubber duck on your monitor, or the cat. Does your excuse
sound reasonable, or stupid? How’s it going to sound to your
boss?
Run through the conversation in your mind. What is the other
person likely to say? Will they ask, “Have you tried this…” or
“Didn’t you consider that?” How will you respond? Before you
go and tell them the bad news, is there anything else you can
try? Sometimes, you just know what they are going to say, so
save them the trouble.
Instead of excuses, provide options. Don’t say it can’t be done;
explain what can be done to salvage the situation. Does code
have to be deleted? Tell them so, and explain the value of
refactoring (see Topic 40, Refactoring).
Do you need to spend time prototyping to determine the best
way to proceed (see Topic 13, Prototypes and Post-it Notes)? Do
you need to introduce better testing (see Topic 41, Test to Code,
and Ruthless and Continuous Testing) or automation to prevent
it from happening again?
Perhaps you need additional resources to complete this task. Ormaybe you need to spend more time with the users? Or maybe
it’s just you: do you need to learn some technique or technology
in greater depth? Would a book or a course help? Don’t be
afraid to ask, or to admit that you need help.
Try to flush out the lame excuses before voicing them aloud. If
you must, tell your cat first. After all, if little Tiddles is going to
take the blame….
The Pragmatic Programmer kitobidan olindi