Unruly is always on the hunt for programmatic superstars and talented software developers to add to our growing team – does that sound like you? If it does, but you’re not too familiar with what we do, fear not!
To give you a little insight into the day-to-day goings-on at Unruly, we sat down with one of our software developers, Sarah Young, to talk about how she got into the field, her life before Unruly and just exactly what her work entails.
If you like what you read, please have a look at our Unruly’s open roles here.
A: Hi Sarah, first of all, could you introduce yourself and tell us a little bit about what you were doing before Unruly?
S: Hi! I’m Sarah Young, and I’ve worked in our product development team for a little over a year.
Before coming to Unruly, I worked for a software consultancy as a developer. Before becoming a software developer, I was a historian, studying gender roles in education and the field of computer science. I got into software development after attending a software developer bootcamp called Makers Academy.
A: It sounds like you went on quite a journey to get where you are today. Can you tell me a little bit about your transition from having an academic interest in computer science to a practical one?
S: I initially became interested in why there were so few women in tech, as a historian, and how that related to constructions of masculinity. But, ultimately, I decided I wanted to have a more collaborative professional life – a historian’s job can get a bit lonely! I knew I really liked working with people and I liked talking problems out. So after working in communications for a while, I started putting together a PHD proposal in anthropology and organisational culture around why there were so few women in STEM.
Through general reading, I began to reflect on my life and the fact I loved problem-solving, but had never thought of becoming a developer. I’d internalised the message we have in society that women aren’t technical, or they can’t be developers and realised all the research shows those messages are completely untrue.
I thought, ‘OK, well, I like problem-solving – let me see if I can do this’, and I happened to find Makers Academy. I quickly found I really enjoyed software development, coding and the collaborative element – that was what really attracted me.
A: Unruly is known for its XP development culture and practices, so we see the value of collaboration first-hand. Was it your desire to work collaboratively that drew you to XP and pair programming to begin with? How did you begin to learn about XP?
S: It was actually from Makers Academy. Some of the founders and founding teachers had connections to the XP community, and so they embedded it into their core curriculum and it became how I learned to code.
We paired on everything; we did a lot of coding processes around XP, and I thought ‘this is incredible’, ‘this is what I want to do’, so I knew that once I graduated from MA that XP or a company that did XP would be my ultimate goal.
A: Can you talk a bit about how you found out about Unruly?
S: I was checking out Silicon Milk Roundabout and met someone who worked for Unruly there – and he said, ‘we’re an XP team’, and typically when someone says this I wonder if they really walk the walk – do they really pair on all production code? Do they really do trunk-based development? Do they deploy multiple times an hour? But he said they did, which struck me as unusual based on my experience in the London tech scene.
A big part of what attracted me to Unruly was that everyone was so friendly. During the practical stages of the interview I really started to connect with the people I was talking to and appreciated how everyone was on the same page when it came to problem solving – in terms of communication, empathy, curiosity, and taking an iterative approach.
A: And do you feel like you got what you signed up for at Unruly? That the business did ‘walk the walk’ and not just ‘talk the talk’?
S: It felt like there was a shared sense of cultural appreciation about extreme programming, not just in the product teams, but in the wider business. That was another thing I found impressive – other elements of the business had bought into a lot of the processes, values and practices of XP. There was a shared vocabulary within the business around iterative work – lean, small steps, an appreciation for testing, a respect for when developers say, “we need to pause the story work because there is some pretty critical refactoring we have to do first”.
That mutual respect was fascinating.
A: Tell us about your day-to-day?
S: It starts with our morning stand-up, and one of the cool things about Unruly is that it’s meaningful. When I’m at stand-up here, I’m invested in what my team did yesterday and it gives me insight into what I want to do today.
Then we allocate work fairly. We ask, “what are you interested in doing? What are your commitments for the day? How long have you been working on this particular story?”, and then we assign ourselves work and set up pairs. On a given day, I could join the support team to do bug fixing, I could use my gold card to write a blog, build my own projects, learn a new language.
It feels like I have agency in the kind of work I do, and it also gives me opportunities within my role to develop myself and control over my career trajectory.
A: What kind of challenges do the developers at Unruly face?
For product teams in ad tech, the primary challenges are around refinement and refactoring. How do we make our existing processes work better for the problems we face in such a fast-moving industry? How do we make sure the prioritisation process we have incorporates a long-term strategy? There are challenges around that, and also around handling legacy codebases that aren’t moving as fast as the market is moving. Those are real challenges that have a day-to-day impact on the team.
A great counterbalance to that is the way the development community at Unruly addresses these challenges, choosing to see them as opportunities for learning and growth. I like that self-awareness because it addresses the day-to-day frustrations that you face as a developer.