Category Archives: Training

A Code Camp Every Week

You’ve asked.

At least a couple of you did!

Here are the basic principles of the HealthEquity approach to lunch and learns. This article is the super abbreviated version of a 10,000-word epic I’ve been writing for ages.
Me when I realized no one wants to read a 10,000-word epic article.

Why do I care? Why should you?

Folks outside HealthEquity might consider this part of the secret sauce of our organization. Any team/company in the world could take the same approach, and we wish they would. As an industry, everyone benefits from more engaged, better-educated teams.

I don’t remember the first time I saw the following set of questions, but they are deeply ingrained in my approach to leadership. What could be worse than an entire staff of expert beginners?

“What happens if we spend time, effort, and money growing and coaching our team members and they leave the company?”

“Isn’t it worse if we don’t make those investments and our team members stay with the company forever?”

-Someone I Paraphrased

I want to build on this micro-focused concept of individuals working for a single company and expand it to the macro level. Let’s be honest with ourselves, in this world where technology people are in perpetually high demand, folks often switch jobs every few years. Initially, my goal was that folks wouldn’t leave our team, or at least when they do, their new employers would take notice and see a pattern of excellent people coming from HealthEquity. Also, I wanted folks would have fond memories and recommend us as a place for their friends to work. I realize now, this was driven by ego, and it was too narrow a scope for the vision we really need.

We need to be thinking about the success of our industry as a whole. To that end, I propose the following:

Continuous Learning Manifesto
Focus on doing what is right for our team members, companies, and customers, by looking for ways to continuously measure and improve our learning and share our findings with the world at large.

Stepping off the soapbox now…

Preaching is not the point of this article. Let me share the cool stuff we’ve been doing.

Some of my co-workers love lists, so I’ll use a list to illustrate the cycle we’ve been through.

  1. We realized we could improve and asked for feedback.
  2. We used the feedback data to create a plan to improve.
  3. We acted on the plan.
  4. We built feedback into the program.
  5. We continued to listen and act on feedback.

The short version is: we retrospected.

Here’s what we ended up with. A multi-track “lunch learning” program for seven out of every ten weeks 4 times yearly. 56 total days a year!

I’ll say it again. MULTI-TRACK SESSIONS SCHEDULED 2 DAYS A WEEK 28 WEEKS A YEAR.

You’re probably saying, “That’s crazy!” Originally, I might have agreed, but we’ve been doing this for 3 years running. We’ll kick off our 4th year this month (February 2019)!

Here’s the quick version of what we do (yeah, another list):

  1. We pay for lunch.
  2. We facilitate our educators.
  3. We retrospect individual sessions and the program as a whole.

Where we started.

In the beginning, our lunch and learns were just like yours. Sparsely attended, often complained about soapboxes for management and the elite of our organization. We had to figure out how to democratize the process.

Several members of our teams responded to our early efforts to move from “all video, book, and preach” to something new. We were doing one thing a day three days a week, and everyone was expected to attend unless they had more important work. Anyway, the feedback was this: “Why not do something where there are different options for different people who want to learn different things? Multi-track-style!” I was floored. I once helped organize a small tech conference, and it was a ton of work! There was no way to make this happen, or so I thought.

Here’s an anonymized schedule from mid-2016.

Taking things one step at a time, we surveyed for interests and found that people wanted to learn about some specific things. Then we put out the word to everyone working in tech at HealthEquity. We had plenty of volunteers! For a time, I took on scheduling rooms, building a schedule for ten weeks, running retrospectives, helping presenters, and teaching a few things here and there.

From the beginning in 2015, we also opened up Intro to Coding in C# classes to the entire company, and even managed to promote several motivated individuals into our technology group as part of the effort!

If it seems like all of this was an epic amount of effort, you’d be right. But we spread it out over time and learned as we went, so it was never too much to handle at once. Eventually, as we retrospected, we found ways to streamline. As things streamlined, we expanded outside the technology group to the entire company in 2018 including plenty of non-technology topics!

What’s next?

We’re still evolving, and now we’re creating tools to assist with our practices. I’ve intentionally left a lot of detail out because I know not everyone is interested in it. Like I said in the beginning: no one wants to read a 10,000-word epic. I’m warming to the idea of calling this concept “Lean Learning”. What do you think of that?

If you have questions or want to hear more about HealthEquity’s Lean Lunch Learning program, hit me up on LinkedIn ( https://www.linkedin.com/in/williammunn/ ) or in the comment section below. I’m more than happy to help you get a similar program started, or tell you reasons why you should work at the greatest HSA company in the world!

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

2014 Developer Learning Guide: Part 3

This is the 3rd and final post in my series on continuous developer learning. I recommend you read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already.

When I started writing about this subject, I thought I would cover all of the options in one post.

I.

Was.

Wrong.

One of the wonderful things about learning, is that there is a lot to learn about it! I’m in the process of recording a new podcast with a friend of mine and one of our first episodes will iterate just exactly why we believe continuous learning is so important. Stay tuned!

Now, the finale…

In-Person (Larger Groups/Formal Training)

Hackathons/Hack Nights

Hack-er
Um… wrong kind of hack!

This is one that I need to get more involved in. I’ve heard great things about hackathons. I only attended my very first one a couple weeks ago and it was a good experience (all WiFi issues aside).

Additional personal experience is more related to startup work even less formal than these events. There have been a couple of times I’ve tried to put together a quick app or program in a short amount of time using the MVP or “Minimum Viable Product” approach from The Lean Startup. I found that I learned a remarkable amount in a short amount of time.

I learned even more when I did this together with some friends who ranged in skills from entrepreneur to systems admin to programmer to business development.

Code Camps/Large Conferences

I’ve considered writing an entire post about these. There is nothing like being surrounded by others who are looking to improve and be awesome at what we do.

This kind of event can run from half a day to a full week. They tend to be a little heavier on the pocketbook, but you can find lower cost options as well. If you live in an area with a very active tech community, you will probably have many great local options that at least save you on the travel costs.

Conferences really get the creative juices flowing and keep you fired up about your work. Most major tech companies have at least one developer conference per year (Google, Apple, Facebook, Microsoft).

WWDC

Employers with a decent training budget send their developers to 1-2 larger conferences per year (almost never 3+).

I try to mix it up like so:

  • 1-2 out of town conferences. I enjoy travel and this is a nice opportunity to get out of the state for a few nights.
  • 2-3 local conferences. To help keep the budget down.
  • As many code camps as I can reasonably attend.

Why so many? There are a lot of topics I’m interested in and it just so happens that they are all related to my work. This year, I attended an AngularJS conference (ng-conf), an Agile conference (AgileRoots was amazing), Utah Code Camp, and DevFest Family. I’m still planning to attend a large UX conference and a more hard-core software engineering/architecture conference.

I’ve also found it extremely valuable to speak at some of these events. No one learns more than the person who stresses over getting in front of a bunch of smart people to tell them about something!

On-site Training

This type of training is great when you have a team that all needs to get on the same page.  Schedule a trainer to come out to your company on your schedule. I will turn you loose on Google for this one… do a little research and you will find many companies offering this type of service.

My experience here is positive. On-site training sessions can be highly valuable just make sure you get a great trainer. Interview them first or suggest a trial session.

Costs, I’m not super sure on but what is published online is $1000-5000 per session. If you think you will have an ongoing need for this, negotiate a better rate.

Certifications/Degrees

Certifications are highly valuable for IT people although they are not be as well recognized in development circles. I have a former boss who refused to interview candidates with Microsoft’s developer certification on their resume…

MIT
MIT. Yes, I know there’s a TARDIS on it.

Advanced degrees are valuable if you are specializing in certain areas of our field. Machine learning, concurrent programming, and human computer interaction are all excellent examples.

Both certifications and advanced degrees become considerably more valuable if your company is willing to pay for part or all of the tuition. Without that, I would probably avoid them because your return on investment may not be very good.

Conclusion

As you can see, the options for learning run the full gamut of price, time, and commitment. The great news is, even if your company has little or no budget for training, all you need is a couple committed developers to get started with the less expensive (free) types of training. Even better if your company agrees to a budget or commits to learning in other meaningful ways (time/food/support).

I recommend that you seek out employers who understand and value learning. I have and I couldn’t be more glad.

Remember to read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already. Follow me on Twitter (@dubmun) for comments about development and other shenanigans.

Image credits:
Egg seller
A visit to Amsterdam always, always involves coffee
https://www.flickr.com/photos/bbcamericangirl/