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

Cinco de Mayo

“Who accidentally comes to Orlando on Cinco de Mayo?” the guy at the motel asked us. Except more politely.

We did.

All we wanted was to get catch our flight in the morning. Not party. S didn’t even want to eat. But I voted with my stomach, and this time common sense was on my side.

The main street was crowded, but head five minutes in any direction and it was quiet again. We asked for directions, but didn’t know where we were going. What did we even want to eat?

At least we could get around on foot. Six hours of jetlag to go to a wedding on an endless road called Gainesville. At least here we had sidewalks, and didn’t have to deal with six lanes of traffic.

Somehow we decided on sushi.

It was pretty good, and the sake woke us up a little. But not enough for Cinco de Mayo.

Flight in the morning, and we weren’t going to rest at the other end, so best to rest up now.

It didn’t work, but at least we tried.

Two channels, two mics and a rock band. What do I do?

You’ve got some new songs you want to share with the world. Maybe it’s just some friends for some feedback or to send around to get some gigs. You look around your rehearsal space. Drums, check. Guitar, bass, check. Recording equipment? All you’ve got is basic 2-in/2-out soundcard and a mic or two, maybe a mixer. No engineer other than the space between your ears? Ok, we can work with this.

Step zero is to get the sound you want in the room. The song should be tight, ready to be recorded. Your kit should be in tune, sounding the way you want. Any creative decisions that need to made have to be made now, almost nothing can be done in post now. Many of the great tracks from the 60s and before were limited to four tracks and what comes through is the quality of the songwriting and the performance. Yes, with some tracks there may be a lot more going on, but if things are sounding good when you start simple you can scale up from there. You can use a DAW or something simple like Audacity.

First up, record an instrumental

You know I said four tracks, this is why; vocals are almost always recorded after. I’ll talk about this below.

Using the mics you have it’s all a matter of positioning them and your kit so that the sound on the recording is balanced. If you’ve got a mixer, use that. If all you have is two mics set them up next to each other angled 90 degrees apart, pointing at the edges of the drum kit, and turn things up or down in the room so they fit with the drums.

Once you’ve got the room sounding good hit record. Listen back and don’t move on until you’ve got a take you’re happy with from start to finish.

Then, overdub vocals

This is where your virtual four track comes in. You get no bleed from the instrumentation and you don’t have to worry about monitoring nearly as much when you don’t have to compete with the drummer. Again, I prefer getting a good take from start to finish, but you can punch in and out if you’re set up for it. You’ve got a fixed take for the backing track, so as long as you have the cues anything’s game.

Have you ever watched some old videos of people like James Brown performing live?
Or even some of the more modern singers on the top of the game? Did you may notice that they move around the mic a lot? These guys know how to make a belt or a whisper sound a similar volume once it’s picked up by the microphone. This is is called working the mic and it’s a skill that doesn’t come naturally and I’ve not mastered yet. For the rest of us there is compression, or riding the volume fader. The target is to have the quietest part of the performance understandable without the loudest parts sticking out. Here I suggest getting the best performance and tweaking in post.

Once you’ve got your take, set the relative volume between the band and the vocals, maybe add some reverb (but less than you think) and hit print. If you’re tight then this is a quick and simple way to get your music out there.

What Does it Mean to “Trust your Ears”?

We’re all just trying to get the best mix we can, but sometimes it can be hard to tell whether we’re making things better or worse. Or even more disheartening; making a change one day and then playing at a friend’s or client’s and it sounding nothing like you expected.

There are as many ways to approach a mix as there are mixers, but once it’s bounced it doesn’t matter if you used the analog modelling plug-in or the modern, transparent one. As long as it serves the song and sound better for it, who cares? Since every song is different advice can only be so specific, we often fall back on the maxim “trust you ears”.

But how can we trust our ears if they tell us one thing one day, and something different the next? The first step might be the simplest; tame your listening volume.

Not all sounds are created equal

Studies have shown that the ear is non-linear in it’s response. This means that a mid heavy sound will appear louder than a signal of equal power that is mostly lows or highs. More than that, the difference in perceived volume will change based on how loud the signal itself is. What does this mean for mixing? Good question. First, let me introduce you to Fletcher and Munson.

These two guys did a series of experiments where the participants were played two pure tones; a 1kHz test signal and one at another frequency. The subject then changed the volume of the second signal until they perceived it was the same volume. For some frequencies the signal needed a mich higher absolute volume.

What they found has been condensed into what we call Equal Loudness Contours, the most well known being the Fletcher-Munson Curve. It describes how my ears behave, how your ears behave and how your listener’s ears will behave. Armed with this knowledge we can predict the effects of our listening volume and take steps to avoid problems down the line.

Fletcher-Munson Graph

Sorry if you’ve seen this diagram before, but there’s useful information in this graph. Along the bottom we’ve got the frequency, and along the side we’ve got the power. The lines show the actual output needed to sound to feel like it’s the same volume as the 1kHz test tone. The further from the bottom the louder the test sound needs to be.

Simply put, we suck at hearing low frequencies and anything above 5kHz is a bit screwy too. And as the volume gets louder, looking at the higher up lines, something else happens. At higher volumes the curve changes shape and becomes flatter. Meaning that turning up the volume in the mids will have a fairly regular, predictable effect, but turning up the bass… The bass will still sound quiet at higher volumes and then suddenly get a lot louder quickly.

What does this mean for my mix?

The good news is that this is a shared response between us all. We can reverse engineer this graph into a good rule of thumb:

Good sounding mixes mixed at low volumes will sound good at high volumes, but with a bit more bass. Good sounding mixes mixed at high volume may sound thin and lacking bass at low volumes. The fix is simple; do 90% of your mixing at low volumes, only going loud to double check, but not to fine tune. A good volume I’ve heard suggested is the volume you’d have background music; loud enough to hear, but quiet enough to talk over without raising your voice

You can also keep this in mind when playing with individual effects. Any time an effect changes the volume of the source A/B the effect at the same perceived level as the input and make your changes before setting the output level. For example, listen to how your compressor sounds before taking up that headroom you just created. Don’t rely on your meters for this.

If you keep your volumes low and consistent the next time you reach for the controls you’ll be one step closer to hearing just the song and not your ears. And as an added bonus your ears will fatigue less quickly, meaning you can mix longer at a stretch.

I’ve had mixes suffer because of this in the past myself. A band mate once complained that my bass was lacking when he was checking mixes on his headphones. He suggested that it was my speakers bass response, and I think he was half right. Looking back, I may just have been monitoring too hot and turned down the bass when I should have turned down the whole mix.

Don’t forget to listen to other material at these volumes too, to learn what they sound like in the same environment you’re mixing in. I’ve wilfully neglected acoustic treatment here because the same rule applies if you’re using headphones. No listening environment is perfect, but you’re using the same ears in every situation.

Shrinking Plug-in Headers in Logic Pro X

I’ve been doing some producing on my laptop recently and here’s a useful tip I’ve found for saving space on those smaller screens. When you open a plug-in window in Logic Pro it wraps the GUI itself in a black window with some extra options on.

You could always enlarge a plug-in window (although I’m not sure why you would want to), but since Logic Pro X you can also shrink them. On the top right there’s drop-down list of sizes you can choose from. But did you know you can also hide the header itself?

With Header

To do this just click the black-on-black button. This will shrink the plug-in’s header bar. You can find the top of the header and click the boarder itself, but I find this temperamental. Pixels saved! The only thing I find myself missing from this view is the power button for A/Bing plugins.

No Header

Bouncing Aux tracks in Logic Pro

Say you’ve got a few tracks grouped and bussed and you want to take a bounce to create a stem. The bounce in place feature is useful, but works track by track, and if freezing isn’t what you’re after. What if we want to bounce the whole drum group? How can we take the processed audio, effects and all, and bounce that to a stem?

Logic’s audio tracks hold the answer. You can set an audio tracks input to be any bus. By sending the tracks or groups to an unused bus we can capture the output by simply recording the output. Step by step:

1: Select the track or tracks to bounce

2: If the tracks are not already bussed together, pick an unused bus. Either change the outputs to the bus or add a send to the bus, setting it to line level.

Send to Bus

3: Create a new audio track. Change the input to your bus and record the section. The effects chain on the chosen bus will be skipped.

And all that’s left is to clean up your input tracks, if you want. Usually, the Bounce in Place is an easier solution (^b), but for those times where your setup up is a bit more complicated routing to an audio track may be just what you need.

A Project Begins – An Arduino Unboxing

There’s a Maker‘s Space at the DAI in Heidelberg that’s just started up. I’ve been to the DAI a couple times. It has an awesome collection of (English language) books and I want to read them all. It’s an inspiring place by itself and I came away from the maker’s meetup wanting to do more.

The group is new there. They’ve invested in a 3D printer and some 3D pens, and the gaggle of people had a buzz about them too. After looking some 3D dresses and some people messing about with Arduinos the host and I got chatting. They’re planning a launch at the end of April and were looking for people to demonstrate. Without a concrete plan of what to do I volunteered.

View this post on Instagram

Arduino Starter Kit unboxing

A post shared by Mike Ramnarine (@soundornoise) on

So I bought the official Arduino Starter Kit. And it comes in a really pretty box. I want to make something that makes some noise, but I’ll need to go through the Hello World stage and I’ll want to mess about with other things too. The project book it comes with looks really well laid out and the components are just what I need to start with.

I’ve set myself up GitHub Repo and will be keeping you updated here.

View this post on Instagram

Arduino Starter Kit unboxing

A post shared by Mike Ramnarine (@soundornoise) on

 

View this post on Instagram

Arduino Starter Kit unboxing

A post shared by Mike Ramnarine (@soundornoise) on

 

View this post on Instagram

Arduino Starter Kit unboxing

A post shared by Mike Ramnarine (@soundornoise) on