Organisational growth, a leadership journey, and the tombola book club

Introduction

tombola is going through a fascinating period of growth.  We’re breaking into new markets, we’re expanding our workforce to help us build richer experiences for our customers, and we’re going through some organisational change to help support that evolution.  Our values and goals have always existed, and in a smaller organisation, it was always easy to get to the source of ‘why’ with our work.  As we grow, it’s a challenge for all of us that everyone, from the most junior of members of staff to our senior leaders are all sharing those goals, values, and culture.  Our effectiveness as an organisation pivots around this culture, these values, permeating through the organisation and becoming part of everyone’s DNA.  Elon Musk put it best when he said “Every person in your company is a vector. Your progress is determined by the sum of all vectors.”.  If you’re lucky enough (as we are) to have incredibly effective people, but they’re all pulling in different directions, you are far less efficient as an organisation.

I’d been doing my best to be an effective part in this growth, and as a software developer/architect, who’d transitioned into leadership some time ago now, initially reluctantly – I’m a geek, and I love to play with code.  I realised that my own effectiveness ceased to be how many great systems I could build or how many features I could write into our software, but instead became absolutely about how best I can support and help grow a team that understands “what” they’re building, and critically, “why” they’re building it.  My effectiveness would be at its peak when my team was building the right things, right, without me needing to steer any of that.  I realised I was woefully under skilled in leadership, communication, and effective support of those people who were solely responsible for building value for our customers.  An ex-tombola colleague who’s gone on to great things in leading said it best – you can be the best software developer in the world, but in transition to leadership you become the most junior of leaders – you’re back to “Day #0”.  You have to actively want to progress those skills that would help make you a better leader in the same way that we all as developers have actively progressed the skills that took us from junior through to the top of our game.

I realised that my own knowledge of “leadership” was still in it’s evolving (as it always will be) – I use the quotes as it’s such a broad gamut – it’s communication, it’s cultural, it’s delivery, it’s support, it’s helping to translate vision, it’s delivery of the ‘why’, it’s serving, it’s growth, and it’s so many other things.  There are so many theories to learn, so many practices to master, that it really is like being a junior developer again.  I decided I needed help, and as with my development career, that help would take the form of reading, watching, and talking – all of those things that I felt could help me become more effective for my team, and more effective for the organisation.

It was at this point, after reading a number of books on various elements of leadership that I felt I wanted to share this with others.  tombola has some really clever people, and in talking to some of them, I realised that others were on this same pathway, and wanted to share this with each other too, so we formed the tombola book club.  The books would be those books that we felt would help us grow as people, to help us, to help our teams, and to help the organisation.

The Book Club

My own hopes for this were to develop as a leader personally, but also to help others within the organisation share that learning and openly and honestly discuss how best to apply those things that we were learning and contribute to our own organisational culture.  Learning organisations are effective agents for delivery and their staff feel ownership, empowerment, and purpose, and I wished the book club to be a small part of the driver towards that.

After initial engagement, there were four of us keen to help co-ordinate this, and a number of others across the organisation who clearly wanted to share in that pathway of learning.  We shortlisted (longlisted!) those books that we all felt would be beneficial or that had influenced us, and we asked the group to vote.  The plan being to read one book per month.  The books currently on the list are below.

The membership of the book club is broad – it covers a diverse range of business areas and representations, and has attendance from the full range of staff from the most junior up to the senior leadership team across all disciplines.  It’s about a 50/50 split between technical and non-technical – again, something I’d hoped to achieve but feel lucky that we have.

Running the book club

We wanted this to be more than just ‘did you enjoy the book’ – we wanted richer communication, and we wanted to understand how what we’d read could be relayed back into tombola.  Having seen this format used before, we went with the ‘lean coffee‘ (a structured, but agenda-less) approach to our monthly meeting – this helped us focus the discussion around the book, and generated a flow based on what people wanted to talk about.  People organically raised and removed questions during the month, and we voted on those that were most important to us.

The meeting was then approximately an hour, and the topics were discussed in priority order, though these weren’t strict, and we ended up discussing around some of them into the wider impact of things within tombola, which was precisely what I hoped to get out of the book club.

 

The first month – ‘Drive: The Surprising Truth Behind What Motivates Us’

The club voted to read Daniel Pink’s ‘Drive’.  I’d already read this as part of my own improvement pathway, but I was glad to read it again.  We supported people in their choice of physical, ebook, or audio book, and we setup a chat room for any points/discussion during the month, and an email list for broader topics if needed.  As a personal aside, for anyone with a commute, I can massively recommend audible – I find reading physical books a little slow, but consuming it via audio book really has been a revelation and I’ve devoured books this year.

Throughout the month, questions came in to our lean coffee board about elements of the book that people wished to raise questions on, and very often, they had a tombola slant on them – ‘how could X work in tombola’, ‘do you relate to Y? Is that really how we operate?’ etc. – this was exactly what we hoped to get out of the club, and aside from having a group of people learning, is having those honest conversations about what we had learned that could help us on the journey the company is on.

I think we voted in a perfect book to start the book club – a lot of it was about self, and about your own views on the world, but it also helped us ask some crucial questions around the application of that in our local context.  The book club members agreed that the conversation around the book was almost as effective as the book for them, so we’ll chalk that one up as a good start!

The future – the good, and the challenges

Month two, and The Phoenix Project was voted in, which I’m massively excited by having read it previously and really feeling that although it’s heavy on the IT (and 50% of the book club are non-IT staff), it’s a book about organisational change, about flow of work, and about how an organisation that struggled with communication, collaboration, and visibility ultimately succeeds by going through change.  Perfect!

There is a challenge now that we hadn’t anticipated though – and that is one of scale – the first month went so well that the word is out, and we have almost another 50% of our current membership in new applicants.  We’ll be talking through this as a group to understand how best to support this, as having people on this pathway with us can only be good for the company, but that small/intimate feel of the group while discussing a book really adds value.  I’m sure there’ll be a solution there, we have clever people who want good outcomes.

In closing

I’d strongly recommend any company going through growth or change, any company where you have new leaders, you have a culture of personal development, or you have a desire for people to talk more setup a book club like this.  Your leaders and your staff are likely already reading these books, they’re learning from them, and they will have views on how each of them could benefit your organisation.  At the very worst, you’ve helped to bring together like minded people who want to help you grow.  At it’s best, tapping into that by supporting your staff and their personal growth while sharing that journey with them could just be the thing that helps all of those vectors within your organisation line up and start pushing in the same direction.

If you have any recommendations for books that ought to be on our list, please let us know.

Failed releasing, diagnosing collaboratively, and culture – tales from the trench

A quick write up of an incident yesterday that bit us and caused 2 rollbacks of our live UK website, and I thought I’d write it up as I think it highlights a number of things around the organisation and its culture, and was ultimately a ‘good day’.

Our bingo website release pipeline is pretty streamlined, and we generally release “relatively regularly” (2-3 times per week). I use the air quotes, as 2-3 times a week is nowhere near a short enough feedback loop if we’re attempting to amplify the feedback loop, but we are improving that all the time (the pipeline would happily push all changes to live multiple times per day, but there are more considerations there – a topic for another post).

The key failing up front: It had been 8 days since we released (for no good reason), and our release yesterday morning seemed to go great – all unit tests passed, integration – tick, e2e – tick, smoke tests – tick.  We’d manually checked our inactive stack (we do blue-green deployment), and all was good to go.  We switched the customers over to the new release, and all was great.

Then it wasn’t…  About 10minutes after the release we started to get some exceptions on one of our dashboards:

All of which were loudly looking like database connectivity issues.

Which was quickly followed in hipchat by notifications from our customer service staff:

Cultural Win #1

We’re not what you would call a DevOps setup – we do have separate development and operations teams, and in the past, we have struggled in the same way that a lot of organisations that separate these functions do – we’re on the same journey, but looking out of different windows. It’s the usual issues that have been blogged about by others at length – infrastructure blaming developers for setting the world on fire, developers blaming infrastructure for moving slower than they want – both wanting to achieve exactly the same outcome for the business, neither one of them realising it.  You’ve seen it play out in many organisations I’m sure.

We’ve spent a lot of time as an organisation and as teams trying to improve upon our communication, respect, and overall culture, and it played out brilliantly in this – we all gathered together, talked about the issues, investigated quickly and came up with some cracking approaches on diagnosis that helped us rule out both any infrastructure changes and database changes really quickly.  There was no blame, there was no ‘us and them’, there was just ‘let’s get this fixed, together’ with a focus entirely on the customer.

For those organisations that have evolved their practices into either a more DevOps approach, or have gone through the cultural change and have evolved a shared why and a shared journey, this may seem simple, but even 6 months ago this would have been a situation that generated far more friction and silo’d mentality.

Although we were still having the live issues, we knew that rolling back the site and investigating together was then the right thing to do, and there was shared ownership.

Root Cause, and Cultural Win #2

As the feedback loop wasn’t great: 8 days of regular code commits across two teams, a number of active projects in development, and a number of new pathways (albeit feature toggled off), so getting to root cause was a daunting task.

We peer review every single merge to our releasable branch, so if it was code, it was likely to be something very subtle.  It turned out there had been 193 commits and 231 files changed, so it felt like it was going to be a needle in a haystack.

We got lucky – while I was reviewing a piece of code, I saw a unity resolution setup like this:

container.RegisterType<ICoreThingyService, CoreThingyService>(new ContainerControlledLifetimeManager());

Oh, snap. Our services almost all register as PerResolveLifetimeManager, and this one had been new’d up as a singleton.  This had dependencies against data connections, and although those data connection dependencies were per resolve, it would never matter as we had one copy of the above for the lifetime of the application, so the connections were getting held onto (and worse, during connection pooling saturation, disposed of without getting re-setup).  Suddenly it all became clear on why the core issues were all database related.

We have two teams working on this codebase, and again, it’s an indicator of the strength of our interactions and culture that it became then a blameless discussion, an agreement on this as the root cause, and, as soon as the fix was put in place, a shared review of the fix to quickly get it available for testing.

It’s a loooong time since I’ve been bitten by a singleton in a codebase, but I would guess it won’t be the last in my career.  They’re awesome, except in the many, many situations where they absolutely are not!

Continual Improvement – Next Steps

I’ve worked at tombola now for a little over 8 years, and it brings great comfort that the organisation is where it is now.  It’s always been a generally good place to work culturally, but there’s definitely a strong shift over the past year or so into something that is far more collaborative, more respectful, and with a greater understanding of the ‘why’.

Some steps I’ve identified from this one issue:

  • Shorten and amplify the feedback loop – although our feedback loop in terms of dashboarding, alerting, etc. is pretty good, if we had been releasing more regularly as a matter of course, we would have seen this within a very short space of time after it was introduced, and then diagnosis would have been so much easier and quicker.
  • Tie in simple load testing to releases – once I’d integrated the fix into our release branch (which then went through all of our testing listed above, and automatically deployed through our dev and UAT environments), I load tested it with apache bench to validate that I could not replicate the problem.

    Although I could hammer the response times (the server I load tested isn’t load balanced and is far smaller than our production boxes), I was hitting it with enough load to saturated and replicate the problem we’d seen in live and we had zero exceptions raised from the testing.I will ensure that we tie this into our release cycle at some point so that we routinely perform automated load testing on our deploying code, and alert the pipeline if there are any issues.
  • Cultural – I think tombola are on a great path here already, but it feels great to be part of that cultural shift towards more respectful, shared collaboration.  I’ll endeavour to live that ‘why’.

re:Invent 2017

I feel like I only ever write up conference attendance on this blog, apologies!

I was fortunate enough to be one of the 4 developers tombola sent to re:Invent this year –

There were some seriously big announces in both of the keynotes – I won’t go over them here, but you can read about them straight from the mouth of AWS.

The keynotes are both available to watch too:
– Andy Jassy Keynote
– Werner Vogels Keynote

The conference had many different strands and covered some of the bigger hotels in Vegas, but my own particular drive was around architecture, devops, and performance.

Some of the talks I attended that I feel will have a direct impact on the future direction of the business, and will see us leverage performance and cost saving elements while broadening our approach across the organisation.

Cache me if you can

Markus Ostertag @osterjour watch now

“There are only two hard things in computer science: cache invalidation and naming things” – Phil Karlton

A really powerful talk for us – we feel we cache well, though it’s clear from this talk that there is so much more that we can do.  It focused on becoming faster, having your app do less, so that you can do more (in aggregate).  Memory, we all know, is faster and cheaper than CPU, so this was one of the primary wins, and it demonstrated key caching strategies and techniques at each layer.

One thing we haven’t yet entertained is caching via cloudfront of our main web application.  Even if the TTL is 0, cloudfront could help as it is optimised for that ‘last-mile’ delivery of your app.  Couple that with [email protected], and you have a potentially nice, cacheable, yet with dynamic elements means of getting your site out more easily to customers.  [email protected] could also give us a nice pathway into our A/B testing work.

He talked significantly about what to look for in your caching – what the big hitters were, where you were getting the hits/misses and where optimisations could be made around this, and highlighted how even small changes from monitoring these could have massive impact.

Some key guidelines:

  • Choosing your TTLs on caching wisely is another obvious gotcha – even small TTLs help, but obviously aggressive caching to avoid any ‘walk of shame’ to the data layer is rarely a bad thing.
  • Cache everything! (Sessions, Results, Aggregations, Templates, Environments, Configurations, etc.)
  • Log and monitor everything – you can’t optimise your caching strategy if you don’t know the simple outputs like hits/misses
  • If you’re not using close to 100% of your ram, you have an optimisation opportunity there
  • Don’t worry about data duplication in caching too much – if it achieves speed
  • Don’t be afraid of negative caching – if a ‘no results’ is valid, consider caching it to avoid the next call having to do the database call

The adding up of these minor performance gains was put into sums far better than I could here, though even making a 1ms improvement when you are seeing 10,000 requests per second is still 10 seconds overall saving, which added up to 7,000+ instance hours saved per month.

There was a very good comparison on Elasticache of Memcached versus Redis variants.  I can’t immediately find a situation where we’d use Memcached over Redis, but if you have one, please comment.

He talked heavily on caching in front of the DB, though it’s one of the bigger changes that you can make as there’s a significant need to ensure the architecture is aware of it all.  You can either cache using TTL invalidation, or keeping the cache in sync at all times with synchronous writes – it works, but it’s a huge change to the application.  With RDS, you can have uncoupled writes and invalidations via lambda (are we seeing a pattern here yet on lambda?), which effectively gives you DB triggers ala SQL server.  If using DynamoDB, you have DAX (Dynamo DB Accelerator) which seems like a no brainer if you want to eek out performance.

Consider your 80/20s when looking at caching:

  • Find your heavy hitters – the bigger operations either in amount of data processed, or amount of requests
  • Have them in memory as much as possible
  • It pays off to do special things for them and handle them as a special case

Scaling to your first 10million users

Ben Thurgood watch now

“Many decisions are reversible, two-way doors” – Jeff Bezos

This was a really interesting talk about the journey from small scale, single user sites all the way up to millions of users – things to consider, AWS services to perhaps look at, and there were certainly takeaways for us to assist with our current journey towards improving scalability. Rather than re-iterate the details of the talk, it’s best to just watch through it and decide where you are in the evolution of your architecture, and what you can take away as wins.

A day in the life of a netflix engineer III

Dave Hahn @relix42 watch now

The numbers from netflix are just astounding:

  • 100,000,000,000s events through their data pipeline every day
  • 10,000,000,000s reqests handled by edge systems every day
  • 1,000,000,000s metric time series, aggregated, collated and stored every day
  • 100,000,000s hours entertainment streamed to customers every day
  • 10,000,000s devices talking into our service every day
  • 1,000,000s requests per second through the front door every second
  • 100,000s EC2 instances answer those requests
  • 10,000s auto-scaling instances every day
  • 1,000s production changes every day (code pushes, feature flags – daily average about 4,000)
  • 100s micro services to create that experience
  • 10s terabits of video over the internet every second
  • 1 goal – winning moments of truth

I found it interesting that there has been a bit of noise on twitter about cargo culting of netflix, and doing things ‘just because netflix does it’ – I’d agree that you should never just follow blindly (after all, you’re not netflix – what works for them…), but equally, learning from some of the practices they have in place both technically and culturally I think is aspirational and really does give a focus to that passion and drive to improve.  The numbers are bigger, but the challenges are often the same.

Some really good discussion on the tooling they use to facilitate the above in this talk too, and there are certainly tools we’re using already that were OSS’d by netflix, and I’m sure there will be more in future.

Performing chaos at netflix scale

Nora Jones @nora_js watch now

“Chaos doesn’t cause problems, it reveals them” – Nora Jones

A contender for ‘best talk of the conference’ for me and one that immediately inspired me towards both building in resilience, but also introducing chaos to see just where that resilience is, and more importantly, is not.

Chaos Engineering allows us to expose weaknesses in a way that testing in all forms doesn’t.  Testing allows us to address ‘knowns’, and knowns are generally so much easier to plan in and predict.  Chaos deals with the unknowns – part of the reason they are termed ‘experiments’ rather than ‘tests’.  Chaos engineering gives us a new way to increase confidence – how will our payments service handle increased latency with our third party supplier?  How would we handle half of our load balanced web pool falling over?

Chaos is inevitable – there are companies out there who make a living based on the fact it exists.  Chaos engineering attempts to bring that knowledge earlier into the flow and allow us to understand the problems before it becomes a pagerduty alert at 2am.

Nora gave an effective pathway to introducing chaos at an organisation – do not start in production, start with non-critical services, and only include services that *want* to be chaos’d.

The forces of chaos were highlighted as:

Obviously, safety and monitoring key business metrics is key.  Really worth a watch.

Summary

An incredibly motivating conference, and something with direct takeaways for the business.  Seeing others talk about and be open about operating at scale, and how they have solved the same problems that we’re also solving, and being open with their knowledge (both in talks and out of them) was really empowering, and I feel sure that I and my team will be applying what I learned for the foreseeable as we work towards the future.

DDDNorth – a day of free learning in Bradford

It was a 5am alarm that woke myself, and likely my colleagues, on a saturday morning when most people would be comfortably in the land of nod, or contemplating how best to laze away their saturday. For these tombola developers though, it was a drive down to Bradford to attend DDDNorth – a day long free conference setup and run by the community and supported by some brilliant sponsors. The drive down was uneventful, and we were presented with caffeine and brekky before the talks commenced.

Myself, Michael Tomaras, and Luke Hill were in attendance – I’ll relay the talks that were most inspiring to me.

There were two key talks for me – one, which I’ve heard and read a bit about anyway, was around the Spotify model for scaling agile by Stephen Haunts, and the second was a war story from Nathan Gloyn after 18 months of working on a number of projects where microservices played a part.

Microservices – Nathan Gloyn

We’re on a journey of growth at tombola that is seeing us diversify our software products in order to facilitate growth more readily – and although I’ve studied significantly around architecting, building, and supporting microservices, I thought a talk dedicated to ‘what I’ve learned after a year of building a system’ would be right up my street.

There was a bit of background about microservice patterns (and anti-patterns), and discussions around indetification of bounded contexts, fat vs thin microservices and just some key gotchas – security, service discovery, logging (and logging, and logging, and logging some more).

Some key takeaways:

  • Deployment (deploy small, avoid single repo for multiple services),
  • Identity and Authorisation (get these right up front – don’t attempt to retro fit it, it’ll get inordinately harder),
  • Build based upon need (not because it’s cool),
  • Configuration (strongly consider configuration management – consul/zookeeper/et al),
  • Logging (you can never log too much),
  • Monitoring (ensure you understand the baseline and health of each component, but ensure you are monitoring the system as a whole too),
  • System flow (correlation / session tokens in order to track journeys and requests through various systems is crucial)

None of these new, though distilled well by Nathan and he delivered an effective talk. The only thing missing from this for me was around the organisational change required to support microservices – a move we’re currently undertaking in terms of a shift away from a more monolithic single deploy application into many more smaller, co-ordinated, API driven services. Conways Law and team structure vs architecture design within an organisation is of key interest to me, and I think it’d have been nice to see a little more around this in the talk.

Scaling Agile with the Spotify Model – Stephen Haunts

Another useful war story about how Stephen and the team at his previous employer had managed the growth of the organisation via the spotify model which they modified in a rather comic ‘lord of the flies’ motif, with islands (multiple companies) and lookouts (marketing/sales type roles that protected the developers from the external landscape that was very much waterfall / deadline driven).

Some really refreshing pointers during this for me on just how best to empower and inspire the workforce while adapting to the growth and change of the organisation.

Key slide of the day for me though was one presented from a Harvard Business Review article.

This is such an incredible visual metaphor for just how satisfied, engaged, and inspired employees would be within an organisation, and I think this will be the one image that goes up on the wall in the office – definitely something to aspire to.

Crosspost

Post is also available at ops.tombola.co.uk (or will be, soon!)

Roundup

A brilliant day of learning, some really useful talks, and a day to get some discussion with peers from the industry – all for the bargain price of £0.00. Further discussions with peers in other sectors who highlighted that recruitment for them was as difficult as it was for us, no matter how cool or interesting the work is you are doing (by the way, we’re hiring! see our careers site)

Free learning, free food, free chat, free inspiration – what’s not to like? Thanks DDDNorth.

Velocity Conf Europe 2013 – How to utterly inspire in three short days

The past 3 days have seen me attend VelocityConf Europe 2013 which (as the sub-title suggests) focuses on Web Performance and Operations.

Talks I attended can be seen here, though thankfully they seem to record all sessions, so if you missed it they’re available from here.

I had the chance to hangout with the @toptabletech guys (http://tech.toptable.co.uk/) (@ryantomlinson has just joined them and he moved to them from working with me), and they’re all top blokes – very clever, and clearly care about what they do.

tl;dr

Without a doubt one of the best conferences I’ve attended – the mix between operations talks (though often these were given a very devops slant) and web performance really did tick all of the boxes.  It feels very much like my learning time will be consumed by some of the approaches, tools and techniques I’ve seen covered over the past few days, and I remain utterly excited about putting some of this into practice.

It does make me question some of the cultural aspects within my own organisation – something I will endeavour to at least attempt to communicate effectively upon return – there are a lot of things we could be doing better (myself very much included).

Overall, not that my passion was lacking anyway, though I’m entirely re-fired up around the areas I’ve seen talked of – monitoring/metrics, continuous integration/deployment, testing all the things, and automation, with that constant backnote on the cultural.

I became acutely aware of just how narrow my scope of development was (.net developer/PC based), and time and again a lot of the tooling shown while it likely worked on windows ‘ok’, was better geared up to either a mac os/linux background – the mac to PC ratio was scary, and it’s certainly something where I’m now going to experiment with mac as a dev machine (VM’ing into windows for the .net stuff).

I’ll cover some of the details on some of the talks I attended, though obviously covering every talk from 3 days worth is going to see at least some repetition so apologies if I miss anything/anyone out.

The below is as much so that I have all of the pointers in one place to the stuff I want to look at, though hopefully others will find it useful.

Responsive Images – Yoav Weiss

Cracking start, Yoav highlighted 72% of responsive websites serve the same resources to all form factors (we use picturefill).  I liked the look of http://sizersoze.org as a tool to highlight what you were doing at different breakpoints (in terms of savings to be made, etc.)

He highlighted mobify.js, which although a clever implementation, feels like an overwhelming hack to get around some of the limitations currently in play on browsers/http.

First mention of http://worldwidepagetest.com/ in this session too.

Be Mean to your code with Gauntlt – James Wickett

I moved from the more ops’y (TCP tuning/TLS perf etc.) talk into James’ security talk, and I wasn’t disappointed.

Gauntlt provides a means of automating a number of other attack tools and overall was the first thing where I thought ‘getting that into our build is essential’ – another talk where ‘it’s easier on a mac’ (probably the first, not the last).

Making Government Digital Services Fast – Paul Downey

Loved this talk – really nice to see how effectively these guys release and how the mindset shift was entirely around ‘what does the user want’.  Their ‘dark release’ rollout worked well, and it was one of the first talks (though again not the last) that highlighted how important instrumentation was – how do you know you’ve been successful (or otherwise) if you don’t have figures backing it up.

Stand Down Your Smartphone Testing Army – Mitun Zavery

I mention this not only because it was a good talk, though I really must have a look and play with http://www.deviceanywhere.com/.  Really nice little tool.

Testing all the way to production – Sam Adams

Loved the ‘continuous delivery’ from day 1 approach, and the mindset that each commit I make ‘I believe this code is safe to go into production’, though obviously again the monitoring metrics come in, and it’s the pipeline’s job to prove that statement wrong – strong enough pipeline builds confidence that you’ve caught ‘all the things’.

They do a lot of ‘in live’ testing, though their isolation model seemed to work really well – something I have to investigate.

Global Web Page Performance – James Smith

Although the demo didn’t go great for James, I’d used the site the day before as it was mentioned in one of the workshops and it’s a really nice abstraction over http://webpagetest.com – certainly useful.

HTTP Archive, BigQuery and you! – Ilya Grigorik

This was one of those ‘holy shit!’ demos – taking HTTP Archive data and making it accessible/queryable – see (and play with) http://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/ – incredible.

Gimme more! Enabling user growth in a performant and efficient fashion

Some useful stats in this great talk – by 2017 there’ll be 5.2 billion mobile users, making more than 10 billion connections!  Mobile video will increase 16 fold between 2012 and 2017.

New Image Formats

Images make up 61% of page bytes – 65% of page bytes on mobile!  The encoding techniques we have in place are in some cases 15 years old.  WebP (less supported) and JPEG eXtended Range (JXR) look to be the next big thing in image compression and both although not heavily supported right now, if you have in place content-negotiation/browser sniffing, you could save considerable bandwidth.

Code Club – John Edwards

I love this – https://www.codeclub.org.uk/ – teaching children to code in a structured/supported way, and volunteering your own time to help.  I will be investigating this to see how best I can fit in – time is key I guess (support from employer etc.) but I really love the concept so I hope I can get involved in some way.  John Edwards did an amazing job of presenting it, and the video (http://www.youtube.com/watch?v=Ci3hY83rUwU) had me both chuckling and incredibly emotionally moved.  Great cause.

General Thoughts – Culture

A number of the talks focussed around the cultures within the organisations that we work, and in how the culture almost entirely underpins how and what you achieve and the direction of work. 

One of the best talks of the conference for me was given by John Willis, entitled ‘Culture as a Strategic Weapon’, which focussed on some of the core tenets of successful devops (CAMS – Culture, Automation, Measurement, and Sharing).

It’s made me more determined to keep pressing on with both working with, and encouraging new directions within my own organisational culture – as he said, ‘If you can’t change your culture, change your culture’ and the immortal words of ‘get the hell out of dodge’.  Working towards a better organisational culture feels like the right fight to be having, but this one talk has generated me more inspiration than any other single talk at the conference.

When seeing how effective some of the guys I talked to were being with things like ‘30% time’ and how much other organisations invest in their staff, it very much feels like there are lessons I can bring home here.

General Thoughts – Tooling

There are so many cool tools – too many to name, though the links I’ve put above are a good starter – there are so many people working on tools to both monitor, test and graph ‘all the things’ so that we get closer and closer to reliable, repeatable, understandable and maintainable releasing.

Closing Thoughts

I thankfully have a solid team of developers where I work who will be very keen to be involved in this.  We’re not bad, we do automate a lot of our build pipeline, though we don’t have enough monitoring/metrics in place. 

The conference has entirely re-invigorated me and as I sit here writing up, the thing exciting me most is ‘where do I start’ – I look forward to the playtime!

This was a great conference, and was great to be around likeminded, passionate people who were all about sharing how they got to where they are, where they want to be, and how they intend to get there.

Oh, and thanks to the facebook staff who took us to the pub on thursday night – I really enjoyed the talk with you guys and learned an awful lot!

 

Bring it on 🙂