Clean Coder

Category: programming. Date read: September 9, 2017. My rating: 5/5. Buy on Amazon.

How to be a professional! Encourages you to take responsibility and be a better professional in this young industry. The examples are great to help you figure out how to communicate better.

Professionalism is all about taking responsibility. — Robert Martin

Don't take pride or honor in something that you won't be held accountable for.

Software is too complex to create without bugs. Unfortunately that doesn't let you off the hook. The human body is too complex to understand in it's entirety, but doctors still take an oath to do no harm. — Robert Martin

You will create bugs, you will make errors. Learn to apologize and be responsible for the bugs you create. Fix them and learn from them.

Increase your confidence in your code by testing it. And then test it again, and up, and down, and from side to side.

Only write code you expect to get executed, not "just-in-case" code. If you expect your code to be executed, write a test for it. Design and write code that's easy to test.

Get 100% coverage with automated tests that you can run whenever you want wherever you want. It's not a suggestion, it's a requirement. It will not catch everything but less coverage can catch less errors, never more.

If you don't get 100% coverage or when automated tests are not enough, your automated test suite must tell you, at the very least, if your system is likely to pass QA tests.

To your knowledge, QA should find nothing. Don't rely on QA to do the testing for you. Whenever a bug passed through you, figure out why and do something to prevent it from happening again.

Never compromise the structure of your code. The structure of your code allows you to be flexible in the future. Compromising it is compromising your future.

This is completely counter to the way most people think about software. They think that making a continuous series of changes to working software is dangerous. No! What is dangerous is allowing the software to remain static. If you aren't flexing it, then when you do need to change it, you’ll find it rigid. — Robert Martin

Always make changes to your code. Make sure that whenever you find that a change is hard to make, refine your design so that the next change will be easier.

Saying "no" and "yes"

Learn how to say "no" to your managers. Professionals are expected to say "no", to aggressively defend your point of view just as managers defends them. Finding the best outcome usually takes negotiation between manager and engineer.

Negotiation involves clearly identifying what everyone wants, being able to do deliver in the given time, removing less wanted or less valuable features and focusing only on the most important parts, if needed.

Negotiation cares more about facts rather than whys. Why something will take more time is a lot less important than the fact that it will take more time. Too many details encourages micromanagement.

Learn how to say "no" specially when the stakes are high. A team player is not someone who says "yes" all the time, but someone who works for the best outcome, helping others as needed.

Never say that you'll try harder. It assumes that you're not already working the best you can. If you say you'll try, most people will interpret it as a commitment.

Learn to recognize the different ways people asks you to try harder:

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. — Robert Martin

Know how much overtime you can effectively apply, where the limit is, and what it will cost. This is a negotiation tool that you can apply if the situation requires it.

The only way to truly say "yes" is if you're unafraid to say "no".

Never leave your professionalism aside to solve a problem quickly. Not being professional is the way you create problems.

Learn to identify non-commitments. A non-commitment usually use ambiguous words such as: need/should, hope/wish, let's.

Learn to identify a commitment. It's composed of three parts: saying you'll do it, meaning it, and then actually doing it. They state a fact or action about what you—not anyone else or something else—will do in the future.

Only commit to things you have full control. If it can't be done, commit to the actions you will do to get you closer.

Raise a flag as soon as you find out you won't be able to make a commitment. If you don't let anyone know, you're not giving anyone a chance to help you follow through your commitment.

Self Improvement

Professionals spend time caring for their profession. — Robert Martin

Be responsible for your career by staying up to date and improving your skills. It's not your employer's responsibility, it's yours.

Study and understand the domain of the solutions you're solving. You should be able to recognize and challenge specification errors.

Plan on working 60 hours a week: 40 hours for your employer and 20 hours for you.

The minimum things you must know are:

Learn things outside of your comfort zone. Learn Prolog and Forth.

Do a simple 10-minute programming exercise in the morning, to warm up, and in the afternoon, to cool down.

Mentor junior engineers. Don't let them flail about unsupervised.

Be humble. Fight off the act of supreme arrogance that comes with programming—creating something out of nothing, building solutions to problems, bringing order into chaos.

Never ridicule others, but accept ridicule when it's deserved and laugh it off when it's not. Never demean others for making a mistake, you can be the next.

Take care of your sleep, health, life, and lifestyle. Professionalism is more about consistency and good 8 hours of work rather than simply working more time.

Programming and Practicing

Coding is an intellectually challenging and exhausting activity. — Robert Martin

Don't code if you're tired or distracted. Rest or eliminate the distractions.

If you're worried or anxious about something, time-block it. Dedicate maybe one hour to solve the issue. Even if it's not solved, you'll probably have reduced how much it distracts you.

Be careful about programming while in the Zone. Even though working in the Zone makes you feel you're going fast, you'll probably lose the big picture and will end up rewriting things.

Conserve your energy and creativity. When you're tired, rest for a while. If you're blocked and the solution doesn't come to you, find a pair partner.

Software development is a marathon, not a sprint. — Robert Martin

TDD works. Get over it.

Your tests are documentation. It's the lowest-level design of the system.

Don't fear cleaning up. Professionalism leads to steadily improving codebases instead of letting them rot.

TDD is the professional option. It is a discipline that enhances certainty, courage, defect reduction, documentation, and design. — Robert Martin

Don't follow a guideline if the guideline does more harm than good.

When performance matters, professionals practice. — Robert Martin

Do programming katas. They are choreographed keystrokes and mouse movements that simulates solving a problem. You should already know the answer.

Practice programming katas to train your brain and fingers how to move and react. Practice until you know several different katas.

Solve a programming kata with a partner. One programmer writes a unit test, and then the other must make is pass. Then reverse the roles.

Practicing is what you do when you aren't getting paid. You do it so that you will be paid, and paid well. — Robert Martin

Acceptance and Testing

Always make sure your communication with other members of the team, and the business, are accurate and healthy.

Consider that customers are not completely sure of what they're asking. As soon as they see something working, they get a better idea of what they want and they will change the requirements. This is not only common but expected.

Clear requirements doesn't necessarily mean precise. The same is true about estimations. There are intrinsic uncertainties.

Work on making the requirements precise only when you're about to start developing it.

Shipping without tests to ship on time, to save face, is irresponsible. It's not thinking on your customer or employer who expects a professional.

There is only one definition of "done": all code is written, all tests pass, and QA and the stakeholders have accepted it.

Acceptance tests are tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done. — Robert Martin

It's your responsibility to drive the requirements all the way to automated acceptance tests. This is work, but it's not more work than defining a manual test plan and definitely less work than repeatedly executing it.

Automated acceptance tests will prevent you from implementing the wrong system and will allow you to know when you're done.

Just as with requirements, write the acceptance tests only when you're about to start developing the requirement.

The role of QA is to work with the business to define the expected behavior of corner and error cases and to do exploratory testing to characterize the true behavior of a system.

Test automation pyramid:

Time Management

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

You are responsible of knowing what to do and how to make effective use of the eight hours you work per day.

Meetings are both necessary and time wasters. The person inviting you to a meeting isn't responsible of managing your time.

Don't attend to meetings without an immediate and significant benefit to the job you're doing right now.

When invited to contribute to a meeting, decide if the loss to your project is worth the benefit to theirs.

If you lose interest in a meeting, leave. Ask, at the opportune moment, if your presence is still necessary.

For every meeting ask about the discussions that will take place, the agenda, the time allotted, and the goal to be achieved.

If an argument isn't solved in five minutes, make a note to follow up on it once the appropriate data is in place and follow up. Willpower doesn't win arguments, data does.

Avoid getting vested in an idea to the point that you can't abandon it.

Don't suggest or agree on working on two projects at the same time. There's no such thing as "half a person".

Estimations

Realize that the business views estimates as commitments while developers view estimates as guesses.

Don't make commitments unless you know you can achieve it. Don't even imply you're committing to something you don't know if you can do.

Make estimates. If needed, communicate the probability distribution of the estimate.

If you are going to commit, provide hard numbers. If not, provide probabilistic estimates.

Trivariate analysis:

With these three values, the expected duration of the task is:

$$\mu = \frac{O + 4N + P}{6}$$

The standard deviation of the probability distribution is:

$$\sigma = \frac{P-O}{6}$$

The estimated duration of a sequence of tasks is:

$$\mu_{sequence} = \sum \mu_{task}$$

And the standard deviation of the probability distribution of a sequence of tasks is:

$$\sigma_{sequence} = \sqrt{\sum \sigma_{task}^2}$$

Pressure

Always stay calm under pressure.

Avoid scenarios that cause pressure. Avoid committing to deadlines that you're not sure you can meet. It's fine to try to help the business when commitments are imposed, but you don't have to accept them.

Resist the temptation to create a mess only to try to go quickly. That never works in the long run.

Choose behaviors that you would follow during a crisis. Realize that your behavior during a crisis is what you truly believe on. Follow your decisions all the time.

Working more hours is not sustainable. Slow down, think the problem through, plot a course of action, and follow it at a reasonable and steady pace.

When the pressure is on, find someone who's willing to pair program with you. If you see someone under pressure, offer to pair program with them.

Collaboration

Your first responsibility is to your employer. Understand why you're writing the code you're writing and how your employer will benefit from it.

Share what you learn. Document what you do.

You may work better alone, but the team doesn't benefit from you working alone. Face each other, hear their frustrations, smell their fear, and offer help. Work as a unit.

Teams are harder to build than projects. Suggest to keep sub-teams working together from project to project.

Be a craftsman:

It's your responsibility to teach and mentor young engineers. Nobody out of college is prepared enough for the industry. Teach consistency, practice, and the skills of being a craftsman.