Back in 2012 I wrote an article Courage which was a typical example of a whole class of blog posts (once upon a time). The team I was working on had just hit our launch goals and we were feeling pretty good. We had previously worked on the legacy Rackspace Control Panel - a fairly typical project with long-QA cycles - and were finally getting to implement a lot of team processes that we had hoped for, mainly deploying straight to production with no QA gate. I had just been promoted and it felt like everything was firing on all cylinders. Easy to just fire off a blog post about how what made it all possible was our team processes. Other teams who weren’t using our processes were missing out on how great things could be.

Ten years later, it’s easier to understand the things that truly made our success possible. Sure, we had some great practices, wrote some great code, and had great people. But - green field development meant no technical debt. Working on a pure JavaScript project reduced the number of failure states of the system. QA didn’t really matter since all the code was written in the last year - everyone on the team knew all the states of the system. My team had either all been recently hired or selected as transfers from existing teams on our site - no glaring performance issues. We were part of one much larger initiative (Rackspace Cloud) that itself was one VP’s project at a company that at the time prided themselves on their manual support processes, so while our project mattered, the entire company wasn’t riding on it. We had freedom to be a little less good and stuff would have probably been just fine.

Since then I’ve come to understand that every well-running team operates within a delicate balance. I worked two more years on my “everything is great” project and then blew up my life to move to the San Francisco Bay Area, letting me be a part of a lot more teams. I worked on a project that I entered with that same fearless attitude (supposed to be a one month refactor) that turned into a 6 month on-and-off ordeal. I worked on a project that was supposed to save a company that was on a limited runway - that we delivered mostly on time! - but that we couldn’t launch due to one of our vendors. I got to see how tests could save a project from quality papercuts while at the same time added so much extra time to feature development; it turns out writing tests for a non-trivial feature ends up being at least twice as hard as writing the code.

So, on to “courage”. I’d still recommend that young programmers cultivate a sense of brazenness. It’s certainly still one of my defining traits as a programmer. I’ll never write an if conditional that checks for nullability if a field “can’t” be nullable, and I’ll point out every time I see this happen on your pull request. But more than that:

  • I’d recommend learning the fundamentals of your programming languages and the libraries they use - what are actually they doing under the hood? What libraries do their rely on? What’s their source code doing? Could you learn something from it?
  • I’d recommend learning how to read code and seeing it as a communication mechanism from other humans, as opposed to just something that accomplishes a task. Who wrote the code that you’re working on now? What do they understand that you don’t?
  • I’d recommend really listening to what people are saying when they talk to you, express their opinions, or try to prioritize work. Sometimes you might not agree but you’ll learn nothing if you don’t listen to them.
  • I’d recommend understanding how to make the best changes possible - uncontroversial, well-tested, and informed by best practices both in the industry and in the codebase that you’re working in. Can you avoid rewriting code that you don’t understand? Can you write your code in a way to overall match project style and make it kind of difficult to tell that you were the one that wrote it?
  • I’d recommend understanding what your role is within the team and how you can best support the business through the act of writing code. You’ve been (presumably) hired as a programmer; learn to bracket your product opinions, understand what your peers in product and design are trying to accomplish, and truly respect the difficulties that come with their craft.

Yes, there’s still a role for process, but no, process can’t create that great environment by itself. I still look back at my previous team with a good deal of fondness, but I’m truly embarrassed that I ever thought the world was that simple. Thankfully, things are much more complicated.