3 Lessons from building a website with my boyfriend

Joe Rackham
4 min readMar 15, 2021

At the start of lockdown my boyfriend Blair asked me to help him build a website. He had one already on WordPress but wanted to make a new one from scratch so he had more control, and as an opportunity to learn some coding (he’s an Interior Designer). I’d built websites before and considered myself a good explainer (and a good boyfriend) so of course, I said yes.

The experience, however, had some bumps. Working remotely and with a non-techy person proven to be an unexpected challenge. Reflecting on the project now it’s (nearly) done I’ve distilled some lessons I can share.

1. Use the Right Tools

Before starting to work together we didn’t do much in the way of setup. For an example of how this went wrong look at the following terminal command:

git commit -m "First commit"

Simple enough right? Now imagine shouting it down a dodgy Zoom connection to someone who hasn’t used git before. “No, I meant lower-case m”, “Why have you put a space there?” etc. We stuck with this setup for far too long. Working remotely isn’t anyone's first pick but we weren’t making the most of the tools available to us. Setting up remote access is a faff but well worth the effort for those moments when you need to grab the keyboard.

Trying to do things simply was also a bad decision in regards to tech stack. I would normally use React to build websites; I used it to build my own and several Uni projects. However, in an effort to start Blair’s introduction to coding from the basics we opted to use plain old HTML and JavaScript. This meant we had an easier start and I didn’t have to explain JSX or what a Framework was. However, as the project went on this became a more painful choice, leading to a lot of duplication and reinventing the wheel.

The smooth start was nice but if I could turn back time I’d opt for a less simple setup to avoid these issues.

2. Not everyone is like me

I’ve spent the last 4 years immersed in a Computing degree and the summers in-between at internships or UROPs. For a long time, the majority of people I've worked with and been around have known a lot about Computing and had a strong interest in the subject. Working with someone who didn’t was an adjustment. Explaining things without being baffling, condescending, or just boring required some communication. I had forgotten that words like ‘Boolean’ aren’t typically used in conversational English.

However, working with someone with a different skill set was a boon, not a burden. Blair was able to come up with fantastic ideas for how the website should look and be interacted with. I didn’t necessarily understand why we were doing things with typography, coloring and positioning but I can certainly appreciate the final product.

3. Deploying Iteratively is actually a good idea

I know iteratively deployment is the right thing to do, I know things blow up when you try to do it all at the end but I thought I could get away with it. To my credit, it was a small project and it only needed to be deployed to Firebase. Blair didn’t want to release something unfinished and was unconvinced by my evangelizing of frequent deployment both directly to him and online. When we did try and deploy a near-final version we ran into a series of issues:

  • The small project was actually very big. High-res photos and long PDFs meant the project size was in gigabytes. Uploading all of it in one go to Git and Firebase caused issues until a combination of Git LFS, file compression, and partial commits did the trick.
  • None of the fonts worked. The way Google fonts were imported didn’t work over HTTPS. Instead of discovering this early and only having to make one change, we had to edit the CSS files for the vast majority of the website.
  • Google Chrome lied to us. We’d tested that the site was responsive using the device toolbar but found that on actual phones and tablets not everything reacted the same way.

Looking back there was a way to satisfy both good software development and Blair’s desire to not release something unfinished. In previous projects, I’ve used flags and config files to hide parts of an app still in development when it’s deployed. Fixing all these issues only ended up taking one stressful evening but I'd have rather done the right thing and gone without the headache.

Reflecting

This project was pretty low stakes but it’s caused me to reflect on the fact I graduate Uni in a couple of months. There are more non-techy people in my future and I’m about to lose the incentive of grades to follow good Software Development principles. I think building this website over lockdown has been a good learning experience. Not so much because of what I’ve been doing but because of the context I’ve done it in.

If you’re embarking on a project with someone at the other end of a Zoom connection, a loved one, a person from outside your field, or all 3 I hope my lessons have been useful!

I also hope you check out Blair’s website!

--

--

Joe Rackham

Professional Software Engineer @ Microsoft - All opinions my own