Yes, that's the problem - the translation gap. That's why often the developers don't know how to apply TDD to the real world project, or they try to apply but do it in a wrong way due to wrong inference.
I think they are very useful, I think it can also be done progressively and this is an example of how I do it, and obviously at the end there is a pet project.
Emmanuel, yes, they are useful as the building blocks of a skill set; just like in soccer, the players learn how to run, how to dribble the ball, how to hit the ball - repeat this many times, that's like katas. Then after that, they need to play the game as practice (like a sandbox project).
How did you decide the sequence of the katas? Also, could you elaborate more on the pet project?
This was my learning process back in the day, and it also served as the framework through which I mentored my colleagues at Codurance. This approach was validated with Mashooq Badar, one of Codurance’s founders alongside Sandro, as it was also the learning process he followed at the time too.
The methodology is designed with a focus on algorithmic problems, where design naturally emerges, leading you to understand the concept of "just enough design." Eventually, it progresses to more "realistic" katas. Once this circuit is completed, participants are expected to undertake a pet project incorporating everything they’ve learned, deploying it to the cloud and covering the entire process from scratch to deployment.
The pet project: we align the needs of the people learning and the client
This is why 'TDD in Legacy Code' is a required subject for everyone nowadays. Not using automated testing to guarantee your software quality is a big problem. However, problems, unlike situations, have solutions.
Yes, as you mentioned, the absence of automated testing is a huge problem. It's a deep core problem. Companies are focusing on the wrong things (tech stack, libraries, latest versions, switching from one library to a "better" one, etc.) but ignoring the fundamentals.
Katas are ok for learning basics, but don't prepare developers for real-world complexities.
Yes, that's the problem - the translation gap. That's why often the developers don't know how to apply TDD to the real world project, or they try to apply but do it in a wrong way due to wrong inference.
https://www.figma.com/board/FCmGwRPIO8cLowDRraJhgr/Learning-TDD?fuid=994918187711519377
I think they are very useful, I think it can also be done progressively and this is an example of how I do it, and obviously at the end there is a pet project.
Emmanuel, yes, they are useful as the building blocks of a skill set; just like in soccer, the players learn how to run, how to dribble the ball, how to hit the ball - repeat this many times, that's like katas. Then after that, they need to play the game as practice (like a sandbox project).
How did you decide the sequence of the katas? Also, could you elaborate more on the pet project?
This was my learning process back in the day, and it also served as the framework through which I mentored my colleagues at Codurance. This approach was validated with Mashooq Badar, one of Codurance’s founders alongside Sandro, as it was also the learning process he followed at the time too.
The methodology is designed with a focus on algorithmic problems, where design naturally emerges, leading you to understand the concept of "just enough design." Eventually, it progresses to more "realistic" katas. Once this circuit is completed, participants are expected to undertake a pet project incorporating everything they’ve learned, deploying it to the cloud and covering the entire process from scratch to deployment.
The pet project: we align the needs of the people learning and the client
Thanks for sharing the learning process. If you write any article on Substack to describe this progression, feel free to comment back here.
This is why 'TDD in Legacy Code' is a required subject for everyone nowadays. Not using automated testing to guarantee your software quality is a big problem. However, problems, unlike situations, have solutions.
Yes, as you mentioned, the absence of automated testing is a huge problem. It's a deep core problem. Companies are focusing on the wrong things (tech stack, libraries, latest versions, switching from one library to a "better" one, etc.) but ignoring the fundamentals.