Hans Rosling was a great author (and a speaker) and he expressed his ideas in a very clear way. One of the great things that open this book, is the test that he gives you at the beginning. It comes to prove you, how little you know about the world we live in. It drives the point home very clearly.
I’ve just finished this interesting book on the biography of cancer. On one hand, it’s a depressing story, as we are still losing many battles. On the other hand, there are many ways that progress have been made and hopefully, we are in a phase (e.g. genomics research and the cost reduction in analyzing DNA) that will bring us more victories. It is a story about the history of research with eureka moments and decades of despair.
The author, Dr Mukherjee does a great job in describing the history from its first documented appearances thousands of years ago (when the Greek historian Herodotus records the story of Atossa the queen of Persia and the daughter of Cyrus, who noticed a lump in her breast.) through the progress in the twentieth century to cure, control, and conquer it to a radical new understanding of its essence.
I found somewhere this encouraging answer he gave to the question “With all that you have learned up to this point, are you hopeful in terms of cancer research and possible cures?” Mukherjee: “I feel pathologically hopeful! The opposite of hopeful is hopeless. How can you be hopeless? Discoveries have occurred, and discoveries are occurring. Look at history, does that mean that every move becomes the most brilliant discovery or the universal cure for cancer? No. But history clearly shows a track record of progress. Medicine is caught in this moment of pulling out from a sea of uncertainty these little pieces that are more certain than others. I often tell fellows and residents, to me there is no discipline we practice as human beings that manage this level of complexity. Not just statistical or scientific complexity, but emotional complexity. That’s what makes it one of the most unbelievably moving professions that exist.”
What are the components that help teams to build quality into their outcomes?
The main goal is to create a baseline that developers could follow and be in a quality level that is well defined and measurable. The main parts to focus on are:
Health monitoring: availability, resilience, etc’.
It was a fun weekend project I did with my kids. We started with a new Pi Zero and in a few hours (of many ‘paths’ to nowhere) we got into the point of having a useful security camera. The useful part is when the camera sends you alerts (email or Telegram messages) when it detects movements.
We open the package and connected the Pi Zero to a USB power, a keyboard, a mouse and monitor. We cut a bit a corner by buying an SD card with NOOBS on it but it wasn’t working (nothing was coming up on the screen when we boot the Pi). So we downloaded a new version from Raspian Jessie 4.4 from NOOBS and install it. Now when we boot the Pi we got a new screen. We open the terminal and typed:
Thanks to @farnamstreet for these great points that he posted on Twitter. It reminded me of a good conversation I had with a friend about the ‘right’ decision and a ‘good’ decision.
A good decision is the best decision you can make based on the evidence at hand at the moment you need to decide. If it will be the ‘right’ one – only time can tell. Btw, it is good to remember that many decisions are reversible. With those types of decisions, you can use a light-weight process. You don’t have to live with the consequences for that long if you can change it (which is easy to say and hard to do). You should improve your skills to recognize quickly that a decision is wrong. When you become good at course correction, you will be able to ‘fail quickly’ and move forward fast. If you wish to get better and increase the odds to have good decisions that turn out on the right side, here is a list of rules to help with the process.
There are many options to improve your software quality. One of the most effective methods is to do code reviews with other developers.
Code reviews are as much a social interaction as a technical best practice. In a healthy engineering culture (egoless), team members engage their peers to improve the quality of their code and increase their productivity. Developers understand that the time they spend looking at a colleague’s code is repaid when other team members examine their own deliverables. These days, most of the companies (e.g. Facebook, Netflix, Google, Amazon, Uber) are embracing it, so it’s another sign that something is working well here.
Why Ask For A Peer Review?
The most basic reason is to find bugs.
If you won’t ask for it, you will miss bugs in your code:
a. Accidental errors – typos or mixing variables.
b. Structural errors – dead code, logic or algorithm bugs, performance or architecture concerns. These are often much easier to spot for an external reviewers the see your work from their perspective.
You preventing from yourself a great way to learn and get better – Committers are motivated by the notion of a viewer who will look over the change request: the committer tends to clean up loose ends, consolidate TODOs, and generally improve the commit.
Your code is not as clear as you think it is nor its testability and readability.
Code reviews are very important not only for developers but also to product managers, test engineers, designers and others. In many cases, developers will be the first ones to see the benefits. It will allow them to move faster and with higher quality. Continue reading →