This chapter is about professionalism—specifically, what it takes to truly be a professional software engineer. It shares key points about taking responsibility.
The author shares an anecdote where he shipped an untested version of a product just to “save face” and be able to say he delivered on time. This was not taking responsibility. The software was not ready and ended up causing bugs for real customers.
Key Takeaways
-
First, Do No Harm
-
Take an oath: “I shall do no harm.” In the software business, this could mean “I will not create bugs.” This ‘oath’ is meant in the same spirit as the Hippocratic Oath for doctors. Just like the human body, software is a complex system, and bugs are bound to happen. However, this doesn’t mean we should just accept them without trying to prevent or fix them.
-
“The fact that writing perfect software is virtually impossible does not mean you aren’t responsible for the imperfections.”
-
QA Should Find Nothing
-
You should release software only when you are confident that QA will find nothing.
-
QA is not meant to be a bug-hunting team for untested code, and it shouldn’t be used that way.
-
Releasing code to QA (or to clients) that you know doesn’t work violates the first rule: “Do No Harm.”
-
You Must Know It Works
-
This section is about testing. The author argues that testing every single line should not be considered unrealistic—it should be the norm.
-
Every line of code you write should be tested. If certain lines seem unnecessary to test, then why are you writing them in the first place?
-
If code is hard to test, it’s because it was designed poorly. The issue is not with the testing—it’s with the design.
-
Do No Harm in Structure
-
“The fundamental assumption underlying all software projects is that software is easy to change. If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on.”
-
If your software isn’t designed to be flexible, change it!
-
Don’t ask for permission—every time you work on a module, make small, lightweight improvements to its structure.
-
Merciless refactoring: Always leave a module cleaner than you found it.
-
Work Ethic
-
“Your career is your responsibility.”
-
Take time outside of work to learn and grow as a professional.
-
Know Your Field
-
The author argues that you should have deep knowledge of your field, even if some of it doesn’t seem immediately applicable.
-
While many things in the software industry have changed, many have not.
-
Here’s a minimum list of things every developer should be familiar with:
-
Design patterns
-
Design principles
-
Methods (Scrum, Lean, etc.)
-
Disciplines (TDD, etc.)
-
Artifacts (UML, structure charts, etc.)
-
Continuous Learning
-
The software industry moves so fast that standing still means falling behind.
-
Would you go to a doctor who never kept up with medical journals? No. Then why should employers hire developers who fail to stay current with industry techniques?
-
Practice
-
Spoiler: Your daily job isn’t practice—it’s performance.
-
The author doesn’t go into specifics here, as there’s a whole chapter on this later.
-
He recommends doing a coding kata or two every day as a warmup and a 10-minute kata as a cooldown exercise.
-
Collaboration
-
You don’t have to spend 100% of your time collaborating, but it’s the second-best way to learn.
-
Mentoring
-
The best way to learn is to teach.
-
Know Your Domain
-
It’s your responsibility to understand the domain you’re programming in.
-
You don’t have to be a domain expert, but you should know the basics. Read a book or two on it. Talk to product managers and customers.
-
The worst kind of unprofessional behavior is coding something you don’t understand.
-
Identify with Your Employer/Customer
-
Your employer’s problems are your problems.
-
Your customer’s problems are your problems.
-
You need to understand these problems to work toward the best solution.
-
Humility
-
“Programming is an act of creation.”
-
A professional should take pride in their work and be confident in their abilities—but also recognize that they will fail and that their skills will sometimes fall short.
-
Accept your failures—and those of others as well.