More on this book
Community
Kindle Notes & Highlights
Started reading
March 9, 2018
How does a professional behave? • How does a professional deal with conflict, tight schedules, and unreasonable managers?
When, and how, should a professional say “no”? • How does a professional deal with pressure?
As an engineer, you have a depth of knowledge about your systems and projects that no managers can possibly have. With that knowledge comes the responsibility to act.
What would happen if you allowed a bug to slip through a module, and it cost your company $10,000? The nonprofessional would shrug his shoulders, say “stuff happens,” and start writing the next module. The professional would write the company a check for $10,000!1
Yeah, it feels a little different when it’s your own money, doesn’t it? But that feeling is the feeling a professional has all the time. Indeed, that feeling is the essence of professionalism. Because, you see, professionalism is all about taking responsibility.
Do No Harm to Function
We harm the function of our software when we create bugs. Therefore, in order to be professional, we must not create bugs.
The fact that the task to write perfect software is virtually impossible does not mean you aren’t responsible for the imperfection.
Indeed, some companies reward QA based on the number of bugs they find. The more bugs, the greater the reward.
Releasing code to QA that you don’t know works is unprofessional. It violates the “do no harm” rule.
The solution to that is to design your code to be easy to test. And the best way to do that is to write your tests first, before you write the code that passes them.
You must be able to make changes without exorbitant costs.
merciless refactoring.
Why do most developers fear to make continuous changes to their code? They are afraid they’ll break it! Why are they afraid they’ll break it? Because they don’t have tests.
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.
If you use your lunch hour to read, listen to podcasts on your commute, and spend 90 minutes per day learning a new language, you’ll have it all covered.
Do the math. In a week there are 168 hours. Give your employer 40, and your career another 20. That leaves 108. Another 56 for sleep leaves 52 for everything else.
Here is a minimal list of the things that every software professional should be conversant with:
Professionals speak truth to power. Professionals have the courage to say no to their managers. How do you say no to your boss? After all, it’s your boss! Aren’t you supposed to do what your boss says? No. Not if you are a professional. Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done.
The best possible outcome is the goal that you and your manager share. The trick is to find that goal, and that usually takes negotiation.
What we all have to realize is that saying yes to dropping our professional disciplines is not the way to solve problems. Dropping those disciplines is the way you create problems.
There are three parts to making a commitment. You say you’ll do it. You mean it. You actually do it.
The secret ingredient to recognizing real commitment is to look for sentences that sound like this: I will . . . by . . . (example: I will finish this by Tuesday.)
If it can’t be done, you can still commit to actions that will bring you closer to the target.
If you committed to solving a bug you thought was solvable and you realize at some point the bug is much more hideous than previously thought, you can raise the flag.
If you don’t tell anyone about the potential problem as soon as possible, you’re not giving anyone a chance to help you follow through on your commitment.
It’s easy to say you’ll get a lot done on the weekends, it’s a lot harder to actually muster enough energy to do high-quality work. Professionals know their limits. They know how much overtime they can effectively apply, and they know what the cost will be.
We never had time to rewrite this wad
The moral of this story is: Don’t write code when you are tired.
Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.
Professional developers allocate their personal time in order to ensure that the time spent at the office is as productive as possible.
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.
There is something about disengagement that allows your mind to hunt for solutions in a different and more creative way.
The trick to managing lateness is early detection and transparency.
Be as honest as you can about all three dates. Do not incorporate hope into your estimates! Present all three numbers to your team and stakeholders. Update these numbers daily.
Woe to the poor developer who buckles under pressure and agrees to try to make the deadline. That developer will start taking shortcuts and working extra hours in the vain hope of working a miracle.
you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails.
If your boss cannot articulate to you what he’s going to do if the overtime effort fails, then you should not agree to work overtime.
It is a violation of professional ethics to sequester yourself in a cubicle or office and refuse the queries of others. Your work is not so important that you cannot lend some of your time to help others.
a fresh perspective can be a profound catalyst for solving problems.
it is a matter of professional ethics for senior programmers to spend time taking younger programmers under their wing and mentoring them. By the same token, those younger programmers have a professional duty to seek out such mentoring from their seniors.
How can you consider yourself to be a professional if you do not know that all your code works? How can you know all your code works if you don’t test it every time you make a change? How can you test it every time you make a change if you don’t have automated unit tests with very high coverage? How can you get automated unit tests with very high coverage without practicing TDD?
The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
If you don’t write your tests first, there is no force preventing you from coupling the functions together into an untestable mass.
Following the three laws does not guarantee any of these benefits. You can still write bad code even if you write your tests first. Indeed, you can write bad tests.
Programmers can practice in a similar fashion using a game known as ping-pong.8 The two partners choose a kata, or a simple problem. One programmer writes a unit test, and then the other must make it pass. Then they reverse roles.
In the end, 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.
“An ambiguity in a requirements document represents an argument amongst the stakeholders.”
Professional developers have a single definition of done: Done means done. Done means all code written, all tests pass, QA and the stakeholders have accepted. Done.
