What is a Coding Dojo?
A Coding Dojo is a place / meeting for programmers to engage together on deliberate practice of their craft. Expect to do Test Driven Development, Pair Programming and other practices well known from Agile development methodologies together with other people.
It’s meant to be fun and to help everyone improve their coding skills.
All skill levels are welcome.
When and where
December 18th, 2014 — 18:30 at Base Lab, ul. Leona Wyczółkowskiego 7, Kraków, Poland
Please register at: http://pydojo-krk-dec-2014.eventbrite.com
In the very first minutes we will give a brief introduction explaining how the process work, with very few rules, and then we start coding.
Do not bring your computer, you don’t need it, and it would be just one more distraction in the era of smartphones and everyone always connected...
A bit of context
It all began with the question "why programmers do not practice?" If you look at high performance athletes, you’ll realize that they practice everyday in order to stay sharp at what they do. Think about runners, swimmers, fighters, and even chess players.
Communities of coding dojos have been formed around the world. A well known group started meeting in Paris in 2004. In 2008, a coding dojo was born in Rio de Janeiro - with non-stop meetings every week since then.
Now we want to bring a coding dojo environment to Pykonik meetings in Kraków.
The two most common formats to run a coding dojo are kata and randori.
In a kata, someone comes to the meeting to demonstrate to the audience the steps how to solve some problem, and the audience should leave the dojo being able to reproduce the solution. It’s kind of a demo... it’s good but it can be better.
In a randori, we have one single computer and projector, and a pair works on time-boxed turns (5~7 min). After each turn, someone from the audience replaces one from the pair and the dynamic continues. That’s the format we’re going to use.
Important things to keep in mind:
- Continuous learning
- Safe environment
- No competition
- Failure and redundancy
- Baby steps
- Discuss based on actual code (avoid abstract conversations)
What NOT to do:
- Rush to finish the problem
- Work on somebody’s "real life" problem
- Compete with other participants
- Have anyone in the session lost in understanding the current state of the code base
At the end of the session we conduct a retrospective to understand collectively what we’ve learned, what did we like, what could be better, etc. And after that, it’s common to spend more time together and socialize.
Base Lab kindly offers us their office space for a venue and provides snacks.
Base Lab - we're building the future of business software. Learn more about world-class Python hacking here: http://py.getbase.com.