11 Learning Experiences from Web Directions 2015


Jeremy Nagel, LearnosityIn this week’s blog, Jeremy Nagel, one of the Software Engineers here at Learnosity, gives an account of his recent experiences at Web Directions 2015. Jeremy was fortunate enough to attend and speak at Web Directions, an Australian conference that brings together the web industry’s leading experts from around the world, covering a full range of interests for web professionals. Find out what Jeremy’s key learnings were, for those who couldn’t make the conference.

Jeremy Nagel on Web Directions 2015:

Learning #1: Don’t Use Google Slides for High Stakes Presentations

I had a pretty significant technical hiccup at the start of my talk: despite having no issues during the run-through two hours before I spoke, when I got up at 2:50pm, half my slides decided not to load and instead showed “Content could not be displayed”. I had backups ready but discovered that both the PDF and .pptx versions were corrupted and clean forgot to use the Google Slides offline backup:(

Fortunately I knew my material well enough that I could power through anyway (and quite a few people came up to me afterwards and said “That was deliberate wasn’t it?”) but it’s not really the kind of stress I need in the moments before giving a high stakes presentation! It wasn’t entirely Google Slides fault: there was an issue with the WiFi that caused the proximate issue. Nonetheless, it was frustrating that the PDF backups got corrupted and this is the second time I’ve had similar issues with Google Slides (in the warmup event, my browser froze immediately after I clicked ‘Start Presentation’). Overall, it just doesn’t seem worth it.

I’m gonna go Keynote from now on.

*If you want to see my slides in their uncorrupted glory, go here.

Learning #2: Break Out of Silos

Cap Watkins from BuzzFeed gave the keynote speech and dropped many a gem of wisdom as well as some awesome (and sometimes disturbing) animated GIFs. Key takeaway for me was avoiding “it’s not my job-ism”. Cap spoke about how he changed the culture at BuzzFeed away from a “designers do the PSDs and throw them over the wall” to “designers code and developers play with photoshop”. I really like this idea. Cross skilling helps everyone improve and gives the team more resilience + lower lottery factor (key designer wins the lottery and leaves the job, destroying company cos they can’t find a replacement).

Learning #3: Deploy Often & Cautiously

Something I heard from both Cap and Tom Loosemore from Gov.uk was the importance of continuous deployment. Whilst at Etsy, Cap’s team would deploy up to 40 times per day. Tom’s team routinely deploys 10 times per day (and this is in government!). I was really impressed and intrigued by this because Learnosity generally only deploys once every 3 weeks.

Cap was gracious enough to come over for a chat at the speaker dinner and expanded a bit more upon this philosophy of continuous deployment. His argument is that the more frequent deployment is, the less likely any individual deployment is to break the product. As well as this, deploying often means the team knows how to quickly fix things if something does break whereas if deployments are infrequent, it’s easy to get a bit rusty.

Nonetheless, super frequent deployment feels a bit risky. Surely QA won’t have a chance to check everything thoroughly if new releases are getting fired off tens of times per day. Some solutions to this I heard were:

  • using feature toggles so you can turn off features if they break without needing to redeploy (and we’re not just talking entire new features: a feature toggle could apply to a bug fix or a small enhancement to an existing feature)
  • lathering the product with automated tests including perceptual diff tests so that your CI will pick up bugs before they go out into the wild

Learning #4: CCS Modules

Glen Maddern and Mark Dalgleish (both from Melbourne) gave us a cool intro into the world of CSS modules. My understanding of CSS modules is that it allows you to write web components with entirely isolated CSS so you avoid unwanted cascading and naming collisions. Chatting to some attendees afterwards, some people felt it was overcomplicating things and solving a problem that didn’t really exist, but I see a lot of value in this approach.

Rather than having to do crazy nesting like:

GotHub SnapShot

You could just do:

GitHub SnapShot 2

because someGenericClassNameThatWillProbablyBeUsedElsewhere will be automatically given a unique suffix/prefix by CSS modules. This would allow us to write highly semantic CSS because the CSS will be locally scoped by default instead of globally scoped.

Plus with CSS Modules, you can replace all your class names with Emojis like Glen did 😀

CSS Modules

I’m excited at the idea of using CSS Modules or Polymer (Google’s web component polypill) for new parts of the Learnosity APIs.

Learning #5 Automated Site Speed Testing

Maciej Ceglowski gave a hilarious and hard hitting keynote on the rising problem of web bloat. His argument is that no single web page should take up more space than a piece of classic Russian fiction like Crime and Punishment (2.3MB of text content). This is something for us at Learnosity to reflect on because as a 3rd party JS API provider, if we’re not careful, we can cause web bloat for our clients. The bar is substantially higher for us. We can probably only afford to take up 1/6th of Crime and Punishment because the host page is going to have images and other content as well as our scripts.

How can we ensure that we don’t exceed this limit? Kitt Hodsden has a few ideas. She gave a talk about using various grunt plugins to monitor load time as part of the build process. The end result is a private mirror of WebPageTest.org that allows you to check load times on the CI server and block any releases that breach your performance budget.

Learning #6: Learn JS Properly

I was really excited to see that Eric Elliot was speaking at WD15. I’d come across his material a few weeks beforehand via Javascript Weekly and it really hit home for me. He went through a few of the key concepts like:

  • avoid super() calls like the plague
  • don’t use classical inheritance unless you have a REALLY good reason to (otherwise you can end up with the gorilla-banana problem plus brittle class hierarchies that can cause domino effect bugs all down the inheritance chain)
  • favour composition over inheritance

Talking to attendees afterwards, a lot of people found the talk over-opinionated but I didn’t hear anyone seriously argue with him.

I was personally curious about whether composition could also lead to brittle hierarchies. For example, what happens if Object A is composed by Object B and C and Object B is composed by Objects D and E? Is that not another case of a hierarchy which could cause flow through bugs down the chain? I spotted Eric after the talk and asked him about this. As it turns out, he’d already written an article answering this question. TL;DR: you’d be unlikely to have a whole bunch of child classes composing from the same parent because you’d probably create several variants of the parent to cater for different use cases. Makes sense to me. I guess good code review can prevent many of these issues but composition does seem less likely to cause issues than inheritance.

I’m going to avoid classical inheritance from now on and also concentrate on understanding the underlying principles of javascript. Right now, I’m pretty sure I would not score too highly on Eric’s 10 interview questions every JS developer should know! There’s much I want to learn about closures, functional programming, promises etc.

Learning #7: Be Patient

In Cap’s keynote, he mentioned the hypocrisy of change management in tech: we’re happy for incremental change with our products, but we often expect radical change from our teams and companies. This struck home for me because I’ve been trying to ram checklist driven development down my team’s throat and it hasn’t really been working. Cap suggests being patient and looking out for the little wins rather than being disappointed that people still aren’t ticking off the checklists with each ticket.

Learning #8: Use Pre-Mortems

Julia Clavien gave a great talk on cognitive bias in software development. One of the antidotes she proposed was the pre-mortem, in which teams dream up everything that could possibly go wrong before a sprint starts. This thought process can help to make estimates more realistic and surface hidden dependencies. As a lover of apocalyptic fiction, I really like this idea and am going to float it with my team 🙂

Learning #9: Get a Distraction Chair

I tuned in to a few of the talks from the design track as well. Denise Jacobs gave a terrific talk on unlocking creativity. According to Denise, one of the central problems that prevents creativity is distractions. Certainly rings true for me. She had a whole bunch of suggestions (e.g. use the pomodoro technique, use an app like Anti Social to block distracting websites, meditate, use powerful body language to restore energy and confidence) that I’d heard before (but still good to be reminded because I wasn’t necessarily practising them!) as well as one I hadn’t: the distraction chair.

The idea is that when you want to do something distract-y, you go and sit in another chair so that your work space doesn’t get polluted with cat videos and articles from The Onion. I’m definitely going to try this!

Learning #10: Accessibility can be Relatively Easy to Implement

One of my cognitive biases is to assume that everyone uses computers the same way as me, so it was good to be reminded that this is rubbish. Numerous speakers spoke about how we can’t assume that everyone has a lightning fast Macbook Pro with a fibre connection so we should design for limited or fully offline conditions. (Patrick Hamann’s talk was apparently amazing. Definitely going to grab the video for this.)

Isabel Brison also gave an excellent talk about improving keyboard accessibility. Lots for me to learn here but I am inspired by Isabel’s demonstration that accessibility can be relatively easy to implement (if you know what you’re doing).

I also picked up a handy demo of an automated accessibility test from Chris Giffard. Keen to give this a go.

Learning #11: Flex-Box Fixes Everything

Vitaly Friedman, editor of Smashing Magazine gave an awesome talk on responsive web development. His stated goal was to avoid using Javascript by replacing it with dirty CSS hacks. Highlight was “if it doesn’t work, use flex-box. If that doesn’t work, use more flex-box”.

Summary

Overall, I really enjoyed Web Directions. Was great to hang out with the other attendees and speakers, fun going on the rides at Luna Park and a big relief to have made it through my talk despite the technical difficulties.

Big thankyou to John, Rosemary, Bronte, Fiona and the rest of the WD team for doing such a stellar job!

*There are lots of talks I didn’t get to (definitely in favour of single track for 2016) so I might write part two after I watch the videos for the other talks.


Read more from Jeremy on:

 For more on Learnosity visit:

 


This post was posted in , , , by on