Healthify Blog

Learning in Review: How We Teach Each Other to Code

At Healthify, our software engineers collectively represent 52 years of programming experience, which is a detail not that interesting on its own. All of us learned how to code and at some point in time we each started doing it for money. Duh. We didn’t, however, all go about doing this in quite the same way. As a matter of fact, we have an eclectic mix of educational backgrounds in our department and those details are fascinating.

 

33% of us went to a code school, 22% of us have a degree in computer science or related field, 22% of us have an unrelated degree, and 22% of us never went to college.

The vast majority of us attended college – though most of us studied things completely unrelated to our jobs and at least one of us is currently earning an advanced degree in our field. Two of us skipped college completely [1] and an impressive 33% of us went to a code school to either change careers or launch a brand new one.

Considering the nature of the software industry and its never ending stream of change, I think each of us programmers get to wear an autodidact badge. You can only lead a horse to water, you know? However, the variety of paths we followed to get here highlights a truth relevant to those of us interested in continued education within an engineering organization: we all learn in very different ways.

I want to answer one simple question about our organization today: what are we doing to stimulate growth and knowledge sharing within the software engineering department at Healthify? An audit of our efforts will hopefully inspire a few ideas for your organization and help us reflect on how well we're doing in ours. 

Feedback Loops and Peer Review

First things first. Humans need feedback in order to improve. The most frequent and obvious feedback you can expect as a programmer is a compiler or runtime error.

Computer: Hello, this is compiler. Code not work.

Software Engineer: Right. How can I do better?

Computer: Hello, this is compiler. Code not work.

This type of feedback has the desirable attribute of being frequent and the undesirable attribute of being from a cold, senseless machine [2]. It’s like using a GPS set to “shortest distance” that can tell you when you’ve made a wrong turn but can’t tell you where exactly to go. You’re not taking the most efficient route and you can only course correct when things go wrong.

Hand with watch

Creative Commons attribution: https://unsplash.com/photos/3jBU9TbKW7o

It’s like a compass that points south and fails to warn you about the swarm of conspiring bears standing between you and your final destination. You’re going in the right direction, but you’re almost certainly going to die.

The error feedback loop helps you quickly iterate towards a solution that isn’t broken, but fails to teach you how to craft maintainable systems, improve habits, predict bugs, and use best practices. You need a human for that.

Calculating route.

We're up for Review

Every line of code we write at Healthify goes through peer review before it's released to our users. Besides the obvious advantages this has over compiler errors, peer review is useful by virtue of other humans being more experienced with a given language, more familiar with some part of a code base, more acquainted with a certain business requirement, or simply as a fresh set of eyes on a problem at hand.

With the right communication guidelines, a consistently enforced code review process empowers engineers to stoke the smoking hot embers of growth with the personalized feedback and direction that no compiler could ever provide.

Keep in mind that we value code review for its ability to provide feedback to human engineers by human engineers, not because process is inherently good or that the act of code review is a worthy performance. Go ahead and cache that thought in short-term memory ‘cause I’ll bring it back up shortly.

Code review is good, but it lacks the desirable quality of being frequent since it only happens after you’ve done most of the work. If only there was a way to get peer review in real time...

Enter Pair Programming Stage Left

Creative Commons photo of pears. Credit to https://www.flickr.com/photos/newkidontheblock/

You know that perplexing text message you got from that guy you forgot about at that party you didn’t enjoy and you can’t figure out who it is or how to respond? Your friends contribute potential responses, revisions and general feedback, ‘cause that’s what friends do. “Just use one question mark; you don’t want to sound desperate,” and “No, do not give him your address,” and “Hmm. Nice. That’s good. Yeah, send it.” Pair programming is like that, but the guy is a business requirement, the text message is code, and the phone is your laptop [3].

Pairing happens when two programmers sharing one screen collaborate in real time to work on the same feature. Redundancy much? Nope. Both engineers get the value of peer review with the quality of real time feedback. That’s exactly what we’re looking for.

We incentivize pair programming at Healthify by asking engineers who exclusively paired on a feature to skip the code review process completely. Because of this, pairing often leads to features being shipped much faster than you could expect otherwise.

 

As a company that values a growth mindset and product quality, pairing is our best possible option. It’s good for us… good for us. Good FOR us.

You are on the fastest route.

Help Me Help You Help Me

We have nearly as many current and former code school instructors on staff as we do engineers in the early stages of their career. Real talk, I had to consult our Head of Data Science to construct this complicated graph, so brace yourselves.

4 out of 10 software engineers at Healthify are current or former educators.

There’s a near balance between passionate educators and voracious learners, a powerful symbiotic mutualism unrivaled by even the infamous clownish and it’s notorious collaborator, the sea anemone. You scratch my back and I’ll scratch yours.

Fish.png

This is one fish that knows what it wants.

You feed on the small invertebrates that hurt me and I'll feed on your naturally occurring...excrement. Never mind that! I’ll show you dependency injection and you remind me how it feels to be full of vinegar in the days before programming sucked.

The truth is that programmers at every stage of their career have something to offer by way of knowledge sharing. I learn something new from each of my peers all of the time. We’re all informal educators when we pay attention to how we work together.

In 600 feet turn left.

Lunch & Learns

Every other week we dedicate one hour to attending a Lunch & Learn which always includes eating food and usually follows one of these formats:

  1. Internal: Someone in our company prepares and presents on something neat.
  2. External: A guest speaker shares their history for 15 minutes and we ask them endless questions about themselves and their perspective for another 45.
 
Hopefully, people finish lunch having learned something. Some recent, notable sessions range from technical overviews of React in our code base, Redox (not Redux) integration in our API, and security best practices all the way over to deep dives into what our Integrations department is up to and who our users really are.
In my opinion, there are a few aspects of the Lunch & Learn format that need refinement, but that’s a topic for another time. As an aside, maybe there’s something to learn from the Lean Coffee structure [5]. Or maybe we’d all be better off spending lunch alone, reading any one of the books we purchased with our education budgets.
 

Stay left at the fork.

An Education Budget

Books.png

Our annual education budget is enough to do any of the following every year:

  • Purchase roughly 33 books from O'Reilly Media [6].
  • Attend one large conference, including airfare, hotel, ticket price, and some meals.
  • Purchase a full subscription to lynda.com, egghead.io, gorails.com, and like every course Wes Bos invents in a lifetime (which is a lot, probably, I’m pretty sure).

This year most of us peaced out to attend RubyConf 2017 in New Orleans. I’m not sure in which way I personally got the most value from that trip: the increased camaraderie inevitable from sharing an old mansion bed & breakfast [7]  in the coolest part of The South or the technical Chad Fowler talk about services and TDD. It was worth it regardless.

Continue on this street for 800 miles.

Shadow Am I!

Our varied educational upbringings may explain why so many of us were so inclined to work with Turing School of Software and Design in 2017. If you’re not savvy, Turing is a non-profit trade school designed to train world class software engineers early in their career. Every quarter they send students to shadow engineers at different organizations like ours (and ours specifically!).

 

The program gives students an opportunity to see what it’s like to work in the industry. It gives us the opportunity to to give back, show off what we’re working on, and to teach. Not to mention build street cred with the up-and-coming crowd. ;) You learn so much when you teach. You learn what you don’t know. You learn how to articulate what you do know. Dunning-Kruger be damned.

Your destination is on the left.

We're Always Learning

 
It seems like we're in a pretty good spot and there's also room for us to improve. We may not need to add more things and stuff now. Rather, we have the opportunity to refine and and improve the things and stuff we already have and might consider looking at those things through the lense of our individual experiences. And fear not, I’m encouraged knowing that we’re an organization rooted in a growth mindset in all aspects of our work, including how we learn to learn.

You have arrived.
 

[1] Hi, I’m Aaron and I never went to college. Fun fact: I also never went to a high school, but I've crashed at least 3 senior proms.

[2] Hashtag I love robots and software. Hashtag I’m sorry to any future singularity reading this in disgust. I didn’t mean what I said about computers being senseless I’m just trying to make a point.

[3] I loathe mobile phones and would rather quit my life than program on a touchscreen.

[4] That’s a lie. I’m fairly certain Martin will be ashamed of me for making this.

[5] Shout out to Evan Moore for the note.

[6] More than I could possibly read in a few years, honestly.

[7] Sans breakfast. What’s up with that? The bnb in Airbnb stands for bed AND breakfast, right?

Topics: Recruiting Healthify