Tag Archives: coding kata

Kata Cups: Solving Kata Problems Since 2014

First: credit for this concept goes 100% to Llewellyn Falco. I was running one of my favorite Javascript coding exercises in 2014ish at a Utah Software Craftsmanship meetup, and Llewellyn not only showed up, but he also solved the problem I was having with my presentation style.

The Problem

Who’s run a guided code kata for more than three people?

Need a definition for a guided code kata? Start here, then add the idea of one person either displaying steps to follow and/or performing the steps on a large screen in front of several people. Guided katas are commonly performed at user groups, lunch learnings, or at a local coding dojo meetup.

Back to my original question: who’s run a guided kata for more than three people?

Still reading? Then you probably relate to the problem. The problem is:  how can you tell when a reasonable percentage (or 100%) of the room is ready for the next step?

In my case, I was leading a guided kata for a room of around thirty people. Even with about half the room doing the exercise in pairs, I was spending a lot of time asking, “Who needs more time?”.

The Solution (hint: it’s kata cups)

Cut a notch in two sides of some paper cups, and ask people to put them on their laptop screens when they finish the current step of the kata. When a significant agreed upon group of folks are ready, call out “Cups down!” and move on to the next step.

Simple.

When you don’t have any cups handy, try having everyone fix a sticky note to the top of their laptop. Post-its work in a pinch, but the cups are more reliable– and fun.

The use of kata cups has spread throughout the office at work. It’s fun to see something so simple aid in the success of a lean-agile culture. So many things we do are about visibility and collaboration and finding the right solution just-in-time. Kata cups are no exception.

Legacy Code Kata v3.0

You’ve been patient. Some of you have been patient. Last week on Thursday night, I presented Legacy Dependency Kata v2.2 at the SLC .NET User Group Meetup. You’ll notice the name change since then.

But wait– don’t know what a code kata is? Start here.

I’d like to give a quick thank you to the crowd that night and the one the day before at HealthEquity during one of our Lunch Learning sessions. You all are fantastic. Thanks for the great feedback!

What’s different? Not much, to be honest. Also, in some ways, a lot. But what I realized as I was going through the slides one final time, was this: this IS a major revision. I just didn’t realize it while going through all the multiple iterative changes.

What hasn’t changed? Legacy Code Kata 3.0 is still a code kata about dealing with dependencies in legacy code and getting it ready for unit testing. It still uses the same seed code as previous versions, and you can find that here on GitHub.

Changelog

So, what makes this version so great? Let me lay it out for you:

  1. Lost the lame presentation theme. I thought I accomplished this with v2.0. NOPE. You’re welcome.
  2. The intro slides have been honed down to only those 100% essential, and they were also prettied up, and some new notes added.
  3. Added the Kata Barometer (patent pending (not actually (maybe))). At any time you always know what state your tests and build should be in.
  4. Broke up quite a few slides that were too complicated and/or the font was too small to read effectively. Much more Kata Cup friendly now. What’s a Kata Cup? Maybe in a future post. Stop changing the subject!

If you want to see for yourself why this version is so much better, check out the old versions: Version 1.0 or Version 2.0.

Here it is.

Legacy Dependency Kata v2.0

Well, well, well. Look what the samurai dragged in. An updated version of my Legacy Dependency Kata. I’ll have to update the Coding Kata Resources page.

50795_01_kurosawas-classic-seven-samurai-gets-stunning-4k-remaster

I’m not proud to admit that there even was a v1.0 at the moment. Let me explain.

Just over two years ago, I was experimenting with writing katas, presenting at code conventions, and running a coding dojo. It turns out. I wasn’t super fantastic at any of these things. Nevertheless, I wrote a kata, ran it a few times with the kind folks in my dojo, and proceeded to share it with the delightful folks at Utah Code Camp 2014. Reviews were mixed, but overall I felt good about it.

Fast forward to the present. While planning the lunchtime learning schedule for our recent SAFe Program Increment, there was an opening, and I, ever so graciously, decided to run my Legacy Dependency Kata for folks who may not have had the chance to see it before. Upon thoroughly embarrassing myself with some of the crappiest kata slides in existence (slides even I couldn’t completely fathom), I recognized that my life would be forfeit if folks were forced to do the kata again with the same slides the following day.

I dashed to revise the slides and spent many hours on the task. When I presented the kata on the second day, it was a much more successful attempt. I’d go so far as to call it a version 1.7. I spent some more time and enlisted the advice of the ever-gracious and capable Kaleb Pedersen in finalizing v2.0. The source code is still the same. Legacy code problems from 2 years ago are still very similar to what they are today.

coughnounittestabilitycough

I think the new slides do their job. Could this kata still be better? Without a doubt. Please submit your recommendations in the comments or feel free to yell at me on Twitter. I’m sure I deserve it for something.

Without further adieu, I give you Legacy Dependency Kata Version Two.

Seed code is still on GitHub:
https://github.com/KatasForLegacyCode/kCSharp/releases/tag/Step0

Learn Like A Viking

My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.

I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!

drinking-horn

Untitled

Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then sleep
Then do it all again

-Ron Coulson (2016)

If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.

2014 Developer Learning Guide: Part 2

In Part 1 of this sequence of blog posts, we covered online and print learning. Part 3 is now available as well. This time we will review some of the in-person options for learning and focus in on smaller groups. But first…

An Elaboration On “The Best”

I suggested in 2014 Developer Learning Guide: Part 1 that A-players, top developers, etc. only want to work for companies that have a great learning culture. This doesn’t necessarily mean that they already ARE working for these companies. The point is that, given the choice, the best developers know the value of learning and want to be part of groups where everyone is actively engaged in it. If you are already working for a company like this, I congratulate you on your outstanding choice!

The most common argument I’ve heard for choosing or sticking with a company with poor learning policies/funding: “If a company pays well enough, I can afford my own learning/training.”

Money Vortex
Don’t get caught in a money vortex that leads to stagnation.

This is true. The fallacy is that all of the developers will use their “extra money” for this purpose. We all have obligations and sometimes paying off that credit card or taking a family trip might take priority over paying for our own training. When the employer provides budget and opportunity specifically for training, the entire team is far more likely to take advantage of it. This leads to the entire team learning and growing together. You avoid the situation where stragglers are content to stagnate and contribute a steadily degrading quality of work (and contribute steadily degrading quality of feedback on teammates’ work).

TL;DR I stand by my original statement with a few caveats.

This is not to say that everyone should try to learn in the same ways. Some people don’t take much away from certain types of training and learning opportunities. There is absolutely nothing wrong with this, in fact, it is the purpose of these posts to provide a comprehensive list of the options that are out there! My hope is that you won’t focus on only one type of training. A rich selection of options awaits. I encourage you to try many and find out which work best for you.

In-Person (Smaller Groups)

Book Clubs

Start or join a book club/group/discussion. If you don’t like the word “club” find something different. Oprah won’t mind… why do you even care what she thinks? oprahAndDubmun Hopefully your company is willing  to sponsor a  book group with lunch provided and books paid. This is a minimal expense and provides a great return on investment. Reading books alone often isn’t enough. Having discussions with peers (who will definitely have takeaways you didn’t consider) is a great way to help maximize learning. In addition, adding coding exercises that pertain to the book topic occasionally really helps to cement the knowledge. More on that later…

One thing I’d like to call out here: if your group is larger than six people, consider breaking out into smaller groups for the majority of your discussion time. This is a neat trick I picked up from Mike Clement at Utah Software Craftsmanship meetups. Large groups tend to lend themselves a couple of antipatterns:

  • At best some participants may not participate because the more dominant voices in the room are taking up too much time.
  • At worst, you may have people napping in the back.

We implemented the breakout approach at my current company with great success. We get back together for an overall discussion for 10-15 minutes at the end of the hour and cover the points each group thought were most important.

Selecting the right kind of book is a very important concern here. Voting as a group is a nice way to get an idea of what people are interested in. Always be sure to select titles that will be good for discussion. Code cookbooks are an outstanding example of what not to read. I tend to prefer books grounded in theory, patterns, practices more than how-to books on specific technologies. If you aren’t sure where to start or don’t have money for books initially, there is a lot of great free material for discussions available online. Many blog post make for excellent discussions (hint, wink, nudge).

Presentations/User Groups/Meetups/Open Space

This section is a little more broad. Intentionally. There is an entire class of in-person interactions that can be extremely valuable learning tools. Many are existing groups and some you’ll have to go out of your way to create.

IPresentToYouTheOceanPresentations – The most formal entry of the section. Presentations are sometimes more valuable for the presenter than they are for the people watching. Nothing cements knowledge in your brain like stressing over sharing it with 5 to 500 other people all at once (for me anyway).

What you will take away from attending a presentation depends on your own personal learning style, the effectiveness of the presenter, and how much attention you actually pay to the presentation. I get nuggets from attending presentations but in general they have moderate value for me. So, “Present, present, present!” becomes my mantra.

“But where can I present?” you ask? The opportunities are out there. Present at work, user groups/meetups, coding dojos, code camps, large conferences, or just record yourself and post it online. Not sure how to get started? Go and watch someone present and ask them how they did it. This is also a topic I may write more on in the future.

User Groups/Meetups – Unfortunately I missed a great one of these (Utah Software Craftsmanship) last night because of pressing matters elsewhere. These groups are somewhat hit and miss, but if you find a few that are a good cultural fit and really match your interests they can be fantastic. User groups/meetups are a great place to learn, practice presentation skills, mingle with fellow techies, and often get free food.

Meetup LogoIf there isn’t a local user group that fits your interests, start your own. The most difficult part is securing a venue but local colleges and businesses are often willing to host your group. In addition, larger groups will attract sponsors who may provide swag for giveaways and/or food.

The best current place to look for a public group (or start one) is on Meetup.com.

Open Space Technology – I’ve only participated in one open space-style of meeting/collaboration unfortunately. It was at an Agile Roots conference back in 2009 and had a fairly profound impact on me. If you have the opportunity to attend an open space, I highly recommend it.

For more info check out OST on Wikipedia.

Coding Exercises/Katas

Coding exercises are a general term for writing code following a format lead by a presenter. There are many different subsets of exercises including design, gamified, and code katas. All of these have value, but I’m going to focus on the latter.

If you aren’t familiar with the term code kata, here is what Wikipedia says:  “code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition.http://en.wikipedia.org/wiki/Kata_(programming). I like to compare it to a martial arts kata where we work to develop the equivalent of “muscle memory” for certain coding techniques. Kata Coding dojos are specialized meetups of people who perform code katas as a group. Participating in a coding dojo is something I look forward to every week. I always learn something new and almost always have the opportunity to help others do the same.

I have a future blog post queued up about my experience with starting a coding dojo at HealthEquity over the past year.

Part 3

It turns out I have too much to say for a 2 part post. In the third and final part of this post I will cover more in-person options for learning. It focuses on larger groups and formal training. Find it here: Part 3.

Also, be sure to check out Part 1 if you missed it.

I’d love to see your thoughts and comments below or to @dubmun on Twitter.