RustFest Barcelona – Katharina Fey: The human cost of development


All right, sorry for that. I had it working immediately the last time
and now I was kind of confused why it caused problems. So thank you all for coming and thank you
for watching and to one particular person on the live stream right now. I hope you’ve had a good RustFest so far. I know I have. I really like the way that the talks were
split across two days because it gave me more time to think about them and to talk to people
about what I’ve heard. It was less crammed so a big thumbs up to
the organisers. I really like that. I have been given the privilege to close out
the talk track today and it also means that I’m the last hurdle before lunch so I will
try not to take up too much of your time. I want to take this opportunity to talk about
something that’s pretty important to me and I feel that it should be more important to
all of us as a community. So for those of you who don’t know me, here
is a quick intro. My name is Katharina Fey, I have been involved
in the Rust community since 2017. I started writing Rust because I wanted to
write a DNS server. Please don’t ask. I’m currently a freelancer and you can hire
me but please don’t do it all at once. I write a lot of free software and I am also
one of those people who says free software instead of open source. Also I like shaving yaks, and my current yak
is emails. I will be giving a lightning talk later about
this by the way. I travel a lot and I write some software and
I have a pet shark called Nibble which is the smaller sibling to a larger shark called
Bite. [Laughter]
I think this tweet sums up what I do pretty well. I don’t really like doing questions on stage,
it’s kind of awkward for me, but you can send me an email or for the five other people using
XMPP it’s the same thing as my email. I’m on Twitter, also known as the hell site,
or just come talk to me. I don’t usually bite. So this talk comes with a few disclaimers. The first disclaimer, and this was already
mentioned, is that this is not a technical talk. I will try to visualise some problems in the
industry and none of that really requires any code. Just more abstract things. There’s no code on the actual slides, well,
except for one. I recently used async-std and it was really
awesome and I just wanted to say that I really love it. Disclaimer number two is that this talk is
not based on personal experience. Well, okay, it’s not only based on personal
experience. All of these issues can and do affect us all
and I think it is important that we talk about them. Disclaimer number three is that my slides
are kind of boring. I wrote this talk as a sort of essay and I
will – mostly the slides are a way for me to get through my speaker notes. I think it is more important to listen to
what I say and also the script is in the speaker notes and I will upload the slides. The slides are mostly there so that you have
something to look at that’s not my face. The talk also comes with a content warning
for anxiety, burnout and depression and if you are one of those people who don’t like
content warnings, I invite you to grow up, please. So there’s a few things that I want to talk
about and at first glance you might think that these issues aren’t really connected,
but I feel that they are and I hope that over the course of this talk you will come to agree
with me that there’s a larger perspective to consider and maybe together we can start
working towards a better world. I don’t claim to have any answers but I do
want to start a discussion. But it will be okay. It’s fine. So first of all I want to talk about technical
debt. What exactly is technical debt? Well, as Rust developers you probably don’t
really know what that is. It’s a term that only recently – more recently
came up as large companies have started dealing with their technical debt. Unfortunately, this means that a lot of the
discussion and talks about it happen as to how to get rid of it, not why it is happening. Technical debt is just like any other debt
but for the tech stack of a company. Generally when developing systems sometimes
engineers take shortcuts or make bad choices. Stuff happens and then, poof, there’s legacy
code. Maybe someone was fired who understood it
all and then no one else can, or maybe you had to push yourself to make bad decisions
for release or something, so either over time or sometimes with bad decisions technical
debt is created. Now, I want to run through a small example
here and again this will have no code but I think it will sort of demonstrate how this
happens and I think this will feel pretty familiar. So take Foo Ltd, a fictitious company. They ship their first product that does serverless
cloud computing on the blockchain and they are very proud. Unfortunately, to push out their product they
had to do some – write some hacks. Some of the code isn’t as cool as they would
want it to be. It kind of looks weird and pointy. Some of the engineers want to go back and
re-write some of it to be nicer and have a nicer architecture. The next funding milestone is due and they
also have a large client, Oogle, who would like to use their tech, so instead they hack
around it and they ship this. They apply some duck tape and, you know, get
more money and do more cool things but it can does mean that the investors are now happy,
it also means the work that should be done never gets done. What is happening here? Well, money from either investors or clients
is exchanged for technical debt. So when you start looking into why technical
debt happens, or if you generally look into the issue, most of the articles, most of the
discussion is how to deal with it and I guess that’s fair. A lot of companies have large technical debt
issues and it would be an obvious question how to get rid of it. There are some good resources out there, how
to do this, and I don’t really want to get into this right now. Some of it is just refactoring techniques,
throwing away code, all of these things. I feel it’s a space that’s pretty well covered
and I don’t think me sitting here or standing here and talking about it is going to add
anything. Needless to say, I feel that if your company
has technical debt there are resources out there to learn how to deal with them. In my opinion it is much more interesting
to ask the question why. Why is technical debt created? So I started researching this a few months
ago I think at this point and really there’s a few reasons but the most prevalent ones
that I could find were these four, so the Internet says: making sacrifices for a deadline,
which was the example we just saw earlier; bad decisions from engineers. You know, sometimes people make bad choices
and then it bites them in the arse. Systems getting old or talent going away,
someone just leaves the company and no one understands it, and bitrot which in this case
means a module that gets re-factored over and over and over again to do more and more
things to the point where it doesn’t really do anything well anymore and it’s not really
understandable. Now, I will grant you that there’s a lot of
reasons why technical debt happens, but none of them are technical. They are all social problems. People make bad decisions sometimes but it’s
in the framework of their company that these decisions become technical debt. Not letting your engineers go back and fix
their mistakes is how you create technical debt and honestly the same applies to making
sacrifices for a deadline. If you as a company, not an individual, have
to write some hacks to get your product out the door and then you don’t go back and let
the people who did those hacks go back and fix it, that’s creating technical debt but
it’s not the engineers’ fault. People don’t really work in a vacuum. It’s the people’s fault who did the time planning
and who didn’t allow for the people that – for the engineers who worked on this to sort of
build a working environment where they can do the things that they wanted. Companies make a lot of decisions all the
time and some of them are greedy, I guess, and then after a while of doing this over
and over again, they start to pay the price. So I want to run through another example with
Foo Ltd, and by the way I want to thank my friend Rebecca @HazelnutXYZ on Twitter who
made these in two hours’ notice and my design direction was: engineering fuck up. So for my last example, Foo Ltd is doing pretty
well, they have two clients, Oogl and Amadont. Unfortunately your product is a bit of a monolith
so there is a module in there that interacts with your cloud and it can’t really be removed. The most sensible way of dealing with this
would be to pull out something from your core and write a thing that enables plugins to
interact with your core but that sounds expensive so why not just copy and paste some code and
build this wonderful tech stack? So again, being put into the situation where
either you can do something right or do something fast, the fast way is the one that ends up
with an unmaintainable code base. I want to take a small step back here and
at least mention in part why I’m giving this talk. A few months ago I was at a conference that
I don’t want to name and I saw a talk there that I don’t want to identify and it handled
the subject of technical debt and how throwing away things can lead to nicer projects, instead
of just refactoring, throw away your code, and for the most part I really liked this
talk right up to the point where it fell kind of flat. See, it’s always possible to add new things
and when you are tasked with doing something – you can either do it in a maintainable way
or in a bad way. Depending on your situation, you will choose
one or the other but the question that this talk never dared to ask is: is there really
a need to add more things, are potential clients really that important that you sacrifice whatever
you are building to the pictures that I just showed you earlier? They look huge as graphics. They don’t look as cute as hundreds of thousands
of lines of C++. Don’t get me wrong here, I’m not saying that
writing features is bad or that we shouldn’t make stuff. What’s the point of being alive if you can’t
write bad code? [Laughter]
I simply take issue with the idea that an engineering department has to bend over backwards
because some management people promised some other management people a feature and the
people who then have to do the work don’t get a shot at either coming up with alternatives,
with more realistic deadlines, or finding a nicer way of implementing it. Even if you look – if you leave this aside
and you only look at the effects of technical debt, pretty much all the time the focus is
on the company and I did this in my own talk until this very moment. I focused on how does technical debt impact
Foo Ltd and not the people working at Foo Ltd? Most of the articles that you will find on
the Internet does this, or do this pretty much always, and the talk that I mentioned
earlier did this all the way through to the end. Yes, even some research papers do this. Productivity is the focus. So what kind of effects can any of this have
on people who actually have to work with these systems, and are humans with feelings and
actual limits? People talk about burnout very often the same
way that they talk about technical debt. This happens at conference talks and in online
articles and, yes, also some research papers. A lot of the stuff that you will find is stuff
like this. Articles that go into detail how you personally
can prevent yourself from burning out. The issue of being overworked in your job
is being put on you to deal with. In a way, this reminds me of climate discourse. You personally are responsible for killing
the planet, not the system that you are forced to live in. I talked to quite a lot of people over the
last few months, when preparing for this talk, about their experiences with burnout, especially
in tech; how they tried to deal with it; what support they got from their companies or friends. Needless to say I have bunch or dirt on a
bunch of companies now, so that’s fun. More importantly, it’s a common theme, even
when people describe their own burnout, not to focus themselves in that conversation. There are people I kind of had to pry it out
of, what their experience had been and what they had gone through. At times it felt like a taboo thing to even
talk about, on a personal level anyway. Most were happy to talk about burnout industry-wide
and oh yes, the tech industry has a real issue, but I’m personally never affected. You know? Productivity, again it’s a term that’s most
often used and it frames the entire conversation about burnout, something that happens “to”
individuals with regards to a company and the loss of labour that it causes. This is very common. The only real sources of this that take burnout
seriously I found were medical papers and studying the negative effects that burnout
can have on people with excruciating detail and charts and numbers of really just things
that happen to people. There’s no slide here because it’s depressing. So instead of doing any of that, I want to
be a bit more personal for a bit. Part of changing the conversation means giving
people the space to share their experience and so I want to be at least one person on
a stage that takes the issue seriously. Burnout is losing yourself to a job that you
hate doing. Whatever you do, it’s never enough, but you
also feel like you want to do more. You are not being compensated, whatever that
might mean, but you are too greedy if you ask for more money and you are letting down
your colleagues if you ask for vacation days. Personally I also notice my creativity taking
a dive whenever I burn out. I usually make music or write stories, and
yes, it has happened a few times before. Burnout isn’t something you even entirely
realise is happening to you. Sometimes it makes people anxious, sometimes
it means people cry themselves to sleep. For others, it means focusing so much on what
they do, it becomes their whole identity. They think of nothing else. They speak of nothing else. Literally, their job becomes their life. How many people like that do you know? The phrase “oh no, I’m just stressed but not
like … burnt out”, is pretty common, and I guess for some it would be admitting a kind
of failure? I know it was for me. Why am I talking about this at RustFest? I can already hear someone complain about
how this is way too political, you came here for the Rust. First of all, okay, everything is political,
whether you like it or not. But secondly, and I think more importantly,
Rust is a young language and the people who write Rust are largely people who do it because
they think it’s fun. We are a community that’s built around hobbyists. The previous talk mentioned this, the compiler
is largely being developed by volunteers. Some people are even learning Rust as their
first programming language and maybe a Rust development job will be their first gig in
tech. I think we owe it to those people, and to
ourselves, that we give these issues a stage and talk about them because Rust projects
often don’t have technical debt yet, but the management structures that create it still
exist and burnout can just as well happen on a Rust project as it does on any other
project. Burnout is something that affects us all,
and I feel that as a community we need to talk about it because it’s important. These issues aren’t going away. So I submitted this talk because I just generally
saw how conversations about burnout went down most of the time but it’s the larger context
in which this happens which I find concerning. The tech industry has a burnout problem, I
do have some charts in a second, and it feels like most people in it are grasping at straws
as to why it’s happening or what we need to do to stop it. I will say that finding actual numbers, solid
numbers on how many people in the tech industry are burnt out is incredibly difficult. I could find numbers that were more representative
of the entire workforce, but I’m not sure how much you can actually extrapolate from
that. There’s a lot of numbers on – or there’s a
lot of data on studying the effects of burnout on people, so take – I guess this is like
a single source of they are fucked up but even if you apply a margin of error over half
is not a great number. Interestingly enough, from the same set of
data and the same sources and the same sort of methodology, this chart emerged. It doesn’t say in the picture but if you do
a reverse image search you will find the same article that linked the first one. It’s really interesting that rates of burnout
in the UK versus the US versus the rest of mainland Europe, it’s not something I would
have expected. I will say that. So what now? Say that you are a team lead at Foo Ltd and
you want to take this issue seriously, but you don’t know what to do. You go on the Internet, you find some ideas
and follow some popular discourse on what to do to help your colleagues or employees
with their struggles. A lot of the discussion is about a 40-hour
work week. This seems to be largely an artefact of US
tech companies branding themselves as progressive for not having a 60-hour work week and explaining
how much free time you have in such a model. In Germany a 60-hour work week would be illegal
because there’s such a thing as labour law, yet there are startups in Berlin right now
that advertise their 40-hour work week as progressive and generous to workers. Another proposed mechanism is to make the
office more friendly, add a ping-pong table or a Nintendo 64 emulator, and noncommittal
statements like: why don’t we just try chilling it with the deadlines, or have you tried not
being in so many meetings? I feel that these conclusions are unsurprising
considering the lens through which the analysis of burnout is happening. Your focus or the focus of these techniques
is on the productivity of a company. Think of your KPIs, not the mental health
of your employees. Actual solutions to burnout would include
things like switching to a four-day work week or even putting someone on several months
of paid leave to recover, the same way that they would be allowed to recover if they had
a severe physical injury. So if we know that there’s good approaches
for aiding people recover from burnout, why aren’t these things that companies are proposing? Wouldn’t you as a stakeholder in Foo Ltd also
gain from keeping your workers healthy and productive? What we end up with, or what we end up getting
are these fake solutions that make sure that people’s recovery from burnout is always grounded
in the office environment. You are allowed to recover from burnout but
please think about work in the meantime. Solutions that have been shown to work, like
the ones that I just mentioned, but are expensive are often not considered. Also this screenshot is from a paper. There is a link in my speaker notes, please
read it. It’s amazing. There is a wider trend in our culture of seeking
solutions that make everybody happy, sometimes called a win-win. It frames our ability to facilitate change
as a quest to a solution that benefits those who need help as well as those who don’t. You are allowed to address A but I as a stakeholder
in Foo Ltd also need to benefit with B, is essentially how the conversation is framed. So discussions about burnout turn into conversations
about productivity. Discussions about technical debt turn into
conversations about productivity. This happens because the stakeholders of companies
have a vested interest in letting the conversation go down this route, but there’s a common thread
here. When the stakeholders of an organisation make
decisions, people will end up in situations where they burn out, regardless of how well
intentioned they thought to have been. By being disconnected from the reality their
conditions exist in, people will burn out. Analysis done through this framework is inevitably
lacking and will fail to describe why these things are happening and keep happening, even
though we know why. It’s a work week that’s way too long, deadlines
that get made by people who are too detached from both how much work something is as well
as not having to do that work. Changing requirements, technical debt that
already exists and keeps piling on, adding more stress to the people who need to work
with these systems every day, and these things will keep happening as long as we don’t fundamentally
change the way that we work and can relate to it. So what are the alternatives? What if the stakeholders of a company were
the people doing work? What if you remove management from the equation,
let workers take control of their work? When I say take control, I don’t mean require
little oversight, I mean something much more essential. You might think that you are being overpaid
in your cushy tech job but even your high five or six-figure salary is nothing in comparison
to what someone in upper management makes and they hold power over you and your life
that you will never have. When I say “take control over your work”,
I don’t mean you personally either. Get connected with your colleagues. Together you are stronger than you could ever
be alone. You might think that your company needs you,
but it’s also exploiting you, so fight back against that and honestly unions are a great
tool to achieve this. Working without bosses isn’t entirely easy
either. It requires organisational structures and
it requires everybody involved in a team or company to understand the relationships between
the work that is being done and how power dynamics factor into the decisions that get
made. When you work under a management, the power
dynamic is very explicit. Your boss has power over you. In a way removing management from the equation
means being better able to understand your role in group dynamics and how you relate
to the work that you want to do. Lastly, and this is I think maybe the most
important point that I want you all to take home, when we talk about burnout, can you
please stop mentioning productivity? How often did you – and actually think about
this – how often have you thought in these terms when you’ve thought about someone burning
out, if you thought about burnout being an issue in the tech industry, did you think
about it being a danger to the bottom line? And how often in recent times have you legitimately
thought that a win-win is something that actually exists, where you can help someone and then
you also get help, or however that is supposed to work. None of the issues that I talked about exist
in a vacuum and you will find that once you accept that we are dealing with a larger social
issue, that really only manifests in our little bubble of society in very particular ways,
the world will look very different to you as a result. Thank you very much, and I hope you enjoy
the workshops today. [Applause]

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *