I’m a good software engineer, but I’m not one of those engineers that delights in engineering, and is sought out for their engineering brilliance. I just want to build stuff and I want people that play with the stuff I build to be excited by their experience.
The implication is that any activity that is not focussed on creating and building great digital experiences is, for me, a distraction that grates. If there is something I’m building, then my tax return is gonna be late, and the office will be untidy. However, I reserve my maximum contempt for that time spent working out what software infrastructure to run, where to run it and how to deploy it correctly, consistently, securely, cheaply, flexibly – and quite a lot of other adverbs. Because that time isn’t occasional, it is constant, it is unavoidable, it is tedious and I am shit at it.
Designing and deploying infrastructure requires a lot of research, testing, experimentation, process and discipline. Many web agencies seek to mitigate this risk by employing the same pattern for years at a time. For example, they select Django or PHP and they get a contract with Rackspace and there are a bunch of other dependencies and that is the pattern. Node.js comes and goes. AWS and Digital Ocean arrive but the pattern is the pattern and all the great benefits of that new technology are ignored.
And I sympathise because I struggle to keep with up the latest technologies. I am frequently conservative in my choices because I simply don’t want to spend time learning what the recommended web server is today for a given class of app. What the recommended driver levels are or learning the subtle differences in how to deploy that latest version and testing all the combinations of packages.
Many engineers enjoy learning new technology – they consider it an opportunity to expand their understanding of the universe. But most don’t, and I have become one of those. We have jobs that require us to produce stuff and we are rarely judged on the currency of our technology choices.
The problem is getting worse as the pace of new new technology and resulting options increases. And whereas 15 years ago there were operators that did the installation today we have DevOps – and this is frequently just an excuse to get the developers to manage the environments without the tools, budgets and training to make it meaningful. I can barely keep up with the new languages and development methodologies – how does anyone expect me to keep up with DevOps – especially as I hate touching infrastructure and all it awkward knobbly bits?
So we built Chill Code. For me, it’s the product that I have always wanted, as a good but not fanatical software engineer. I want to know that I can go to a single location, search for patterns that broadly match my need and that have been implicitly embraced by the software community (as expressed through the fork count). I want to be able to deploy those patterns, with my source code or content from GitHub, in one click, and know that the deployment will be consistent regardless of which cloud I elect to use. That way I get to concentrate on what I care about – building things in code that give people great digital experiences.
Chill Code 