The following sections are not from the book but contrived from my own knowledge. Some of the sections were mentioned in the book but I feel they deserve their own space.
54. Keep it Stupid Simple (KISS)
The smartest solution to the problem is not the best one, neither is the most optimized one nor the best looking one. The only solution that can stand the test of time is the simplest one.
“Simplicity is the ultimate sophistication.”
— Leonardo Da Vinci
55. “Select” is not Broken
More often than not, we conclude a tool or dependency to have errors but it’s worth the investigation if we are using it as it was intended by the original developer or if our basic understanding is incorrect.
The First Rule of Programming: It’s Always Your Fault.
56. X-Y Problem
The X-Y Problem, occurs when a person tries to solve a problem on their own, pursues a method that seems like a promising approach, gets stuck, and then asks for help with their chosen method instead of asking for help with the original problem.
57. No Permanent Code
All code, even the one in production will require change in future. Service-oriented architecture enables us to reliably change a part of the project. It honors the EtC principle.
“The only constant in life is change”
— Heraclitus
58. State Coverage vs Code Coverage
At a lot of times developers writing tests strive to get 100% code coverage, forgetting missed states in the pursuit. It’s better to test all the possible states of the code and writing tests before or concurrently with the code allows us to think about more possible states.
59. Blameless Postmortem
A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring.
Never use possessive pronouns like “my” and “your” to avoid making people defend their mistakes.
60. Logs are your best friends
When debugging, it’s important to remember the first step is checking the logs. Follow the logs to narrow down the problem domain and iteratively keep narrowing down to arrive at the problem location for effective debugging — it’s a simple tip but evades many developers.
61. Code responsibility
From security to privacy, all lands at the hands of the developers, it’s important to realize that management does not have inherent understanding of possible damage from lapse. Explain it to them in easy language to have the confidence that your application is safe.
“Do unto others as you would have them do unto you”
— Luke 6:31
I hope you learned something new today. Good Luck with your skill development!
