Nor(DEV):Con 2020 Review

Nor(DEV):Con is a developer conference in Norwich. An hour on the train, but further from London, there was a local, community feel to this event. There was a wider mix of technical and non-technical talks than we expected. This was a deliberate choice to focus on the human side of software development, and it matched the needs of the smaller size city. There were a number of talks geared toward non-technical founders and running a small business, which I hear suited them well.

Humaning

All the keynotes opening and closing both days were focused on developer experience and team health. Gail Ollis used the term humaning in her talk, reminding us that simple things like asking someone how their day is or checking their preferred pronouns may feel like friction in the moment, but are vital for the cohesion of an ongoing working relationship.

Communication around change

Karen Poulter opened her talk by sharing her life story. From our darkest points, it’s impossible to see our greatest potentials. Talking to us today from a Head of IT role, she recounted the unexpected turn in her life as a university dropout and a single mother in her early twenties. Raising her son gave her an immense sense of satisfaction and purpose. While it was not ruinous to her career development, it destroyed the image she had of her future she had as a teenager.

When change happens it can be a highly emotional and disruptive event. And when it happens in a business context, it can be hard to see why we should change when the we’re not in direct contact with the decision-makers, or have a differing perspective. Carrying a team or an organisation through large-scale change requires buy-in from all involved. And that requires understanding.

A risk of Agile approaches is short-termism, with the horizon of focus being a short week or month. For longer projects this can make the talk seem Sisyphean, and having no end in sight can be demotivating. However, having a connection to why these tasks are happening, and broader goals can help. Moreover, understanding why the project is happening means that making the right decision in the moment is easier and will be better aligned with the project as a whole.

Feeling free to experiment

For those in the know, kombucha is referred to as booch. Talking about her home-brew hobby, Jennifer Wadella use the booch community to talk about experimentation. For as little as £30-50 worth of materials you can get yourself a starter kit and have the resources to do a whole gamut of experiments.

So, why are we afraid to try? What stops us from starting?

She saw a lot of question on reddit asking “if I do X, will it work?” Her response was “I don’t know, why don’t you try?” The environments we work in are really low risk. All that might happen is you get a bad batch of booch. Really, the biggest risk is building up too much pressure and spraying booch across the room… and your cat.

Tech isn’t so different from this hobby. Our material costs are low. All that’s at risk is a little time. The downsides are low, but the potential upsides are why we’re interested in the first-place. First we need a culture where we can feel safe to have an experiment fail, and then we need to try.

Charli Vince’s talk was on imposter syndrome and summed it up this way: Shift your thinking from “you should” to “I can start”. As an illustrator she was seeing gorgeous art books on Instagram and feeling inhibited from starting her own. Then she realised what she was after was a sketch book, not an art book; the audience for the book was herself, not the public. Some ideas need to start small before they can be made public. But also talk to the communities for the work you’re trying to do. You’ll find that everyone goes through these struggles in some of what they do.

The key is lowering the perceived risk. Karen Poulter also mentioned that while every project has the potential to be a growth opportunity, but not every task we do can be. A large part of what we’re doing needs to be familiar for us to be comfortable in our work. And then having some work that’s a stretch, challenging, or new is where the growth happens.

The story of the code

Dom Davis had a talk of with this title. We work in code everyday, and the code slowly builds up a representation of what we know, and what can be done within our system. But Dom challenged us as to whether code can really be self-documenting. Especially when it’s really a working draft for the system we want to build.

There is a lot of context that isn’t in what’s executed. In the code-base there’s the naming of things, structure, doc comments, inline comments and git commit messages. Within your team and workflow there’s feature requests and bug reports at the beginning, with pull-requests and code reviews at the end. Each one of these pieces tells a fragment of the story of the code.

As well as small commits to detail your thinking as you go, Dom recommends detailed code reviews that touch on many of these points:

  • With a fresh pair of eyes, go back to the to the initial request. Does this have enough detail in know whether the feature is complete or not?
  • Look at the documentation for the API alongside the code. Is there any drift that needs to be addressed?
  • Look at the tests. Are they reflecting what’s described in the documentation?

Gail also touched on the story of the code. There’s an old acronym YAGNI; You Ain’t Gonna Need It. It’s a reminder to keep your change small. If it needs extending, that work can be done in the future. What’s much harder is working out whether and when you can remove a piece of code.

Theory of Constraints

Chris O’Dell works at Monzo as part of the developer experience team, and talked us through their process for improving their system. They run internal micro-surveys, asking three questions and repeating it month after month. The feedback from these surveys are used to inform how they improve the internal tooling. They ask:

  • How satisfied are you?
  • What one thing would you change?
  • Why?

What they do with the results follows the Theory of Constraints, as described in The Goal and The Phoenix Project. The original phrasing of the steps is a bit weird. Chris rephrased them as:

  1. Find the weakest link
  2. Use it to the maximum
  3. Make everything else wait
  4. Once exploited, pay to expand or alleviate
  5. Find a new constraint!

The Theory of Constraints is also a big influence on the Accelerate book about using DevOps for creating high performance teams. In Accelerate, the authors find that high performing teams:

  • Have short lead times on features
  • Have can release multiple times a day
  • Can roll-back with minimal down-time
  • Have a low defect rate of releases

In short, their goal was high stability and high throughput.

Putting these pieces together, the team used the survey results to drive their focus. Their surveys told them that the wider dev team was having issues with their staging setup. Having 1000 micro-services, a local development setup isn’t feasible, so they rely on a shared staging setup to test whether their changes integrate well. With a bunch of devs using this shared resource at once, it’s not too surprising that there were some issues. It was hard to tell whether issues on staging were with their code or with whatever else was being tested at the same time. I can relate to this one over the past couple of weeks.

Unfortunately, my notes don’t have the exact changes they made. My guess it was around making it easier for people to use staging for a shorter amount of time and keeping it in a good state. A side note was made that by having a robust rollback process means getting things live without paranoia level of testing is fine. Risk is mitigated by shrinking the impact.

The alleviation of the constraint was shown in the changes in the responses given by the developers. They no longer list staging as the one thing they would change.

New Tech

Katja Mordaunt made a bold case for using Elm over React. Their design has been influential on one another. And the code is simple enough that she found it possible to show it to non-technical clients. create-elm-app loads far fewer dependencies than its React equivalent, and being a compiled functional language gives far greater assertions of correctness than anything in the Javascript, or even Typescript, ecosystem. elm-ui was touched on, which gives type-safe CSS. Mind blown!

There were a few talks on WebAssembly, which bypasses Javascript entirely, and using a compiled language for reactive front-end development. Blazor looks like it does the trick, but I’m unlikely to look into the C# project anytime soon. I was much more interested in Q 🦄’s talk on using Rust for the front-end. Not only does it compile much smaller (since it doesn’t need the runtime components), the talk went into detail on the amount of scaffolding needed. WASM is now supported on all the major browsers, but the tooling isn’t there yet. WASM doesn’t natively support the DOM yet, so there is still some need to pass actions to Javascript there. For that side of things you can wire things together, but it’s not seamless support. However, as Q pointed out, if you want to use a cryptography package or similar, with the performance of native code (and without someone modifying it at runtime) WASM is looks like a contender for those specialist tasks as of now.

AWS Step Functions are a wrapper around Lambdas and other actions. They provide a UI for wiring up your functionality in a pipeline. This could be useful for composing different tasks out of common Lambdas, and getting good visual feedback on the execution path between them. But you need to be deep in Lambda-land before this is really useful, but could be a good layer for liaising between developers and technical people in other fields. Moving our ETL pipeline for the data warehouse to somewhere that Data can own or observe it is the only use case I can think of right now.

Dom also did a talk on concurrency in Golang. Goroutines and Channels are so much nicer than p_threads ever were.

Other Quick Notes

  • Know how to submit a GDPR breach to the ICO before you need to! Submitting small breaches builds confidence if you’re audited for a big one. Remember, even if your business is being a data controller, you’re a data owner for your employees.
  • Find out about the speakers and talks here
  • IYJI, one of the sponsors, have collected some two minute interviews with some of the speakers