Work With Me

What I do Link to heading

I’m a software developer specializing in processes and tools that improve developer productivity. I started my career in big telecom, working on tools to automate production and testing of large switching systems. I’ve worked on a variety of products since then: productivity tools, communication applications, educational tech… But throughout my career, although I was a developer on teams working on products, I often spent much of my effort on making the whole team more efficient. In 2017 I rebranded as a “devops engineer” and began working full-time on what I prefer to call “developer productivity engineering”: applying techniques and technology to speed up production and reduce development friction and pain. A lot of people come into “devops” from the operations side, but I think it really helps to have a developer perspective. I speak “devops” with a developer accent.

How I do it Link to heading

There is a dazzling landscape of tools, techniques, platforms, and tech stacks for enhancing developer productivity. Proficiency in any of these isn’t terribly difficult to acquire. The real art is in knowing which tools and techniques will bring about optimal results, and successfully putting those tools and techniques in place. That requires spending time getting to know the team that builds a product and establishing trust with that team.

I love new tech and new ideas, but I’ve seen lots of fads so I try to be cautious. Things you might want to know about me include:

  • I value simplicity. Using a lot of moving parts in a tool stack is risky in terms of maintainability, extensibility, security, etc. It can – maybe – get you to a goal in the short term, but can end up costing you more in the long term. You don’t want to all-out sprint at the beginning of a marathon. Similarly, looping an entire company into your development critical path is not something to be done lightly. It creates a failure point beyond your control. If you do it, plan accordingly.
  • I tend to take the long view, but I also know that (like most humans) I’m not very good at predicting the future. I try to avoid spending up front for complexity that may or may not be needed later. However, I want what I build to be resilient and likely to survive.
  • My favorite of Larry Wall’s Three Principal Virtues is Laziness. As the Build Buddha says, “If a thing is worth doing three times, it is worth not doing.”

If you have a small- to medium-sized development team whose productivity is suffering due to friction and pain because:

  • it takes too long for developers to make changes
  • developers fear making changes because the results are unpredictable
  • you can’t keep track of what changes are in what releases
  • the tech-debt repo man has been sniffing around your building
  • or all of the above

…then you might want to work with me. To contact me via email, use zen at buildbuddha.com