It’s now been over two years working at Pivotal and I can safely say this has been the best place I’ve ever worked in my career. I’ve had plenty of jobs prior to getting a college degree: serving pizza, washing dishes, peeling potatoes, washing more dishes. During and after college, I worked at software startups and more established software companies. Pivotal is the first software company I’ve worked at with good software engineering practices. It’s kind of our thing. Working here has given me language about how to describe the past failures of other environments I have worked in. Here are a few of my thoughts.
Pivotal is a software company. We make Pivotal Tracker, Pivotal Cloud Foundry, many other products. I work in the consulting organization called Pivotal Labs, which was originally formed in 1989 and has been a major influence on XP and agile software development practices. We teach companies how to efficiently and consistently build high quality software. Leaving a startup made me yearn for this type of discipline, and I found it.
My biggest concerns when I joined were whether I would be ok with pair programming and TDD 100% of the time. It seemed strange compared to anywhere else I worked. Maybe a waste of time. But I also knew that I was miserable at past companies due to a lack of testing. It made changing code a perilous task and I never wanted to live like that again. And I figured pair programming would result in me learning new things all the time, so that seemed pretty cool. After a few months, those initial fears were allayed. Pair programming means more focus resulting in extremely productive work day after day. Ardent testing means refactoring or adding new features feels so easy it’s practically algorithmic.
As important as pair programming and testing are to Pivotal’s process, the deeper reason we do it is because we want fast feedback cycles. Running a unit test and seeing it fail is (should be) a quick process. Running your integration tests to make sure a change did not cause an unexpected failure is a faster feedback cycle than relying on QA to find bugs. And it’s automated. When you pair, it’s like a continuous code review. Share an idea, talk it through, decide to do it, or move on to another idea. Pairing is extremely effective for honing implementation details. I don’t go on tangents when I’m pairing, and no amount of coffee or sleep directs my focus as much as pairing with another person.
Testing is baked into everything we do. We don’t build new features and hope they work. If they are worth building, they must be maintained with tests. Writing tests as you write more code is like placing cams into the side of a mountain as you climb. If you were climbing a 10 foot rock, it would look like overkill, but once you have a team of climbers who want to climb a mountain in every direction possible, it’s necessary. The result is that progress becomes sustained and consistent, rather than sporadic and unpredictable. When a bug does occur, the first thought is: how can we write a test to prevent this from happening again? Are there more things we’re missing? Do we have a test that we thought would catch this but didn’t? This constant building up and refining of tests was never the case at previous companies I worked for. And it resulted in massive tech debt that would only be fixed with huge rewrites of the code. Which meant it never got fixed.
Pair programming has shifted my whole way of thinking about software projects. When a team pairs well, everyone has familiarity with the whole code base. Without pairing each person “owns” their part of the code and feels threatened when others want to change it. Pair programming forces me to speak and articulate my concerns immediately. Instead of going into my head and thinking about every possible outcome. I have to say everything out loud. In the middle of an ideal day of pairing, I go into a focused stream of consciousness state where I ask questions and answer questions in a very fluid way. Finishing each other’s sentences. I’m not analyzing and rethinking every possible problem and preparing a statement in order to sound smart. If my suggestions or concerns are invalid, talking them through will reveal that immediately and we can continue to move forward as a team.
Psychologically it feels a little like ego death. Me sounding right or wrong is less important than getting to the right or wrong solution. I practice this also by trying to predict the outcome of a code change before I see the result. For instance: “if we change this variable to 5, I think it will work.” Or “When we change this css property, the background will be blue instead of green.” I say this out loud to my pair right before I actually see the result. Sometimes I’m wrong, sometimes I’m right. If I’m totally open with my pair about my thought process and my understanding of the system, then we are usually right. If I’m not talking it through with them, I usually end up missing something and that’s a cue to take a step back and discuss what’s going on. Not only that, but when I’m wrong it shows my pair that it’s safe to make mistakes. It's natural to want to be right all the time, but it also inhibits innovative ideas. Tearing down that need to sound smart gets you to solutions faster.
Think back on a time a coworker you respected said: “You’re right.” It felt great, didn’t it? It’s like giving someone a present. In improv they call it “yes, and…” because no matter what someone in your group says, you reply starting with “yes, and…” because you’re building a made up world together. When you’re pairing, you can do this all day. Not to blindly encourage bad ideas, but to find pieces of truth to build on. To sculpt together a better idea than if all the thoughts were coming from just your own head.
The hard parts of Pivotal, are that it’s exhausting. I don’t get to put my headphones on, block out the world, and write code all day. We spend a great deal of time discussing whether we have the right solution before implementing it. There is always something new going on. Presentations during lunch or after work about new technologies or interesting topics. The Pivotal process keeps you constantly busy, especially as an engineer. Once you finish your task, you refer to the top of the backlog to start the next task. I have maybe 3 - 4 hours of meetings a week, and the rest of the time is spent writing code. With the occasional ping pong, bathroom, or snack break mixed in. We only work 9am - 6pm, which was a nice relief after the never ending hamster wheel of startup culture. It means I never take home work with me. It also makes it hard to get away from the office for more than 15 minutes during those times, but it’s a tradeoff I can make at this time in my life.
Pivotal is not for everyone. For many people our dedication to XP process probably looks pretty zealous, but that’s ok. When big companies need help, that’s what they pay for: guidance. And that’s what we provide. It has turned out to be exactly what I needed when I needed it. I have already soaked up so much knowledge from my fellow pivots, and I look forward to continuing to learn more from the awesome people around me. I want to continuously challenge my assumptions and ideas, and Pivotal thus far has been a perfect place to do just that.