Ben posing in a blazer at the gym
At CloudBees, we have a lot of seriously talented developers. They work hard behind the scenes to keep the CloudBees Platform as a Service (PaaS) and our on-premise Jenkins solutions up-to-date with all the latest and greatest technologies, gizmos and overall stuff that makes it easy for you to develop amazing software.
You can follow Ben on Twitter
Ben, What is your role at CloudBees?
I handle the "Forge" (Git, Subversion, "Maven" repositories), billing development and operations, DEV@cloud operations.
My timezone of interest is 9pm UTC - 11am UTC - a long day for sure - but we don't work all the hours every day!
Areas of "focus" include - UNIX administration, automation, operations, development (Ruby / Java if I have to / bash when I want to / whatever else has been madly coded), deployment to AWS infrastructure with varying degrees of testing and automaton, testing, fault resolution and root cause analysis.
I hate the term Full Stack Engineer, but not as much as I hate the term Architect. We just do what needs to be done to get the job done and keep customers operational.
In my other lives I am a father of two and husband; and a cyclist, cycling coach and cycling advocate!
What does a typical day look like for you? What are CloudBees customers like?
Once I've finished my cycling training (getting out of the house is critical when working from home on a long-term basis)...
My day looks like most people's work days - but tends to be spread out a bit more. Some days I start later - and then work later other days if there is an emergency or Amazon is causing mysterious EBS issues. If I need to take the kids swimming / soccer, then I do that and then return to smash the monitoring system later.
I have a choice of working environments - home / office / library - all work can be done remotely.
My normal day consists of going back through any tickets that came in, clearing / following up on ones that haven't been dealt with, or have been sent back from the customer. I don't take responsibility for all support - I cherry-pick the items that I can deal with quickly or are in my area of the platform.
After that I'll start/continue working on tasks based on assigned priority or biggest hurt point of day / week / month / year. One recurring theme is resolving problems that are consuming resources every day - the pain points.
Customers range greatly from those who are using the PaaS as a magical silver bullet - through to those who are cloud savvy and understand the tradeoffs; the most astute customers generally expect the least from us in terms of engineering; but when it goes wrong they need it resolved immediately. We strive to identify trends and patterns and then I raise a suitable meme with sarcastic comment pointed at our DEV@cloud team leader (@recampbell) to encourage him to resolve the issue.
Ben's highest priority is finding the funniest memes!
Because Australians are often left alone in the twilight between the US and EU support regions I'm required to have skills across a variety of operational areas and systems. Tasks include turning off the monitoring system, forwarding tickets, terminating instances, and creating amusing memes about my colleagues questionable coding and support.
What are some of the most common mistakes to avoid while building an app?
In the context of building our internal infrastructure, the biggest issues we have are:
Failure to automate - without automation we can't keep up with building new server types or upgrading instances
Failure to document - if it's not documented, then when it fails we call the person who created it
Failure to handover to operations - there is a world of difference between something that runs, and something that can be managed by operations
DevOps is a good theory, but really doesn't scale up very well. It is far too disruptive to have developers monitoring a production environment 24x7 - responding to alarms and generally being interrupted. Much better to hand off to dedicated ops and automate as many tasks as possible.
If you weren’t working in PaaS what would you be doing?
In the last few years I've started cycle coaching with a local club - this has been rewarding - and has seen me integrating new IT systems into the training programs, power output analysis and general business operations. I'm now coaching a team of over a dozen riders who are focused on competing in a 3 day stage race in May - road racing, criterion and time-trial.
Ben is the third rider in this group of avid cyclists
I aspire to being a not-quite-as-slow bike racer. At our recent club criterium (pictured below - I'm 3rd rider) - we averaged 45km/h for over 40 minutes - which tends to hurt a lot.
In a previous life I was a senior systems analyst - I worked in a variety of contract positions in government, telco and healthcare positions on a variety of projects. It's not very exciting.
What is your favorite form of social media and why?
I don't really use social media heavily personally. However, I do use Facebook to organise cycling events and training - and I love harassing colleague @michaelneale on Twitter .
With the ongoing limits to Facebook page reach, the utility of Facebook for inexpensive marketing seems to be waning. It will be interesting to see what takes its place.
Something we all have in common these days is the constant use of technology. What’s your favorite gadget and why?
My favourite gadget would have to be the Garmin on my bike. Using the Garmin and Strava , I'm able to compare my results over time and analyse the effect of training on performance for myself and my team of riders.
Being a software developer I'm also able to slice and dice the data it captures and present that information back to my club in interesting new ways to drive motivation and friendly competition. Personally - getting a personal best on a climb gives a great sense of achievement - and you can go back and analyse results similar to those shown in graph pictured.
Performance results from a challenging bike ride
Several years ago I started to create something like Strava, but the supporting technology wasn't really there (we were limited to heart-rate, speed and elevation). The explosion of GPS technology (Garmin, iPhone, etc.) has made for a much more compelling solution that can track riders over time and space.