Posts
-
Remembering in public: starting a digital garden
I’m publishing a subset of my private notes as a digital garden, as a home for unfinished thoughts, experiments, and random facts I find interesting. Easy to update and without the pressure to craft a polished essay, I hope it will complement this blog. I don’t necessarily expect anyone to read any of it, but it’d be lovely if somebody found something interesting there and started a conversation with me about it!
Right now it’s mostly a bunch of original1 cocktail recipes, but I’m looking forward to growing this garden over time and seeing what it becomes.
-
Cocktails have been around for a couple of hundred years (estimates vary) and most cocktail recipes are simple variations of other recipes, with an ingredient substituted or proportions tweaked. This means parallel evolution is extremely likely, and any recipe will have been “invented” multiple times by different people. (In fact, many classic cocktails like the Manhattan and Martini have many competing and equally apocryphal origin stories!) So my cocktails are “original” in the sense that I didn’t follow a recipe when first making them, but I don’t claim that they are novel. ↩
-
-
13 Years of Blogging
Over the holidays I rebuilt this blog from scratch. This isn’t the first time it’s needed major maintenance. For such a simple piece of software, it’s been surprisingly hard to keep operational for - at time of writing - 13 years. I thought a recap of its history would be interesting, if only as a cautionary tale for my future self.
Since I started this blog I moved country, got married, became a US citizen, adopted two cats, bought a home, sold a startup, worked at several companies and did three stints as an independent contractor… and somehow didn’t yet manage to write about any of those things on this blog!
-
Startup engineering (part 1)
What should the engineering team of an early-stage startup care about?
The obvious answer: making the startup succeed. Making something people want, growing revenue, landing that big customer or the next funding round. But everyone in a startup cares about those things. What should engineering, specifically, care about, in order to make the startup succeed?
There’s loads of advice online about how to be effective founders, how to refine your business plan, how to validate your product thesis. But I haven’t found much written about effective engineering for early-stage startups. This is a shame, because for most startups, engineering is pretty important. It’s how you build your product - not to mention probably the majority of your headcount - so the way you go about it will affect the kind of product you build, and even the way your company operates.
When you do find advice about startup engineering, it tends to be limited to cursory admonishments to “move fast” and “get shit done”. These slogans aren’t wrong, but they are overly dismissive and reductive. They suggest that the way you do things doesn’t matter at all: anything which doesn’t look like immediate, visible progress must be a waste of time. This all but rules out introspection and improvement. It offers no help with answering questions like:
- Should we do code review?
- How do we prioritise maintenance work versus developing new features?
- Is it worth it to host our own infrastructure rather than using a cloud platform?
I’d like to suggest a more constructive theory of what an early-stage startup engineering team should care about, to help answer those kinds of questions.
-
How to get started making cocktails
As well as software, I also make cocktails. I got into it a few years ago, and by now it’s become a fully grown hobby, as evidenced by the entire kitchen shelf given over to bottles, and the ongoing invasion of my fridge by Mason jars of syrups and infused spirits. (Luckily my roommate considers that an acceptable price to pay for having an onsite bartender!) One question I often get asked is: “How do I get started making drinks at home?”
Home bartending is a very satisfying hobby, not least because you’re working with booze. It offers much of the creativity and sensuality of cooking, but with a fraction of the prep and cleanup work. And there’s a thrill to making a tasty, classy drink at home, for around $4 instead of $8 plus tip. And it doesn’t take much to get started. Your average kitchen is probably only missing four cheap pieces of equipment to make a wide variety of cocktails.
If you want to get started for yourself, the following are my recommendations for what to get. They also make a nice gift package: buy someone these, wrap them up as a set, and they’ve got four fewer excuses not to start mixing their own drinks.
-
Move fast with confidence
If you work on a software product team, you’ve probably heard, or said, things like this:
- “The deadline is unreasonable, I can’t do a quality job in that time.”
- “Just ship it already, it doesn’t need to be perfect.”
- “Shipping quickly is the priority, so we don’t have time for testing and code review.”
- “We’ve been moving too fast recently and breaking too many things. We need to slow down and be more careful.”
These sorts of statements often come up when discussing schedule or scope. They frame the decision being made as a choice between two approaches: you can do it fast or do it well, but not both.
I believe that “speed vs quality” is a false choice. Each time we naïvely frame a decision this way, we do a disservice to ourselves and to our users. Sometimes the best way to run fast is to be confident in your footing.
-
Let's talk about confidence
Ever been in a conversation like this?
Engineer: “We’re going to have to cut feature X if we want to launch on time. It’ll take two months to build, but the deadline’s in a month.”
Product manager: “That’s a shame - our competitors have that feature. I thought you demoed it last week?”
Engineer: “That was just a prototype. We can’t ship it to users.”
Product manager: “Why not? It looks awesome, and it worked fine in the demo.”
Engineer: “Sure, it basically works, but the code is a mess, and we haven’t done any testing. It’s not ready to ship.”
Product manager: “It doesn’t have to be perfect. We need to move fast now - we can always fix it later.”
Engineer: “That’s what you said last time. Fine, we’ll ship the prototype… again. Don’t blame me when it breaks.”
Each person is trying to manage the risks they know about, and do what’s best for the business. Despite the best of intentions, these conversations can feel frustrating for both parties. It’s easy to feel like the other person doesn’t understand your concerns, or is stubbornly clinging to their own principles. The optimal decision is probably somewhere in the middle, but this kind of discussion rarely gets there.
I previously argued that we should stop using the word “quality” because it tends to polarise conversations. Now I want to offer an alternative. I propose that most conversations about schedule or scope would go better if they were framed instead around confidence.
-
Let's stop talking about quality
I don’t like discussions about quality in software.
Don’t get me wrong. I want to build software I can be proud of. I want to be part of teams that build great products. I aspire to craftsmanship. What I dislike is the word “quality”, and how it tends to polarise conversations.
Quality is subjective
A lot of factors go into software quality. Good software is fast. Good software is maintainable, readable, scalable, and well tested. Good software has attractive UI and intuitive interactions. Good software has no bugs, or at least no serious bugs, or at least no bugs that our customer support team can’t work around.
In practice, quality means whatever you want it to mean. To a fan of unit testing, quality means investing in unit testing. To a designer, quality means beautiful screens and careful interaction design. To a customer support manager, quality means all bugs are documented and the serious ones have an ETA.
If you tell people that your estimates are higher than expected because you want to do a quality job, some of them will think you’re spending time refactoring and writing tests, and some will think you’re going pixel-by-pixel in Photoshop. Some of them will end up disappointed.
-
Programming is not magic
When people who program want to convey to others the joy and satisfaction we find in our craft, we often liken it to doing magic. The analogy evokes a sense of empowerment, possibility and freedom. But I think comparing programming to magic actually does unintended harm, because it has another connotation: that programming is a mystical ability, something you are born with, not something you can learn.
I want to get a lot more people programming, and I think we need a better analogy to get there.
-
What programming is like
What is programming like?
We in the software profession have done a terrible job of explaining to the public what it is that we do. Everyone has interacted with a teacher or a doctor. There are TV shows about lawyers, cops, even government officials. However warped our impression of their day-to-day, we can relate to these professions. TV depicts programmers as modern-day wizards, socially aloof, hacking into systems or bringing the new algorithm online just in time to stop the cyberterrorists — totally disconnected from people’s experience of the software they use every day. Software remains mysterious.
This isn’t just a problem for awkward “so, what do you do?” conversations at parties. I believe one reason why so many demographics are underrepresented in software is that unless you grew up with it, you’re unlikely to have the faintest idea what making software is actually like. Why would you strive — particularly against economic obstacles and systemic biases — to enter a profession you know nothing about?
Programming sucks
Inspired by a friend who couldn’t see what was so hard about programming, Peter Welch wrote a hilarious, heartfelt and all-too-true rant about what writing software is like. His title, and answer: “Programming Sucks”. The whole, long post is enjoyable reading, but here’s a representative excerpt:
Imagine joining an engineering team […] for a bridge in a major metropolitan area. […] The bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. […]
Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.
-
Early afternoon serendipity
Rainbow uplighting.
-
Inception isn't science fiction (spoilers!)
This is an insightful analysis of Inception, but I think it doesn’t go far enough.
Spoilers below
-
Vim wizardry #1
(I wrote this as a response to an Ask Hacker News post about learning Vim, but I thought it deserved a life of its own.)
This is one of my favourite Vim features. Say you have the following code:
do_something_with(some + long * complicated * expression) ^Say your cursor is where the caret indicates. Typing
ci)(“change inside parens”) in normal mode will:- delete all the text between the two matching parens
- place you in insert mode with the cursor between the two (now adjacent) parens
- put the deleted text in the yank buffer so that
pwill paste it.
The use case here is obviously so you can assign a name to that long complicated expression.
ci)is much easier than selecting it with the mouse, and keeps your hands on the keyboard where they belong ;) -
Please demand debate on the Digital Economy Bill
Don’t let the Government rush draconian internet laws through Parliament before the election: write to your MP! I did.
-
The genesis of a building
Witnessing this is pretty cool from a “making things” point of view. Shame it’s happening right outside our flat.
-
Limerick Lisp-style
In honour of the Functional Programming eXchange, on a bus to which I am writing this.
(a (program (writtenp :in 'lisp)) (may 'be (and (simple) (elegant) (crisp))) (but (cry '(C pros) "too *fancy();" "for (i; simply(); &cant++ + ++see)" "{ the code; for (;;) { the parenthesis; } }"))) -
My first Manhattan
-
Made enchiladas
-
Why the Digital Economy Bill is flawed
My MP, Meg Hillier, was kind enough to respond by post to my email about the proposed “three strikes” legislation in the UK. The main content of her response was to forward me a letter she received from Stephen Timms, the Minister for Digital Britain (his actual job title, I’m not making this up), to “clarify the Government’s position on this issue”.
The forwarded letter mostly just rattled off the party line - illegal file sharing is illegal, artists need to be compensated, the usual unjustified claims of urgency - but it did mention the recent report by the UK Intellectual Property Office, awkwardly entitled © The Way Ahead, which is actually pretty encouraging reading: I will discuss it in a separate post soon.
My previous email focused on problems with the “three strikes” approach. Since the Digital Economy Bill was published we’ve discovered that “three strikes” is only one of several nasty tricks up Mandy’s sleeve. Therefore, and because I felt from her letter that Ms Hillier hadn’t really taken my concerns on board, I wrote back.
-
Regex style in Ruby
Reading Patrick McKenzie’s excellent practical example of metaprogramming, I came across a line of code I didn’t understand:
caller[0][/`([^']*)'/, 1]That line taught me three new things about Ruby:
-
On "three strikes": email to my MP
An email I wrote to my MP (using the very handy WriteToThem) regarding the UK Government’s so-called “three strikes” proposals to combat illegal filesharing.
subscribe via RSS