Not a design system. Not a React component library with Storybook, documentation, versioning and a Figma counterpart.

Just a page. An inventory of the headings, buttons, layouts and all the little bits that make up the site.

It's been surprisingly refreshing, and got me thinking about how I ended up back here.

Making it work

I started building websites back in 2005, and I still remember many of the tricks we used to get a design looking just right across different browsers.

Cutting up Photoshop files and putting them back together in HTML was the day-to-day. Drafting sprite sheets, sliding-door backgrounds, images for rounded corners and fonts before @font-face — If you know, you know.

Working in an agency, jumping across projects and picking up other people's work meant we needed to find ways to make things quick consistent and understandable.

For me, this was a humble single-page style guide.

Much like Story book, it was a collection of every heading, button, form and component variation rendered in isolation. Powered by sensible CSS conventions, reusable templates and eventually approaches like BEM to keep things organised.

It wasn't particularly clever, it didn't need to be, it was all out of the box, low dependency and low tech.

Somewhere along the way

Twenty years later, I've spent a good part of my career standing up and maintaining sophisticated component libraries and design systems. I've know first-hand how impactful they can be when done right, particularly across larger teams and products.

However I've also watched us add abstraction upon abstraction, dependency upon dependency, libraries to manage libraries, tooling to manage the tooling and systems to support the systems.

I remind myself of left-pad, where in 2016, the tiny npm package was unpublished and broke builds across the JavaScript ecosystem. A few lines of code that was buried in dependency trees, caused widespread disruption.

A decade later, supply-chain attacks like Shai-Hulud have made those dependencies an even more serious consideration.

Now we have AI writing code, AI scanning for vulnerabilities and AI suggesting fixes. A machine-on-machine arms race, with developers caught in the middle reviewing pull requests from one machine to fix code written by another.

Watching the industry become inundated with this makes me want to let the bots fight it out and ask you to wake me when they're done, or perhaps its more like a spring clean...

I'm joking, well mostly... These tools are useful, and these established systems and libraries solve real problems. But there's something faintly ridiculous about the amount of machinery we've built to maintain all the other machinery. I keep hearing the words of an old mentor "keep it simple stupid".

Back where I started

In my previous post, I talked about moving from the things I need to the things I want.

Well, here's something I don't want. More complexity for the sake of it.

For this website, I'm finding myself quite happy keeping my head down, using the lowest level of abstraction that gets the job done.

HTML for structure, CSS for presentation, JavaScript where it's needed. A few templates and my trusty old style guide.

Browsers are considerably more capable than they were twenty years ago. We can do things natively now that once required all manner of workarounds in the past.

I'm not suggesting we abandon modern tooling or that the old ways were better. I certainly don't miss Internet Explorer or Netscape Navigator.

But it's nice to be reminded that underneath all those abstractions, it's still HTML, CSS and JavaScript.

And sometimes, that's enough.

There's a point in life where your Christmas list changes from things you want to things you need. A decent frying pan, new socks, the boring stuff that makes life easier. These days I'm going back to asking the big man for things I want. Still, nothing I won't use, but things that make me happy rather than things that fill a void.

The last version of this site was a needs list. Minimum viable, fewer dependencies, nothing it couldn't justify. This one is a wants list.

Five years, a few jobs and a small human later, I've got considerably less time for tinkering. But I've also realised I miss making things just because I want to make them.

A proper kitchen

The site had quietly become more of a representation of my kitchen than a blog, and I needed a new one.

My recipes started life on a spreadsheet that was essentially a dumping ground of things I'd made rather than a curated cookbook. Originally I was cooking something new every week, but eventually it became a log of recipes I'd found buried among the 50 open tabs on my phone. I write notes in physical cookbooks too, so the next logical step was to centralise everything somewhere I could actually keep track of and share it.

Transitioning from the sheet to the site was painful. Some things were in metric, some were in US measurements, a few were jumbled up, and some methods just said "make the thing". So I got stuck into clearing out the mismatched tupperware.

Recipes now have proper sections for dishes with multiple components, and ingredients are checkboxes you can tick off as you go (using pure CSS). There's a switch between metric and US measurements because apparently we still can't agree on how to measure something. The conversions happen at build time, so they'll even work without JavaScript.

I've added a "cook mode" that bumps the text size up so you can read it from across the worktop, turns the method into a checklist, and asks the browser to keep the screen awake. No more jabbing at your phone with hands covered in whatever you're cooking. I'll be testing and fine-tuning this over the next few weeks.

Adding a recipe is now one step too. I paste a link and a recipe page comes back as a pull request, with the method rewritten in my own words and credit given to the original. A lot less copying, pasting and faffing about.

The things I wanted

My logo has always been a single, very detailed icon. I've had this contact sheet idea knocking around since it was designed in 2013, and I've finally got round to doing it.

The artwork is drawn once per page as an SVG symbol, and everything else is just use'n it. Each tile on the homepage shows a different crop of the same image, zoomed and panned using viewBox.

Whilst the homepage loads the tiles as one picture of the whole mark and then pull apart into their own contact sheets, the 404 page does the opposite, there's an underlying design choice there or something.

Nobody needs a homepage like this one, but I wanted one that's a bit of fun. There's more fine-tuning to do, so check back later, or not.

Keeping it lean

Just because I wanted a few toys doesn't mean I wanted to drag in everything and the kitchen sink.

• System fonts, so there's nothing to download.
• Dark only. One colour scheme, to rule them all.
• Plain CSS components instead of a framework, you guessed it, no React.
• The unused stuff went. I ported a component library from my design system, then deleted every piece the site doesn't actually use.

My logo used to be embedded in every page. Now it only goes where it's needed, and a typical recipe page dropped from 42KB to 13KB. The whole site went from 4.8MB of HTML to 1.6MB.

Every page has a proper description for search engines now too. It turns out none of them ever had one.

It's not perfectly optimised, and it isn't trying to be. The homepage animation is there because I like it, not because it scores well. Lighter where it matters, fun where I want it, and a return to old skool front-end development 101.

Every byte is sacred, every byte is good.

How it got built

I am a number of years past waking up in the middle of the night with a new portfolio idea and being able to afford to spend a night building it. Since I threw my old site up, I've got less time than ever, so I paired on most of this with Claude Code.

As an engineer turned manager, it was a fun and interesting way to spend some evenings. It felt a lot like working with a quick and keen design engineer: brilliant at the legwork, occasionally confident about the wrong thing, and much better once I'd been clear about what I wanted.

It also meant I could spend more time on the bits I enjoy. Playing with ideas, figuring out how things should work, and occasionally making something entirely unnecessary just because I could. Sorry for all the tokens I burned.

In any regard the decisions are still mine, and so are the bugs. And I'll own the source code I only half-read, if the machine lets me.

Same dinner, better table

The idea hasn't changed and so, if you're reading this, you're round for dinner.

The following is based on something that I first experienced when I started reporting to a seasoned manager at FreeAgent. During our first encounter he sat me down and laid exactly what I can expect from him and what he expects of me. I'd never experienced such transparency but afterwards I knew exactly what our time working together would be like. It was great!

Why bother

I've given this introduction enough times that it now feels more like a professional courteously than anything else but I don't want to understate it's importance to my workflow. The aim is to build trust, be transparent and set the expectations as to what it's like to work with me.

Whenever I have a new direct report, meet another manager, or start reporting to someone new/different I give them "the speech". It not only encompasses who I am, how I operate and what I'm like to work with, it also keeps me right, accountable and grounded, it doesn't let me forget the type of manager I want to be.

The introduction

I keep my introduction notes on a document or email so it's easy to access and edit as I'm constantly fine tuning and tweaking it depending on the audience. I also find using a bulleted list keeps things conversational.

I always start with a brief introduction about myself and work history, followed by what it's like to work with me. I then set out expectations for the individual and then ask them to do a similar exercise. I tell my counterpart how long it's going to take and then ask them to "settle in for the speech".

About me & work history

Generally I'll start with my name, how I like to be called, where I'm based, what my family life is like and a couple of my interests. Nobody needs to know when my birthday is but I want people to know I'm more than a talking head on a computer screen.

From there I'll give a brief overview of my work history and technical expertise. I don't just load up my CV and read it out, but instead give a whirlwind tour of my journey to management, the areas I've worked in and a couple of key changes in career direction. I'm looking to show how I arrived here and that I've spent my time trying to stay technically relevant.

Working with me

Here's where I lay down my management style - which is everything from what drives me day to day to how to my take on work life balance. This is the main body of the introduction which run through quickly:

Here's an overview of what I normally cover:

• what drives me
• my values as a manager and what I pride myself on
• my approach product work, delegation and ownership
• the environment I like to work in
• the support I can offer/give
• my demeanour, what I'm like day-to-day and also when I'm grumpy or upset
• how to tell me if I'm wrong or heading in the wrong direction
• how I like to receive feedback
• how I handle conflict inside and outside the team
• how I will respond if I don't know
• my expectations around communication
• work/life balance
• my daily/weekly working schedule (assuming I have it figured out already)
• how to reach me during the day, if I'm in a meeting, or out of hours
• my take on meetings and team ceremonies

There is a lot to unpack there and each of these things can be spoken about at length. I don't want to dwell or overload as it can be a lot to cover. What I'm trying to do is lay a transparent foundation about what to expect from me. I tend to say 1/2 lines about each and move on.

E.G "I like know what's going on so when I ask I expect an answer. I get it, "async comms" so I probably don't need an answer now, but I do need an answer."

Expectations of you

The final part of the introduction changes depending on who I'm speaking to. I won't ask for end of week updates from an executive and so I adjust this section accordingly but I find it easier to have a complied list of things here and omit those which aren't relative.

• Treat others with respect
• If you're frustrated come to me before you act or lash out
• I expect ownership of the work we do
• If it breaks we should care and fix it
• Meet the expectations for your role (a link to a document here helps)
• Highlight any risks, or ways of doing things better
• Status update on what you're working on
• Write it down or it didn't happen
• Be direct with me
• Speak up
• Tell me how you like your feedback
• ...and finally, tell me what you expect of me/your manager

At this point I generally receive a "wow, thank you", as most seem surprised about how this opens up the relationship between us. In particular the last question creates an opportunity for us to connect: "what do you expect from me". I've laid myself out, and now you can tell me how I can help.

Following up

It's equally important to follow up on this introduction as it really lays the ground for mutual understanding and trust. I've had some open up more than others which is fine, what matters is I tried and they know what to expect from me. Relationships aren't created in an instant but instead forged over many interactions.

Conclusion

It's a fact of managerial life is that people in your team come and go, but and when newbies join your team it's important to make the right impression and set clear expectations about working together. I feel this introduction helps set a common starting place for working with me at least.

I had originally built this blog using Jekyll which was ideal at the time. It had minimal dependencies, a shallow learning curve and used rails which aligned with the tech I was using at FreeAgent. I took a no JS approach with minimal, future friendly CSS. It was pretty much good to go. I just wanted something up... and there it was on a basic Netlify instance gathering dust... a year later. Why didn't I ship anything?

A lot has happened in the last year, there's lots of things I could have written about: I changed job, I evolved my managerial skills, I read a lot of interesting books, I was back teaching lindy classes in a COVID safe environment, I've been experimenting in the kitchen, I built a website for my wife. I've grown both personally and professionally and I want to talk about it... but, the impetus to ship this site hung off two major things:

1. Learn Eleventy (for eh, reasons) and
2. Migrate all of my recipes out of a stupidly large and unmanageable spreadsheet

So with it being the 1 year anniversary of "Minimal viable website" and a family gathering cancelled due to COVID I took the opportunity to migrate from Jekyll to Eleventy and implement a basic Netlify CMS over the 2020 Christmas break. thanks to a great community and fantastic documentation it was a relatively painless endeavour and I learned a lot in the process. I mean it's all just front matter, collections and templates really, all things I was familiar with already. ✅

I created a recipe section as a new home for all the recipes I've gathered over the years. The formatting was so inconsistent I spent more time standardising the content than I did piping all the data through Google sheets and generating the new collection on the fly. I went down the wrong road on more than one occasion but finally have something which was manageable, and shareable. The content is far from perfect, but it's usable and that's what I'm after ✅. Maybe I'll write about that journey a little later.

So here it goes, LGTM ✅, fuck it, ship it.

About 2 years ago I went through some disaster recovery which blew away my local environments and whilst I have some solid local back ups simply upgrading plugins and deprecated methods wasn’t a quick and easy win. In the end I spent a month of weekends reinstalling my local LAMP stack, meticulously fixing my old wordpress sites just to save a few bucks every month.

And I found myself looking at my old portfolio... I had the foresight to use minimal tools and libraries and yeah, I was super proud it. It was fun, had some of my personality and it got me work. What did else did it need. Now, I claim to know a few things about web accessibility and my old folio was heavily motion based, so much so it could make you sick. I wanted in to add a prefers-reduced-motion flag but when I tried to spin it up it was riddled with security holes and no longer maintained dependencies.

When I tried to add secure certificates (I mean, what year is it) my previous host could provide them but for £50 a month, per website (apparently OpenSSL wasn't an option). I was locked in. I took a step back, realised that it was no longer fit for purpose and just took it down.

So here we are. This website is an experiment in using only what I need. It's something for me. Somewhere to explore the challenges I face every day in the world of. And sure, there'll be some food related things coming soon.

I know, this isn't revolutionary, but there’s a few things that I've been wanting to talk about during my career and really I've never sat down to write before. I don't know who my audience is so I've chosen to write for me.

If you're reading this, I'll treat this blog like having you over for dinner. I'm making something I like and I want you to be there to enjoy it with me.