Before he retired, my dad was an electrical and diagnostic engineer. In short, he dedicated most of his adult life to designing and building lasers and laser equipment – everything from laser-tag through to guidance systems for those massive drills that dig rail tunnels. After dad passed away, I stumbled across a box in my parent's garage containing prototypes and product specimens for many of the laser modules that he'd built throughout his career. That box now serves as a tangible legacy of a long and varied career.
Flash forward to a few months ago when I was chatting with a potential client. They asked me to show some of my past work, so I duly shared my screen and hopped over to the URL of a humanitarian campaign site that I was particularly proud of having worked on...
I often think about that box in the garage.
Let's get existential for a moment. permalink
This is not a new phenomenon. In my younger years I was keen to make a mark in the industry and would often find myself working to the point of exhaustion in order to meet unreasonable deadlines. What was I working on at the time? There's the kicker, I can't even remember. Whatever it was, I know that the site has probably been long since replaced. That is just how the web industry is.
But, what does it actually mean to work in an medium that is so temporary? How does it shape us? When your work can literally disappear at any given moment, how do you reason with the effort that went into producing it?
Personally, these are uneasy questions but, thankfully, I know that I'm not alone in feeling this. I recently found myself nodding along with Jason Lengstorf's video "Your job doesn't matter (and that's a good thing)" and, just this morning, I felt Eric W. Bailey's beautifully to-the-point Sandcastles in my bones.
Control structures. permalink
The more I think about the why, the more I believe my own sense of discomfort ultimately comes down to a lack of control in a job that is seemingly all about control.
As developers we spend a lot of our time trying to take nothing and give it the necessary structure and logic that turns it into something. Once we have the something, the job shifts gears. We start to monitor uptime, we handle traffic spikes, triage error logs, make tweaks to the UI and do everything we can to keep the project ticking along. We are in charge of managing and maintaining the systems necessary for the project's life-support. And yet, despite those efforts, there's no system that can stop a project from just running its course.
It's a truism that, from the point of launch, our work is no longer "ours". We have full control, until suddenly we have none. Eventually, someone will make the decision that the time has come. The server will be shut off, the domain will be left to expire and the website will be gone, save for a trail of broken links.
The industry has collectively come to call the closure of project, "sunsetting". In a world of blazing-fast bro-sy newness, it's an oddly melancholic bit of romanticism that seems to suggest that we knew the end was inevitable from the start. Regardless of any prior understanding, it can still feel uncomfortable that an entire body of work can just be ...gone.
Code conservation. permalink
So, if we know our projects will end, perhaps we can lessen any sense of existential unease by taking steps to preserve them. The question is, how can we do that?
Well, the most obvious solution seems to be case studies, which is perhaps why so many of our portfolios are screenshot memorials to that sweet-spot between launching the site and handing over the keys to the CMS. Screenshots and videos definitely go some way towards the job, but its little more than a tribute – you can't really get a feel for the work in the same way as a live site. Set Studio's recent site launch included a beautiful and novel solution to this – it contains embedded, responsive snapshots of their work preserved in time. I'm a huge fan of this approach but, as a freelancer, licensing and NDAs mean that it isn't always possible to do the same.
What about retaining local versions of projects? Licensing issues aside, anyone who has spent any time struggling to update and run an old project's NPM dependencies will know the answer. Hell, even recording our work to physical media isn't a solution as external storage can fail – the box of useless, peeling DVDRs that I found alongside my dad's lasers is a testament to that.
It's funny that, as developers, we often talk about "legacy code". For us though, the word "legacy" isn't used in terms of something to preserve the past. More often than not, "legacy code" is something to be refactored, replaced or removed altogether in the name of progress. Without necessarily realising it, we have unconsciously accepted the temporary nature of our work into the language of our industry.
This is all to say that, at the end of the day, perhaps it's the nature of digital things that they just aren't meant to last.
The ephemeral nature of (digital) things. permalink
It is the ephemeral nature of things that makes them wonderful - Yoshida Kenkō, 1283 – 1350
Up until now, you'd be forgiven for thinking that this post was a bit of a downer. But, honestly, I don't want to see any of this in that light.
Prior to joining the industry, I didn't formally study web development but rather social and cultural anthropology. The quote above is something I read in my university days which still sticks with me. Perhaps, rather than getting caught up in a bleak everything-ends sensibility, the steady destruction of our past work should be seen as a strength.
That humanitarian campaign I worked on was only destined to run for a short time and, because of that, the team pulled together to make sure that we got it right in the time we had. If the initial impact is great enough, the need for preservation is secondary. In many ways, a finite shelf-life is an opportunity to be better.
I want to get more comfortable with that idea, so I've been thinking of how to get there. Here's my plan going forward:
Wherever possible, use tried-and-tested tech. Stay as close to the platform as possible. Fewer moving parts means fewer chances to break and resiliance creates longevity. Look, I know that it's a massive cliché at this point, but there's a reason that Space Jam's website is still online.
Longevity shouldn't always be the goal and you need to be comfortable with letting go. Your work is ultimately not your own and today's shiny new tool is tomorrow's technical debt. Tools are rarely worth fighting for, but the thing you're building should be. If the work is only going to be around for a short while, try to make the most impact on the people who will use it. Focus on their experience over your developer experience.
Code like you think no-one's reading. Try not to get hung up on "good code" and burn yourself out on over-engineering the perfect, scaleable solution. That scaled-up future may not happen so solve the user's problem first, then iterate it to solve the code. (Remember the bowl).
Back in December I mentioned how I wanted to make more things "for the sheer hell of it". I realise now that this isn't just great for creativity, but it also helps with attachment. Make more things for fun. Prototype, build sites that are intentionally throwaway and play with your code. Things built for only yourself are no less important than the things built for others. Think of these projects as recycling – the project will live on in the new skills you use for your next bit of client work.
Lastly, if you do ever find yourself having to put in unreasonable hours to get a job done, make damn sure it's for a cause you'll care about and remember in fifteen years.
Will I stick to all of this? probably not. Will doing any of it have an effect? most definitely.
After more than 15 years, I don't see the industry suddenly shifting to a preservation mindset but that's fine. I want to focus on doing the best work I can right now. In the end I probably won't have a box of my work in the garage but, ultimately, I think I'll be OK with that.