Maayan Roth

Engineer, potter, e-bike enthusiast, mom of two.

Learning Cultures reading group: “Like Coding In the Dark”

July 9, 2026

While at Recurse Center, I'm hosting a weekly reading group centered around the collective works of Dr. Cat Hicks, a researcher studying the psychology of software teams, and whose new book with that title just came out yesterday. Since none of us have gotten our hands on the book yet (my copy is waiting for me at my local bookstore), we had our discussion today about one of Dr. Hicks' older works: “It's Like Coding in the Dark: The need for learning cultures within coding teams”.

A brief recap of the paper

Dr. Hicks interviewed 25 “code writers” of different levels of seniority and from different company sizes, all located in the Bay Area, on their experiences learning as a member of a software development team, with a particular focus on the experience of onboarding in an unfamiliar codebase. The themes that emerged from the interviews clustered into three main topics: the activities that code writers perform when learning a new codebase, code review as the common first instance in which a new team member receives feedback from their new teammates, and ways in which the company or team environment sends implicit and explicit messages about the value of learning.

Most interviewees described a similar set of activities performed in order to build an iteratively more accurate mental model of the new code base. This learning was actively experimental in nature: intentionally breaking things, probing for potential edge cases, and forming hypotheses about the intentions or previous decisions of the previous writers of the code. In most environments, interviewees reported that this learning was conducted individually and privately, with limited opportunities for the new team member to share what they had learned with others.

At the code review stage, interviewees reported feeling significant performance pressure. They were reluctant to use the code review as an opportunity to discuss their learning because of fear of being seen as less competent, and because of implicit or explicit messaging that communicated to them that only their output, the code artifact being reviewed, was of value, and the process that got them to that artifact was not.

The code writers' environments reinforced a message that devalued learning both implicitly and explicitly. Explicitly, time pressure was a consistent theme, and activities that promote learning, such as documentation, code comments, and mentorship and collaboration, were seen as taking time away from producing code. Implicitly, new team members observed the absence of documentation, code comments, and pair programming, and inferred that these activities would not be valued by their new employer.

Collectively, these themes combine to create cultures of what Dr. Hicks calls “learning debt”, defined as “cumulative failure to support learning, created when code writers' investment in long-term understanding is disincentivized”. Code writers working in cultures with large learning debts report feelings of loneliness, long-term stress, and demotivation.

Discussion themes

The themes and environments described by the interviewees in the paper resonated with many of us, and it felt validating to read about it as a commonly shared experience. One member of the discussion group recalled a time when, upon joining a new team as the only junior engineer, they were explicitly told by their manager that they were expected to “sink or swim”. The common theme of time pressure as a disincentive to learning was universally familiar.

An interesting reflection that we had was that, even environments that want to promote learning sometimes struggle to do so effectively because of immature practices around knowledge transfer. One participant in our discussion described being on a team with a recurring Friday morning meeting called “Knowledge Transfer”, in which a member of the team would brain-dump everything they knew about a particular part of the code base. Attendees were expected to remember and retain everything that was said in those meetings, since there was no other documentation. We also noted that effective learning often requires a teacher, and that being an effective teacher is itself a skill that is not explicitly taught in most coding environments.

Some of us have been fortunate enough to spend time in environments that do value and promote learning. Some useful practices from those environments include:

We noted that all of these practices are only as effective as the managers who implement them. Individual team members are unlikely to successfully self-organize to promote a learning culture without leadership support.

Finally, we spent a little while discussing the study itself, such as how it might have been impacted by a sample of 25 Bay Area software engineers, vs code writers from other countries or cultures, or employees in other fields. One participant described working in another country with an even stronger culture of not sharing information. In software teams in that country, the participant said, if you have knowledge, it's the norm to keep it to yourself because that will help you get ahead of your peers. Another participant described the substantial formal structures that exist to scaffold learning in other fields such as mental health and medicine, which are largely absent in software engineering.

My reflections

Over the years, I've worked in software environments with very different learning cultures. Reading the paper's section on code reviews, I couldn't help but think of my first code reviews as a brand new junior engineer at Google. I know that I learned so much from those reviews, but I definitely wouldn't describe the experience as comfortable. Later, at Flatiron, when we were writing our first engineering job ladder, we intentionally put teaching, mentoring, and sharing knowledge with others as expectations for senior engineers. Flatiron had recently acquired another company where being the “go to expert” on a topic was strongly valued, and some engineers from that company were reluctant to share their unique knowledge because they feared it would harm their job security. We encoded formal expectations around knowledge sharing in our ladder (and in the company value of “Train Your Own Replacement”) as a way of pushing back against that cultural norm.

I also strongly agree with the paper's reflection that companies with strong learning cultures are those where it's safe to be seen making mistakes and where communicating about your process, and not just your results, is appreciated and rewarded. I don't need to write about blameless postmortems, plenty of others have said what needs to be said already. I haven't seen this idea about the value of showing your process said explicitly before. It made me think of a common practice on my most recent engineering team. Engineers would frequently record short videos in which they demonstrated some part of their work setup, or an experiment they had done, whether or not that experiment succeeded. The most senior and tenured engineers pioneered this practice, demonstrating to newer team members that showing your work was a behavior that would be valued within the team culture.

It's fun to read this paper while at Recurse Center, a software environment with the stated goal of being a learning culture. There are lots of explicit ways that RC promotes learning (e.g. scheduled pair coding jams and presentations), but it's also been fun to notice the implicit ways that the value of learning-promoting activity is communicated. The paper describes cultural onboarding moments in which new employees look around and note whether their more established peers are writing comments and documentation, and through that observation decide whether or not to write comments and documents. Similarly, as a new batch member, I've noticed that RC participants devote as much or more space in their daily check-in messages to coffee chats and pairing sessions with other RCers as they do to their coding output.

If you're a Recurser and would like to join us for a future discussion, we'll be meeting on Thursdays at 1pm ET for at least the next 4 weeks. I also highly recommend following Dr. Hicks on Bluesky.