I’m often asked some questions that I would like to share with you.
Disclaimer: I don’t have an answer for every question (those are not included here). And I ask a lot of questions as well.
One test class per production class?
I think that I didn’t have a good answer for this frequent question until my apprenticeship in Codurance London. Every session with Sandro Mancuso was eye-opening.
Let’s see what happens:
If we write production code and then we write test code, test code will be focused on implementation. Therefore, every change in production code organization will cause another change in test code and vice versa.
If we write test code and then we write production code, test code will be focused on behaviour or intention. Therefore, code organization changes can be made independently.
The first situation is the case of “one test class per production class”. Not only it’s an uncomfortable situation, but also test code doesn’t communicate.
Dijkstra wrote in The Humble Programmer (1972): “Today a usual technique is to make a program and then to test it. (…) The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. (…) If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.”
Why do you waste time with katas? The real world is absolutely different
Yes, it’s true, our professional experiences are very different, but katas can help us:
- To learn new concepts.
- To try new IDE features.
- To develop confidence in our ability solve problems.
- To improve our decision-making process when realizing the consequences.
- To simulate business interaction (there are incremental katas which add complexity at every step).
You advocate questioning all the things, but there are things that cannot be questioned like trunk-based development or TDD
I advocate questioning all the things in this way:
- Why is this thing convenient for our project?
- Which are the benefits?
- Which are the drawbacks?
- How must we prepare ourselves for it?
- How can we improve it?
And I like to make decisions based on information beyond “this big company works in this way” or “X told that this practice is the best”.
What’s better? X or Y?
I find it difficult to choose the best thing, because everything has benefits and drawbacks depending on the context. The best thing for me is trying each option and analysing the feedback from it.
Which tool do you recommend for X?
I usually answer this question with another question: what do you want to achieve?
Remember that I don’t know everything, so I answer with that question when I know about X.
I love a thread by Christoph Neuroth in Twitter which starts with: “So you’re adopting a technical practice. Don’t start from the tools. Start with a dictionary.”
The success of a tool depends on us. For example, Jira is one of the most customizable tools that I know and it can be a pain or a help depending on its customization. That’s the reason why it’s useful to know what we need before choosing the tool.
How do you have time to know so many things?
I know some things and I continue learning and improving most of them.
There are a lot of things that I don’t know or I will never know. This is a long journey and I’m in no hurry, because I like to enjoy it.
I follow these personal principles:
- Be willing to share: some things can only be learnt by sharing.
- Be willing to face new challenges: some things can only be learnt from the experience.
- “If you compare yourself with others, you may become vain or bitter, for always there will be greater and lesser persons than yourself” (Desiderata by Max Ehrmann). Therefore, don’t compare yourself with others, because you’ll always find people who know things that you don’t know and vice versa.
And I think my value is in what I can do with what I know. So, I don’t only focus on learning new concepts, practices or technologies, but also I focus on being a good “player” with all those things.
How did you get your capacity for creativity?
I don’t consider myself to be especially creative. Perhaps it comes from my desire to make things easier and funny, but creativity can be nurtured:
- Consuming different resources (books, documentaries, cinema, radio) about different topics, not only about our profession.
- Being humble and thinking that there will be always new things to learn and improve.
- Leaving our comfort zones.
- Having a basis of fundamentals on which to build other things.
- Making mistakes.
- Sharing our thoughts.
- “Affording to be a child again, with all the accumulated experience.” - Bibiana Ballbè
- Travelling and knowing other cultures.
- Having a public library card. You can find some hidden treasures.
Why do you read old books or articles from the seventies? There are more modern books
When Isaac Newton was asked for his discoveries, he said: “If I have seen further it is by standing on the shoulders of Giants” (that metaphor comes from Bernard of Chartres). He referred to Copernicus, Galileo, Kepler and all the physicists who were explaining the firmament.
No, I don’t want to make discoveries ;)
We don’t only have legacy code, but also legacy documentation and we can learn a lot of things from Dijkstra or Fred Brooks, among others.
This is the last paragraph in the acknowledgements section of the book “Test-Driven Development By Example” written by Kent Beck: “Finally, to the unknown author of the book which I read as a weird 12-year-old that suggested you type in the expected output tape from a real input tape, then code until the actual results matched the expected result, thank you, thank you, thank you”.--