The idea of the Kata is to do it over and over again. The reason we do this... the red, green, refactor... is so that when my boss comes to me and says "Jim, I need this fixed in a day... can you get this done by this afternoon?" And I don't panic and just start writing random code, because I've got the discipline of practicing the TDD over, and over, and over again, it's actually much faster for me to fall into the good habits that I've developed by practicing the katas then to fall out of them and ignore all the good things that I know about how to develop software. That's the real purpose of the kata.
SARON: One of the things that we started doing, I think, a few weeks ago is we started having these evening study sessions. So we have on Monday, we do Ruby. On Tuesday, we have JavaScript. On Thursday, we have Python. What we started doing is having team projects. The whole code review, pull request, team collaboration part is the focus of those projects. So JavaScript is doing like a Hangman game which is relatively simple but in the process of doing that, like we have a tally board and we're organizing our feature cards by priority. You have to get the thumbs up before you can merge in your pull request. And for a lot of people who've been mostly learning on their own and doing things there just by themselves, it's a really interesting opportunity to say, "Okay, now I have to know what a pull request is and how to name my branches and how to respond and how to communicate." We do that exactly for that reason. It's a huge skill. The thing there is just knowing how to code and good design patterns and that but then working on a team collaboratively to ship a product is a whole other skillset that I think is hard to pick up when you're learning on your own.
DAVID: That's fantastic, to pick a simple project and just put in all of the process and the overhead where yeah, you're basically just practicing the process in the overhead.
SARON: Exactly.
DAVID: The code itself is pretty simple. There's a really good motto that I heard about a year ago and it just keeps coming up over and over again. Of all places, I think it's from the Navy Seals but the motto is 'Go Slow to Go Smooth, Go Smooth to Go Fast'. And I really liked that motto of let's take some code where we're not panicking, we're not trying to get this shipped to keep the company from going bankrupt. All we're trying to do is just practice our process and make sure that everything is going out and coming back right in the way it needs to do. Once you start to get in the habit of write the code, push the commit, ask for the PR, wait for the LGTM, then merge the code. Yeah, now you start to get smooth and now you can start to go fast.
In some ways mdpg is a simple project, but I'm "practicing the process" by cargo culting the process. Do every idea I've seen, but do it on a small project so I can easily adopt the new processes without burning out on the project.