O(n) Week Day 1, 2015 – Somewhere in the Yarra Valley, Victoria: A group of fresh young faces gather in small groups around a house-cum-conference-centre nestled amongst the trees. A communal dinner has been shared and there are beers and soft drinks in-hand: some play pool, some cluster around a newly learnt eurogame, some just chat. Our 2015 graduates are starting to relax and unwind at the end of their first day of (O)n Week.
Over the past 12 months REA Group has been moving towards a structure where individual teams will manage their own infrastructure.
Start ups (or companies that behave like one) should already have devops culture. At REA Group we’re trying to bring a startup feel to individual teams, so engineers at the team level can decide on what new technology they want to try out, test and learn ahead of the rest of the organisation, and ensure the company stays adaptable and ahead of the curve.
dead air (noun): a period of silence especially during a radio broadcast
bash-my-aws (foss): set of bash functions that reduce dead air when managing Amazon AWS resources with CloudFormation.
DJs avoid dead air like the plague. We should too.
At the command line, dead air is the time between intention and outcome. It’s the time spent constructing commands and waiting for them to execute. It makes demonstrations tedious. It’s unacceptable for oft performed tasks.
Having the right tools for the job and knowing them well makes interactive use a breeze. bash-my-aws provides simple, powerful tools for managing Amazon AWS resources with CloudFormation.
This post was originally published internally, as an appeal to REA colleagues.
“Getting Shit Done” is the catchphrase on everybody’s lips, and deservedly so! When we deliver new functionality, our users regroup and flock to us, our customers grudgingly respect us, and our shareholders rejoice. When the novel concepts invented by our product managers take shape as they watch, their eyes light up with pride and enthusiasm. Programmers are never happier than when fire and magic fly from their fingertips; products that change people’s lives materialise from thin air, and insurmountable problems melt like butter. Beer flows freely, parmas are devoured and our managers circulate glowing praise within the company.
We have all felt the opposite too; long months gone by without new features, frustrated and bored developers; product managers forced to nervously adjust their collars and disappoint their superiors, with often dense technical reasons they can barely hope to convey. New features pop up like mushrooms on our competitors’ sites, and we wonder: why didn’t we do this years ago?
Yet when I hear this phrase “Get Shit Done”, I grimace; my teeth clench and my back involuntarily stiffens. Why? There is truly nothing I want more, and it is clearly important; many of our most talented teammates live by it.
Employee led innovation is nothing new.
Google 20% time is acknowledged for producing a number of key product innovations like Gmail and Docs (although it’s understood they have officially killed off that perk). Over at Facebook, founder Mark Zuckerberg spoke extensively of “The Hacker Way” in their IPO filing to the SEC.
What is not as widely known is that employee time can be traced all the way back to Post-WW2 in the United States. It was 1948 and multinational manufacturer 3M instigated “15% time“. In 1974 an employee by the name of Art Fry used this time to develop a means of applying an adhesive to the back of a piece of paper and the post-it note was born.
In addition to the Silicon Valley titans, several companies have embraced employee time to foster innovation, all with pretty cool names: BlueSky (Apple), [in]Cubator (LinkedIn), Hackweek (Dropbox), The Garage (Microsoft), ShipIt (Atlassian).
“Microservice” is becoming a buzzword in the industry today. Developers all over are experimenting and learning more and more about it. It’s a cool concept and we’ve started working with it at REA. There were several challenges that we faced with microservices and one of the key ones was tracking and documenting them.
After lots of deliberation, discussions and debates we could summarise our dilemma and needs as:
“Wouldn’t it be cool to have a living, breathing tracking system for all the microservices that exist in our ecosystem which will emit all the key information that we would like to know and have?”