City life

As my final days at daisie draw to a close, I’ve been reflecting on lessons learned, the people met, and the opinions encountered.

Prior to joining the London startup, I earned my spurs at Tomango, a creative agency in Sussex. When I say in Sussex, I mean in the middle-of-a-field Sussex. It was an idyllic location, about as far from a city as you could get. There were no amenities, no shops, no fancy coffee joints and certainly no Deliveroo.

I anticipated, and looked forward to the inevitable culture shock of coming to the city after six seemingly sheltered years in the field. Working in a team of ‘city developers’ and learning from them has been invaluable. But I, in hindsight naïvely, didn’t expect some of the different approaches, values and opinions they’ve had, particularly when it came to the state of the web.

Jake Archibald recently posted a fascinating comparison of F1 team’s web performance, two subjects very dear to my heart. But it was the final thoughts that really hit home:

None of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

oooph. Nail on the head.

It reminded me of an encounter in my first week or so at daisie. I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!"

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m extrapolating from a dataset of two points and cursory industry feelings, but I feel like the web built in the city, is disparate to that outside. Or perhaps, the web built in ‘city-sized’ companies is different to ‘village-sized companies’. And from what I’ve encountered, the Wealthy Western Web is very much alive in Shoreditch.

Products & apps, not websites

Perhaps this disparity stems from the unhelpfully vague term ‘web app’? When working at an agency building for small/medium businesses, it’s rarely disputed that your job is to create websites. Even if the client uses the site as a ‘business-critical system’, it’s still a website.

But since crossing the M25, I’ve heard the term web app floated around much more readily. “We’re building a product, a web app”. Maybe it’s a justification for funding, or a personal/corporate brand thing, but ‘website’ doesn’t appear to cut the mustard in London.

‘Web app’ covers a multitude of sins.

Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.

The phrase ‘You can’t build Gmail without JavaScript’ is usually pretty quick off the lips of the web app aficionado. Not only is that statement false (I wholeheartedly believe you could), it totally misses that point that I’m not building Gmail, and neither are you.

Tim and I recently mulled over our work and independently came to the same conclusion. Not all of the app/site needs to be controlled by JavaScript. When you dive into the framework pool, the natural, and most documented step is to write it all in the framework. But in the real world, we both felt that there were only two sections of the site that truly benefitted from a client-side implementation. The remaining majority could’ve been achieved with a static or server-rendered build enhanced with JS.

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

Team size

Team size could be a factor in the divide between city and rural development. Businesses in cities tend to be vast and distributed. Employees will usually have a specific role, and will be in a team of colleagues doing similar or similarly niche roles. Everyone has their place and sticks to it, to keep the company running efficiently.

Not only will the field of vision be narrow, but the number of project touch-points may well be limited. Big companies are like big ships, they aren’t all that agile and take time to react to change. New and varied sites will come about far less frequently for those in a big company, so their experience will be more specific.

That large team can easily exist in a bubble, much like the bubble that Jake described. So it’s not a surprise when the question: “WordPress! Who uses that anymore?!" gets asked. The underlying motive is often “We haven’t used WordPress in years, therefore no-one has used WordPress in years”.

In closing

It’s certainly been fascinating working in the startup world this past six months. I’ve learned a huge amount about prioritising, MVP’s and iteration. I’ve also learned that rural developer and city developers, while different in many ways, are similarly skilled.

Making the leap from Sussex to London was daunting, I thought that I’d be out-skilled by the big company developers who regularly have the loudest voices online. But to my delight, that’s not been the case. It’s brought me encouragement that we’re all building for the same platform, and it’s a testament to the web that it can work for both city and rural developers alike. We could learn a thing or two from each other.