Extreme to Lean: A Pluralsight Journey

How does Pluralsight development work? How does it compare to other tech companies? Are certain processes considered ‘best’ for me and my job? While I cannot answer these questions fully, I can share my experiences transitioning to working for Pluralsight as a software craftsman and how my views have changed during that process. I aim to show a small snapshot into the bigger picture of finding the work environment that best suits you. I hope that every reader will understand that while my experiences detailed here are my own, we all can and should strive to find the processes that move us, the passion that drives us and the people that lift us.

My journey to becoming a professional programmer is unique and I feel it gives context to the subject matter. Rather than pursuing a Computer Science degree, I have a B.S. in Physics. But surprisingly though, it was the physics that led me to programming. As I was working through the physics program I was also working full time for a local tech company as a tech support agent. When I was about halfway through the program I was required to take two introductory CS classes, just as an intro to basic programming. After I had completed those courses I decided to naively apply for a junior position in the development department of the company I was working for, and surprisingly I got the position. Looking back, I realize that it was almost impossible for me to attain that position with such little experience, but regardless my foot was in the door and I wanted to learn all that I could from my new co-workers. I ended up working in that development job for over 5 years. I share this background to help the reader understand that until 3 years into my 5 as a developer there, the processes and paradigms in place at that company was all that I knew and believed in.

When I started working in development for that company, I was opened to the world of Agile. A word that until my first day in the new role, had never heard before. That company practiced a subset of Agile called extreme programming, commonly referred to as XP. The intricacies of XP won’t be detailed here, but rather a few highlights to help contrast with the Pluralsight processes mentioned later. By practicing XP, we used common tools to organize our work like story and task cards, velocity, sprints, retrospectives, etc.

To highlight, we had a policy of pair programming on all production code. If you are a seasoned coder, you might guess that didn’t work as intended for much of the time, and you’d be correct. It usually devolved into one coder coding and another being asked to review the code before commit to ‘pair’ on it. There was also a very strict hierarchical structure of developers, one in which it was an unwritten rule that nothing could be done successfully without the involvement of the one of the highest leveled developers. One last highlight would be that much of the work was dictated by the product manager/sales/CEO. For the most part, we did what was asked of us, never really thinking outside the box.

Here at Pluralsight things are a little different than what I’ve described. We practice what’s known as Lean Programming, and again the intricacies of which won’t be detailed here. The first thing to note is that Pluralsight strongly believes in small autonomous teams. By having these, each team can decide what works best for them. Some of the highlights here are general across all Pluralsight development and some are specific to the team where I work. I mention both to help contrast earlier practices. By practicing Lean, we do not have any defined sprints or velocity, and although we do use story/task cards, they are not viewed in the same manner as XP. We continuously reflect and hold mini retrospectives to better ourselves. We collaborate with our product manager. We practice test driven development (TDD). We practice mob programming, an extension of pair programming. The best part is that we do these things in their entirety, all the time.

As I’ve made these transitions I’ve also had to change myself. I feel that I’m a better craftsman and developer than I was before, not only because I’ve transitioned to a different paradigm, but because I’ve transitioned to a different paradigm that works better for me. It’s common for my team to code for a full 8 hours each day, compared to the 4-5 at best I was participating in before. By test driving all production code, I’m able to have confidence in the code immediately rather than later after writing tests post-commit. Possibly the biggest change for me is transitioning to a culture of learning rather than a culture of dependence. As a perpetual learner, I’m hungry for more knowledge and at Pluralsight I’m free to learn/experiment and most importantly, fail. Before all I knew was a culture of depending on those more experienced than myself, a culture that I still believe works well for that company. They did hire the greenest of green junior in me, for example, and continue to do so. But the culture that fits me best is the culture of Pluralsight.

In retrospect, for the first years because of the culture I found myself and because of the unique path I took to get there, all I knew of practices, paradigms and tools was the experience I had had to that point. Once I could start branching out my knowledge by attending conferences, freelance developing, networking, etc., I began to realize that there are many ways of doing work. Each with its own benefits and best applications. I believe that there are a few companies out there, hopefully just a few, that waterfall really is the best method for them. The trick I’ve found is to find what drives your inner hunger as a craftsman and developer.

For me, Pluralsight and its processes/culture are a better fit than the ones I recently left. For me they are, but the best fit for me may not be the best fit for every reader. I strongly believe in the pursuit of learning and experimentation. Find what’s best for you. Apply it, and if it doesn’t fit, find something else to try. The challenge for all of us is to keep learning and trying, never settling for something that may work, but doesn’t work well.