One way in which culture influences this is that people often absorb their ideas of what’s possible from the culture they’re in. For a non-velocity example, one thing I noticed after attending RC was that a lot of speakers at the well-respected non-academic non-enterprise tech conferences, like Deconstruct and Strange Loop, also attended RC. Most people hadn’t given talks before attending RC and, when I asked people, a lot of people had wanted to give talks but didn’t realize how straightforward the process for becoming a speaker at “big” conferences is (have an idea, write it down, and then submit what you wrote down as a proposal). It turns out that giving talks at conferences is easy to do and a major blocker for many folks is just knowing that it’s possible. In an environment where lots of people give talks and, where people who hesitantly ask how they can get started are told that it’s straightforward, a lot of people will end up giving talks. The same thing is true of blogging, which is why a disproportionately large fraction of widely read programming bloggers started blogging seriously after attending RC. For many people, the barrier to starting a blog is some combination of realizing it’s feasible to start a blog and that, from a technical standpoint, it’s very easy to start a blog if you just pick any semi-reasonable toolchain and go through the setup process. And then, because people give talks and write blog posts, they get better at giving talks and writing blog posts so, on average, RC alums are probably better speakers and writers than random programmers even though there’s little to no skill transfer or instruction at RC.
Another kind of thing where culture can really drive skills are skills that are highly attitude dependent. An example of this is debugging. As Julia Evans has noted, having a good attitude is a major component of debugging effectiveness. This is something Centaur was very good at instilling in people, to the point that nearly everyone in my org at Centaur would be considered a very strong debugger by tech company standards.
At big tech companies, it’s common to see people give up on bugs after trying a few random things that didn’t work. In one extreme example, someone I know at a mid-10-figure tech company said that it never makes sense to debug a bug that takes more than a couple hours to debug because engineer time is too valuable to waste on bugs that take longer than that to debug, an attitude this person picked up from the first team they worked on. Someone who picks up that kind of attitude about debugging is unlikely to become a good debugger until they change their attitude, and many people, including this person, carry the attitudes and habits they pick up at their first job around for quite a long time3.
By tech standards, Centaur is an extreme example in the other direction. If you’re designing a CPU, it’s not considered ok to walk away from a bug that you don’t understand. Even if the symptom of the bug isn’t serious, it’s possible that the underlying cause is actually serious and you won’t observe the more serious symptom until you’ve shipped a chip, so you have to go after even seemingly trivial bugs. Also, it’s pretty common for there to be no good or even deterministic reproduction of a bug. The repro is often something like “run these programs with these settings on the system and then the system will hang and/or corrupt data after some number of hours or days”. When debugging a bug like that, there will be numerous wrong turns and dead ends, some of which can eat up weeks or months. As a new employee watching people work on those kinds of bugs, what I observed was that people would come in day after day and track down bugs like that, not getting frustrated and not giving up. When that’s the culture and everyone around you has that attitude, it’s natural to pick up the same attitude. Also, a lot of practical debugging skill is applying tactical skills picked up from having debugged a lot of problems, which naturally falls out of spending a decent amount of time debugging problems with a positive attitude, especially with exposure to hard debugging problems.
Of course, most bugs at tech companies don’t warrant months of work, but there’s a big difference between intentionally leaving some bugs undebugged because some bugs aren’t worth fixing and having poor debugging skills from never having ever debugged a serious bug and then not being able to debug any bug that isn’t completely trivial.
Cultural attitudes can drive a lot more than individual skills like debugging. Centaur had, per capita, by far the lowest serious production bug rate of any company I’ve worked for, at well under one per year with ~100 engineers. By comparison, I’ve never worked on a team 1/10th that size that didn’t have at least 10x the rate of serious production issues. Like most startups, Centaur was very light on process and it was also much lighter on incentives than the big tech companies I’ve worked for.
One component of this was that there was a culture of owning problems, regardless of what team you were on. If you saw a problem, you’d fix it, or, if there was a very obvious owner, you’d tell them about the problem and they’d fix it. There weren’t roadmaps, standups, kanban, or anything else to get people to work on important problems. People did it without needed to be reminded or prompted.
– Anton (June, 2023)
