How I moved from caring about individual engineers and software craftsmanship to focusing on empowering teams to operate at higher quality and velocity levels.
My tech blog started in 2010. Today is it’s 6th birthday. It’s surprising I’ve managed keep it up this long. Many things changed for me over 6 years. There was a good ~4 year run, followed by a break, and now a change in focus.
I kept blogging and focused on developing better backend services. The Rediscovering the Joy of Design series cap stoned what I learned. I ran workshop at RailsConf 2014 on a similar topic. Then things started to slow down. Truthfully I hit a plateau. I accomplished what I wanted. I grew tired of sharing (and fighting) for the validity of my ideas. I was able to build a team of like minded Ruby developers. We went off our own way doing things differently (and proudly) than the wider Ruby community.
I opened up my editor after a year or so of seclusion and wrote The Ruby Community: The Next Version. It summarized what I felt about Ruby’s community. I received many great comments and feedback on the post. It was great to hear people receptive to the ideas and mirroring similar concerns. It was too little too late. I was no longer passionate about writing about software design — especially in Ruby. I wasn’t writing code anymore at my full time job. I was reviewing other’s code and planning what code others should write. There wasn’t anything left in the tank.
I looked for other languages to fill the gap. I found Erlang and D. Both are fantastic. However nothing stuck. I wasn’t motivated to build anything.
Ultimately I was tired of writing software.
Things needed to change. My technical progression pushed me farther and farther away non technical stake holders. I was confident in my abilities to build and ship backend services as monoliths or smaller bits. However it wasn’t challenging or exciting. It was more exciting and interesting to give engineers the tools they needed to ship code. Shipping excited me. My perspective changed.
The majority of my career focused on building the best god damn software I could think of and educating others how to do the same. None of that matters until it’s deployed. I figured it was time focus on creating the best god damn deployment pipelines.
My career’s first phase focused on individual engineers. The second phase focuses on teams. I know the best software is ultimately created by collaborative teams with aligned goals. My goal is to empower software teams to ship progressively higher quality software and progressively faster velocities. Continuous Deployment is the best way to achieve this goal. This is why I started Slashdeploy.
I started the Slashdeploy blog in early 2016 and it has been great. People want more information in this area. All my effort goes into teaching others how to reach continuous deployment using different technologies and practices. I’ve written one article on Continuous Deployment of Docker Applications, another for Continuous Deployment of Static Sites. I’ve even released an Introduction to Docker course. A more advanced Docker course is planned in the near future. I’ll appear as a regular author on the CloudAcademy blog. There are more continuous deployment articles in queue for SemaphoreCI. I’m speaking at DevopsDays India in Bangalore. This is my first speaking slot in over 2 years.
The topic is worthwhile and interesting to talk about now. It has taken me two years or so to finally find my voice. I gotta say, god damn, it feels great.
So my friends, good look out there and happy shipping!