Alex Warren

A recurring theme throughout my career has been developers asking the question “why don’t we get more time to fix technical debt?”

This was the inspiration behind a talk I gave a few times last year, called Why Not Fix Your Technical Debt?

I’ve turned some previous talks I’ve given into blog posts, and started doing the same with this. I wanted to add a bit more detail, including a nice case study of some technical debt I came across (and fixed!) during my time at Stack Overflow. Doing that made it far too big to be just one blog post, so I’ve created a whole website instead.

Presenting: Technical Debt - a guide for developers and product managers.

Check it out now at techdebtguide.com. If you find it useful, please pass it on to the developers and product managers in your life.

Many companies think they’re already set up for successful remote working. They have all the tools and technology in place. And yet, many people think working from home is simply not as effective as being in the office. Why is that? By shifting our mindset to make office work look like remote work – “Remote First” – we can help everybody to be more productive, whether they work at home full-time, at the office full-time, or a mixture of both.

In this talk, I’ll show how remote work increases productivity, improves hiring and retention, and can really help your diversity and inclusion efforts. We’ll look at both synchronous and asynchronous communication – when to use each, and how to use them successfully. Along the way we’ll look at plenty of examples from my time working full-time remote at Stack Overflow, and subsequently leading distributed teams across multiple countries.

We’ll also look at the personal challenges of working remote, and how to overcome them, and dispel some myths about what “collaboration” means.

Ultimately, this is all about setting teams up for success, wherever people choose to work.

This talk was given at Codemotion Milan on 25th October 2019.

What is technical debt and why is it important? When should we fix it, and when is it not worth fixing? When it comes to a choice between “fixing up old code” or “delivering new features”, it’s often “fixing up old code” which loses - how can we fight back against that?

Based on my experiences over the last 10 years, I’ll talk about empowering developers to improve code while still delivering value to the business, and how the business can understand the benefits of fixing technical debt. We’ll also look at when it might actually be better to leave the technical debt unfixed.

This talk was given at the Front End London meetup on 30th May 2019.

At Trainline we’ve partnered with Code First: Girls, an organisation aiming to teach 20,000 women to code by the end of 2020. We want to help them make sure that women will have the same opportunities as men when it comes to technology skills, by delivering their free Level 1 Beginners Course, as well as providing financial support.

Volunteering as one of the course coaches, myself and Eli Schütze Ramírez, have been taking a group of 18 women who are complete beginners through the process of building their first websites from scratch.

Over seven weeks, we’ve covered everything from the basics of how the internet works, through HTML and CSS, using Atom, GitHub and Bootstrap, all the way to JavaScript and jQuery.

The students, who had never done any programming before, all now have real websites live on the internet, built using the same real tools that programmers use every day.

Judging the end-of-course showcase, we were super impressed at all of the websites the students have developed. We saw eye-catching designs, responsive layouts, and even interactive elements. Everybody had come such a long way!

One of the strengths of the Code First: Girls approach is because it’s using real software, it shows the reality of life as a software developer. The challenges that the students faced when building their websites were similar to the kind of challenges that I and other programmers face daily. How to work effectively with other developers, understanding documentation and code on the internet, working out why sometimes things work on your own machine but not on the website, how to handle an upcoming deadline…

I always think the best way of learning programming is to throw yourself in and start building something, and Code First: Girls provides that, in a safe and supportive environment, without over-simplifying things. Everything the students learnt will be useful whether they want to build sites as a hobby or even develop it as a career.

We ran in-person sessions and provided support via Slack as students built their websites in their own time. That meant there was always someone they could turn to as problems came up.

I thoroughly enjoyed the experience and will definitely be signing up to teach another course. If you’re a developer and thinking of signing up to teach, you should. All the course materials are provided and they’re well written. You just need to talk through the slides and help out the students when they get stuck.

And if you’re interested in learning to code and identify as female/non-binary, you should give it a go and sign up. No prior knowledge is needed, we start from the absolute basics, you just need to have the interest and a little bit of time and we’ll teach you enough to build your very own first live website.

And that's a wrap! We've had 7 wonderful weeks teaching @CodeFirstGirls Intro to Web Development course at @thetrainline. Look at all these amazing new web developers 🤩🤩 👩‍💻👩‍💻👩‍💻 #cfg2020 #womenintech #webdev #londontech Thanks to @alexwarren @mikesheldon for also volunteering! pic.twitter.com/XnhxFIoMde

— Eli Schütze Ramírez (@elibelly) December 3, 2018

I saw a user story that looked like this:

As a back-end service, I want to send the correct data about the widgets to the front-end, so the front-end displays the correct widget information.

Wait, when did a back-end service ever want do to anything? Has it gained sentience?

Now, user stories are great. They help us to build the right thing, by thinking about the user of our application and what they are trying to do.

Writing things down is also great. Despite it sounding strange, I’m glad that we have the user story about the back-end service, because it’s much better than not having any spec about what the back-end service should be doing for this feature, or indeed forgetting that somebody needed to do some work at all on the back-end.

But did it really need to be a user story? Will we write better software by feeling empathy for the machine? Our instincts should say no, because the user - the real end-user of our application - doesn’t care what about back-end services are doing. They only care about what they see on the device in their hand.

The purpose of a user story is to help us step back from a problem - before jumping into technical details, let’s work out what the user really needs, and then we can build only what is necessary to get us there. After writing user stories, we might send them to developers or business analysts to spec out a feature, to get a more detailed idea of how it should work.

The problem here has come from mixing things up - instead of working out what the user’s problem is (the user needs to see the right thing in the app), we have dived straight into a solution (the back-end service needs to provide some data to the app), and then put that solution within a template “As [user], I want [something], because [some reason]”. But if we’re writing a technical spec, we don’t need to fit this template - it is perfectly OK to write “the back-end service needs to send some data to the front-end”, because we should already have written some user stories about the real user. Real user stories might look like:

As a user who has not opted into the new widget feature, I should not see any widgets.

As a user who has chosen to have bells on my widget, I should see a bell button on every widget that is displayed.

This is not the first time I have seen things crowbarred into user stories. At a previous job I worked for a small consulting firm, and we would often get requests like this:

Please update the Gizmo table so that all entries processed after 18th January have a DoodadIdentifier of 5.

Somebody had obviously got the Agile religion, and decided that all client requests now needed to be in the form of user stories. No longer would we just be doing what the client told us to do! We would get real insight into their problems, so we could propose the most effective solution for their needs!

Of course, all that really happened is that requests would now come in looking like this instead:

As the client, please update the Gizmo table so that all entries processed after 18th January have a DoodadIdentifier of 5, because I want you to do it.