Diversity in the Songkick technology team

Quote

Respect each other and celebrate diversity is one of Songkick’s core values. Groupthink can be the enemy of innovation, and there’s a ton of research12 that’s been done to look at group dynamics and what a diverse set of experiences can bring to the table. So as well as creating a welcoming and supportive environment for everyone to work in, it helps us to build better products, too.

The Pipeline Problem

You will have probably heard of this – for the uninitiated, this is a way to explain lack of diversity in the tech industry due to problems earlier in the “pipeline”, eg gender biases which manifest themselves in schools and affect study choices, which in turn affect the number of applicants for jobs at companies like ours. This is a hard and acknowledged problem and Songkick can’t solve it (unfortunately!), although there are things which we can do to both attract diverse candidates and try to eliminate potentially biased treatment once they’re in our hiring pipeline.

Outside of our immediate hiring needs we can also contribute to a healthy debate on the issues and promote technology as a career choice to all.

So let’s start with widening the pipeline…

However good our hiring process, this will make no difference if we don’t fix the top of the funnel. We can be honest about this – we don’t get many women candidates. There are some great organisations such as Women Who Code who have a strong presence in London. We have hosted WWC meetups in our office and are in talks to host more in the future, and have also advertised on their job board. We have a hiring presence at conferences such as Lead Developer that care about diversity and have strong Codes of Conduct. Women are of course not the only minority group in tech, so there’s more we can do here.

We don’t have a preferred list of companies or universities to hire from, and indeed not all of our tech team studied at university.

A note on advertising

When reaching out to candidates, language is important. We run our job posts through linting tools such as joblint and textio. You will never see Songkick hiring for a ninja or wizard. These measures are easy and quick to implement, there’s really no excuse for not doing it. Our job listings only list the essential experience and engineering concepts you need to do the job, rather than using a wishlist of “nice to have” skills.

We’ve got a more diverse set of candidates – now what?

Once we have made contact with candidates we have some extra safeguards in place to avoid bias where it is practical to do so. For example, the coding exercise will be anonymised by the hiring manager, redacting all personal information before forwarding on to someone else to mark. We maintain a flexible interview schedule to accommodate our candidates as best as possible.

We base the technical interview around scenarios similar to those you’d find day-to-day in your job at Songkick, rather than expecting you to recall an obscure section of an university computer science course or solve brain teasers34. We’re looking for good all-round problem-solving ability and a willingness to ask questions.

Not everyone has the same preferences when it comes to ways of working, so during interview we’ll look to see if we can accommodate these rather than insisting that new hires conform to our existing style.

Day-to-day support

As in everything we do, we follow the principle of Continuous Improvement. In our Tech Team Offsite we had an action point to make our social activities less alcohol-based, allowing more people to take part and feel welcome if drinking was not their thing. We also wanted to schedule more of these activities in working hours so those with more commitments during the evening were not excluded.

We keep diversity and respect part of the conversation at work. We are always looking at what other companies are doing to tackle these issues, and encourage our team to call out any behaviour which is not respectful.

As we grow, we are developing a clear set of progression routes to support different interests within the technology team, from managerial to pure technical.

There’s still work to be done..

So what more could we do? We have a hiring council to bring more ideas to the table. One task is trying to find more diverse advertising channels. While there are many organisations for under-represented groups in technology, not all of them have corresponding job boards.

Our awesome team has been pro-active in outreach, and we’ve had some success with random shout-outs on slack channels. We are also looking at developing internships in the technology team and supporting graduates from intensive web development courses (not only university).

I was hired from Silicon Milk Roundabout, and there was an element of chance to it. I knew who Songkick were but didn’t approach them because I didn’t know Ruby (which they had listed on their stand), but a proactive member of the team approached me and assured me this was ok, and here I am a year and a half later. We now no longer specify language requirements in our ads, and hopefully this has helped in attracting a more diverse set of candidates since I started.

I’m really proud to work in a team that values diversity, if you would like to be part of this, please get in touch.

References and further reading

1. How diversity makes us smarter by Katherine W. Phillips
2. Why diversity matters by McKinsey and Company
3. Why we don’t hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks by DHH
4. Interview with Laszlo Bock, senior vice president of people operations at Google, The New York Times

When to repeat yourself

As a developer one of the first concepts you will be introduced to is DRY (Don’t Repeat Yourself) – if logic is re-used around your codebase it often makes sense to bring it into a central place to be standardised and easily maintained.  Later on in your career you might learn the hard way that there is value to be had in duplication and redundancy for the right reasons.

At Songkick we spent some time learning the hard way, so now the value of centralising common logic versus promoting weak coupling is something we actively explore and re-evaluate in our architectural decisions.

Tracking an artist versus tracking an event – be DRY on concepts, not code!

On the face of it, the concept of tracking an artist might look similar to tracking an event. For this reason we originally leveraged the same table and used a polymorphic association.

Tracking an artist vs tracking an event

Tracking an artist vs tracking an event

Looking closer and actually these two things are conceptually quite different. Tracking an event implies attendance on a specific date, and has a concept of “interested in/might go”. There is no equivalent granularity for tracking an artist (though maybe there should be a “I would consider seeing them under the right circumstances” option, look out for that in the future!).

When we split out our domain into services some years later we had to run migrations on this table to split out our attendance data from our artist tracking data, and similarly, separating logic out is much harder than combining it. Code-wise, the complexity added to handle both tracking concepts as the use cases evolved outweighed any benefit of the early abstraction.

See further reading for advice on avoiding early “optimisations” (such as abstractions).

Duplication of client models – DRY not necessarily suitable when weak coupling is required

Our front ends implement their own client models when reading data from a service, rather than making use of a client library.

Fewer dependencies gives us ease of deployment

A client library that provided standard client models may well result in less code duplication but it creates a coupling between client and service. Upgrading the client library would require a new deployment of each frontend, even if only a single frontend benefitted from the change – with our approach, we can deploy our frontends without this dependency.

If you’ve read any of our other blog posts, you’ll know we don’t like restrictions (or directives) on when we deploy!

Easier to reason about

Each frontend uses only the resources it needs and we can track our data dependencies to a service endpoint easily without the client library abstraction sitting in the middle.

Duplication of components – DRY benefits can be negligible with fast rates of change

The shared "upcoming event" component;, used on venue, metro area and user pages

The shared “upcoming event” component, used on venue, metro area and user pages

The artist "upcoming event" component

The artist “upcoming event” component

We unashamedly copy code from one front-end html component to another, making each one self-contained and with no dependency on other components. Front-end components are changed and iterated on quickly, and we usually want changes to affect a single component on a page. Any shared components are mapped out by the designer and PM so we know they will change together – if requirements differ we create a new component.

Because we make our components as dumb and atomic as possible, copying is low-cost and low-risk, and we can avoid complicated branching logic.

Conclusion

Optimising for code re-use might not be the right approach – consider that use cases might change, unnecessary dependencies can be created and that at the line level, code can become unreadable with an overly DRY mindset.  Be DRY, but not too DRY.

Further reading

Developer happiness at Songkick

Back in November 2014 I was on a plane back from Vancouver where I’d left my job in the Visual Effects industry to return to my hometown, London, with the definite plan of trying something new and the vague idea of that thing being working in a startup. In the previous year to that I’d developed an interest in lean, agile and the practice of experimentation and iteration as a way to navigate and progress through an increasingly complex world. Also, I really just thought it would be more fun to work on new stuff in a smaller company that cared about process and developer satisfaction. And I was right.

Songkick takes developer happiness very seriously. All the things that frustrated me working in my old team are age-old problems that have frustrated most developers at some point. Thankfully there are lots of leaders, resources and movements in this area that have sought to address this and at Songkick we are always looking to improve things to make working as fun and pain-free as possible.

I’m going to give you a run-down of some of the things that have increased my developer happiness – this is not an exhaustive list!

The kick-off document – the canonical source of truth!

The standard “As a user.. I want to… So that…” user story that starts the kick-off really gives the motivation and the context of the feature we are trying to build. This document acts as a reference point throughout the development process. We map out the scope of the feature with the product manager and designer, and the tester gets involved to help get us thinking of possible bugs and risks early on in the process. Certain questions might be raised but not answered during the kick-off, so it’s updated throughout to reflect our learnings and any new decisions that have been made. Once we are kicked-off we can dive in and start building, even if there are still some unanswered questions.

It’s a very simple idea but you might be surprised how many companies don’t do this. In my previous jobs this had consisted of some scribbling down in a notebook a vague idea of what a user wanted, a degree of strategising as to how that might be achieved and then one long-running feature branch later, deploying to production test-free and hoping there was no comeback (there invariably was – most likely a bug, or a disagreement on what it was supposed to do in the first place).

Kick-offs ensure that we build the right thing, no more and no less.

Test modelling

For non-trivial features we will also schedule a test modelling session using mind-maps with the tester to think of all the possible failure scenarios and work out a test strategy. Some of these things will be common to all features of this type, others will require specific business or technical knowledge. For internal tools we invite members of the relevant operational team to get that extra context. Mind-mapping really takes you out of the low-level detail of the implementation and makes you think about the real-world impact of the feature you’re writing, and usefully it forces you to think about all the uncomfortable things that could go wrong ahead of time.

Written test coverage

We write tests at various levels of abstraction so that we can avoid bugs and articulate our business logic. This ensures we can spend the vast majority of our time developing features and not fixing bugs.

Pairing

We use pair programming as a way of collaborating on features, knowledge sharing and of course onboarding new developers. The benefits and drawbacks of pairing are well documented, but in short it acts as a real-time code review and focussing-aid whilst making you tired quite quickly! We don’t pair on everything – it’s good to vary between this and some deep-thinking solo programming time.

Dean and me, clearly having fun.

Dean and me, clearly having fun.

Fast iterations and continuous deployment

Our continuous deployment pipeline means it’s a one-step process (and a matter of minutes) to deploy a change to production. Thanks to the test coverage we build as part of a feature (and previous coverage that act as regression tests), it’s also pretty safe – no sign-off required. It’s great to see your code out in the wild as soon as it’s built and to be able to act on feedback quickly. It also means you don’t lose context in the meantime.

Getting involved

Developers at Songkick are fully involved in shaping not only our products but our processes and values. We have councils for among other things, security, hiring strategy and API design that anyone can join, and our tech values are workshopped by the whole team. You will often find us at conferences, attending/organising meetups and writing blog posts such as this one.