Fog Creek

From Talmudic Maxims to Software Engineering Excellence – Interview with Yitzchok Willroth

Looking for audio only? Listen on and subscribe


Up Next
Refactoring to a Happier Development Team

In this interview with Yitzchok Willroth, aka CodeRabbi, we discuss how he has applied Talmudic Maxims to improve Software Engineering practices at Grovo. We cover how by teaching others we can develop ourselves, the benefits of pair programming, how to align product and engineering teams and important metrics to focus dev teams. Yitzchok is currently finishing up his Wisdom as a Service World Tour.

Content and Timings

  • Introduction (0:00)
  • Learning by Teaching (1:12)
  • The Benefits of Pair Programming (3:28)
  • Aligning Product and Engineering Teams (8:52)
  • Metrics to Improve Software Engineering (10:53)
  • Recommended Resources (14:00)

Transcript

Introduction

Derrick:
Yitz Willroth, known as CodeRabbi, is a Rabbinic scholar and software developer who is currently Engineering Practice Manager at Grovo. A prolific conference speaker, he is currently embarking upon his Wisdom as a Service world tour in which he will speak at more than 35 user groups this year alone, giving his talk, Talmudic Maxims to Maximize Your Growth as a Developer. Yitz, thank you so much for joining us today. Do you have any more to share about yourself?

Yitzchok:
Most people know me as CodeRabbi. Prior to being a software engineer, I was a full-time Talmudic scholar, pursuing scholarship as a vocation for over a decade. I’ve always been very active in the software development community, primarily the PHP community. Somewhere along the line this year, in a proverbial game of chicken with the global community, I did agree to embark on the Wisdom as a Service world tour. So far, we’re holding… I think we’re going to make our number. We’re holding somewhere in the early 30s. Yeah, that’s really what I’m about these days, though I’m absolutely, thoroughly enjoying my role as Engineering Practice Manager at Grovo as well.

Learning by Teaching

Derrick:
Your talk extracts some practical, actionable advice from Talmudic maxims about how we can grow as software developers. One maxim, for example, says, “I learn much from my teachers, but I learn even more from my colleagues, and from my students, I learned most of all.” This speaks to the importance of learning by teaching. How can we go about doing that?

Yitzchok:
There are numerous opportunities to learn by teach, both in the workplace and within the community. It’s just recognizing them as such. Mentoring, whether it be formally in the workplace or informally in the workplace, is teaching. If you take that seriously and you embrace the opportunity, through the preparation as well as through the interaction with the apprentice, you’re going to gain as much as they do. The act of teaching, for it to work, you really have to put yourself in the student’s perspective. That opens up your mind to new ideas and new perspectives. That’s in addition to the preparation. The activity of the teaching as well is very empowering for the teacher.

Pairing in the workplace is a form of teaching. I find that, even as the senior in a junior-senior pair, I gain, I grow. To the PHP community, we have phpmentoring.org, an organization which actually pairs up apprentices and willing mentors. There are organizations for women in tech, for teaching children, local dev boot camp initiatives, etc. Conference speaking or user group speaking, again, the same thing. The preparation, you end up learning far, far more than you end up imparting to the audience. I think you’re really the winner there.

Blogging, blogging is a form of teaching, the same thing, codifying your knowledge and refining it into a blog post. That process of refinement typically tends to enhance your understanding. Stack Overflow, IRC, these are also ways to teach. Again, I find when I answer a Stack Overflow question, those that I choose to participate in are those that have caught my attention, not necessarily the low-hanging fruit, so the process of research. Even if I don’t ever end up being the guy to answer the question, it helps me. It helps the teacher.


“Alignment between product and engineering, is necessary, and to be successful, it’s both a technical and a cultural problem to solve”


The Benefits of Pair Programming

Derrick:
You’re a proponent of pair programming. What are some of the benefits you’ve seen from pair programming?

Yitzchok:
The organization benefits with knowledge transfer. It can be used as a way to easily onboard new developers, to allow junior developers to more easily leverage the experience of senior developers, and just that everyone should know a little bit about every part of the code base. That’s typically facilitated by pairing. Sometimes between teams, we’ll pair to affect that knowledge transfer and raise the bus factor a little bit. I think we tend to be more focused when we code in pairs. You’ve got the other person’s attention, and so that shared attention, it tends to reinforce each other’s focus. You’re conversational, so you’re engaging different parts of the brain as well. That impacts both the focus and, I think, the quality of your thinking.

Also, in terms of focus, when you have distraction, one person can defend the pair, and the science behind it seems to indicate that the pair is back in focus more quickly after an interruption than a single would be, because one person has maintained context, so they can bring the other person into context more quickly than that person would work through and re-achieve context themselves. Then there’s wisdom transfer, learning from your pair. It’s difficult to pair at any level and not come back with something useful that you can integrate into your practice, when you’re not a pair.


“An often overlooked benefit of testing is testing as documentation, and assisting in terms of onboarding new developers”


Derrick:
One thing I know I can be guilty of sometimes is not planning my coding days, but for you, this is essential and do it daily. Why is this?

Yitzchok:
My days tend to follow their beginning. If I’m productive in the first few hours of my day, that sets the tone, and I’ll be productive all day. If I am not well-planned, and I find myself context switching, or confusing activity with productivity early in the day, that seems to be a trend all day. Just as you would plan an implementation, I plan my day. I try to, the night before, spend some time clearing my inbox, setting the table, clearing my inbox, clearing my browser tabs, so there’s no obvious distractions. Then at least planning, this will be the first coding that I do tomorrow.

Even if, in my role now, I do end up in meetings and coaching, etc, so I’m not always coding all the time anymore, but I try to code in the morning at least, just set that tone of focus. Then I tend to … That’s my day, but then I think it’s an unlimited good. You can’t plan too much. I try as much as I can to use commit message first development, so just like a named feature branch tends to focus your energies a little bit, so naming your commit before you begin coding that next incremental piece tends to focus my energies a little bit more as well. I try to plan at every level as much as I can.

Derrick:
Part of your role as engineering practice manager at Grovo involves taking tips, like those learned from Talmudic maxims, and putting them into real world use. I know for example that Grovo once had something of a monolithic app that has since been broken up, and you’ve looked to resolve the process and culture issues that had to lead to its creation. What kinds of issues did you solve and how did the maxims help with this?

Yitzchok:
The feedback that I’ve gotten from people that have heard the talk and have put some of the practices into play in their professional lives, looking back then months later, they’re more engaged. They feel more empowered. It’s a fair antidote, I’m finding people tell me, to impostor syndrome. People feel better about themselves, are more capable, and people that feel better about themselves are more capable, take greater initiative. Impostor syndrome is a thing, but it’s not real, and so getting beyond that allows us to apply talents that we already had. Those people that take that initiative find themselves, I think, in the main being successful with it.

Yeah, it’s not a direct connection, but I think you can follow the path between engaging in some of these professional growth habits and ultimately taking a stronger, more successful role in the workplace, sure. The move from the monolithic application to a microservices architecture, that’s primarily a technical problem, so they’re somewhat orthogonal concerns. The secret for us in terms of the move to microservices has been a extremely tight product and engineering alignment, small cross-functional teams, and then laying the groundwork before the transition with creating a really world class integration pipeline.


“Code coverage, cyclomatic complexity, and the 2 together in a CRAP score, are the 3 that I look at most frequently”


Aligning Product and Engineering Teams

Derrick:
Another area of focus for you has been in building greater alignment between product and engineering teams. How did you approach this?

Yitzchok:
I think, as a company, we recognize that this alignment between product and engineering, is necessary, and to be successful, it’s both a technical and a cultural problem to solve. You have to continually work at it. We understand that you have to live together and work together, so the product and engineering teams are physically proximate. We recently outgrew our facilities, and so the engineering team moved within the same building, but to another floor. When we say the engineering team, no, that was engineering and product. They move as a unit. They are part and parcel of one division within the company.

Meetings and communication are not siloed to engineering or to product. There’s usually a representative of the other discipline within every meeting and included in every communication. We celebrate together. Product victories are engineering victories. Engineering victories are product victories. The infrastructure initiative, product celebrated that along with engineering, even though there was nothing they could put in their hands. They couldn’t point to features that existed in the product, but they understood what that did for the organization. That’s cultural. That’s the living together, I guess.

The technical, the working together, so we have product managers which are embedded in each of our engineering squads. The engineering department is broken down into multiple cross-functional squads which kind of aligns with that microservices approach to the architecture. We have embedded product managers, and it works the other way as well. The engineers participate in design sprints and other typically product-only rituals. Engineers are involved in those really from the earliest processes as well.

Metrics to Improve Software Engineering

Derrick:
Yeah, it sounds like a lot of effort has been made to make that alignment, but I know Grovo takes a very data-driven approach right across the company, and you have your own data analytics platform to support that. How does engineering use data to improve?

Yitzchok:
For engineering, it’s a focus more on metrics. My two primary metrics, and they actually synthesize into one, are code coverage and cyclomatic complexity. Together then they form a single metric which, for good or for bad, is called CRAP. It’s Change Risk Anti-Patterns, but it is relatively aptly acronymed as well. Essentially it is the synthesis of code coverage and cyclomatic complexity. A lower number, meaning the less crappy, the better. Lower number is best. If you’re targeting a CRAP score of, say, 30, so that would be a cyclomatic complexity of 10, code coverage of 42. If you wanted to target 20, which is better, that would be a cyclomatic complexity of 20, code coverage now has to go up to 72. It’s a much more complex implementation, so it is inherently riskier, so to offset that, then you need a higher code coverage as well.

We also look at those independently, because together they form a solid technical metric. What is the risk of this code, putting this into production, and maintaining this? What is the technical and the business risk? Individually, I find they’re very good human-focused metrics. Testing is not simply about proving correctness or regression. It influences design. We try to utilize test-driven development. We’re not exclusive on that as a methodology yet, but we’re working in that direction. That’s a good indication of how this code was produced, the higher test coverage.

It’s also testing’s highly documentary, and that is an often overlooked benefit of testing is testing as documentation, and assisting in terms of onboarding new developers, or even an engineer that’s been there some time but is not real familiar with this part of this code base and is tasked to be working there. They often can get up to speed more easily where they have an understanding of the gaps that they wouldn’t have otherwise had by looking at the tests. Code coverage is kind of a human-focused metric as well to me, as is cyclomatic complexity.

Cyclomatic complexity is not only trying to put a number on the potential for incorrectness, but it’s what kind of cognitive load does it take for an engineer to wrap their head around this and to be effective in this piece of the code base? How much understanding do they need here to be able to navigate this code? We read code much more frequently than we write it, and so I think that it’s a fantastic metric itself as well. Those 3, code coverage, cyclomatic complexity, and the 2 together in a CRAP score, are the 3 that I look at most frequently.

Recommended Resources

Derrick:
The CRAP score is definitely something I’ll remember, so that’s an easy one. One last question, can you recommend any books or resources for those wanting to learn more about encouraging engineering best practice across development teams?

Yitzchok:
On an institutional level, I think Code Complete is fantastic. I think that’s a great place to start. In terms of things which are perhaps a bit more tactical, Implementation Patterns by Kent Beck, Patterns of Enterprise Application Architecture and Refactoring, both by Martin Fowler, and I guess you can call it a classic in terms of its approach and its content, although it’s not terribly old, I’m a big fan of Practical Object-Oriented Design in Ruby by Sandi Metz, even though I don’t code in Ruby at all, I use Ruby for configuration. I’m not a Rubyist by any stretch, but I found that to be a fantastic resource for tactical implementation patterns. Then in terms of encouraging the practices throughout the team, I found two that I can point to, Coaching Agile Teams, which is Addison-Wesley, and then Pragmatic Bookshelf has a title, Driving Technical Change, which I highly recommend.

Derrick:
That’s a fantastic list of recommendations. Thank you for providing that. Yitz, thank you so much for taking time to join us today. We really appreciate it.

Yitzchok:
Thank you for having me. I enjoyed it.