diff --git a/package.json b/package.json index 068d148..b676806 100644 --- a/package.json +++ b/package.json @@ -16,6 +16,7 @@ "@sveltejs/adapter-auto": "^1.0.0-next.71", "@sveltejs/adapter-netlify": "^1.0.0-next.76", "@sveltejs/kit": "^1.0.0-next.481", + "@types/leaflet": "^1.7.11", "@types/sanitize-html": "^2.6.2", "@typescript-eslint/eslint-plugin": "^5.32.0", "@typescript-eslint/parser": "^5.32.0", @@ -24,6 +25,7 @@ "eslint-plugin-svelte3": "^3.2.1", "prettier": "^2.5.1", "prettier-plugin-svelte": "^2.5.0", + "sass": "^1.54.9", "svelte": "^3.50.0", "svelte-check": "^2.8.1", "svelte-preprocess": "^4.10.7", @@ -35,6 +37,7 @@ "type": "module", "dependencies": { "date-fns": "^2.29.2", + "leaflet": "^1.8.0", "mdsvex": "^0.10.5", "mongodb": "^4.8.1", "nanoid": "3.3.4", diff --git a/src/content/posts.json b/src/content/posts.json index d483500..e1022f6 100644 --- a/src/content/posts.json +++ b/src/content/posts.json @@ -1 +1,8 @@ -{"hangover-square": {"title": "Hangover Square", "author": "Patrick Hamilton", "date": "2021-05-25T00:00:00", "book_review": true, "preview": "I was gifted this book by my mother, so I feel terrible for what I am about to say about it. It was gifted with the best of intentions: someone or other famous reported that it mad", "content": "

I was gifted this book by my mother, so I feel terrible for what I am about to say about it. It was gifted with the best of intentions: someone or other famous reported that it made them feel at home in London, a city I love. But a city that can feel indifferent to you. This book did not make me feel at home in this city. It showed how it is possible for a place to be the centre of art, politics, ambition and still allow anyone to shift un-affixed through their life.

\n

Credit where it's due: Hamilton captures this mood so well in Hangover Square, a book set in London in the winter of 1938. Written between 1939-1941, just as the Second World War loomed and then broke, the backdrop is bleak, and various characters' enthusiasm for the Nazi regime isn't particularly endearing.

\n

This is a bleak book. There is little in it to broadcast hope. We get a few weak flashes, but we know well enough that they\u2019re faltering and won\u2019t last the evening. Let alone the night. This is thanks to our hapless protagonist, George Harvey Bone: a man who seems rarely to have his own self interest at heart. A man who is in hapless love with Netta, a sometimes actress but always cruel woman who uses Bone for nothing more than social leverage and free drinks.

\n

The drudgery of unrequited love apparently runs in Hamilton's other works, namely Twenty Thousand Streets Under The Sky. He writes it incredibly well. Though I am largely unsympathetic to Bone, Hamilton draws out the sympathy, even when you're pretty stone-cold on the same narrative arc repeating itself for the fourth-or-fifth time in the book.

\n

Netta strings Bone, along with her two other drinking companions (and sometimes lovers) Micky and Peter through the pubs of Euston. Gin and beer and sandwiches appear cycle through this book. Unsurprisingly, Hamilton himself was a drunk. A lonely drunk. But golly can he write.

\n

This complete haplessness and lack of control over his whole life makes the book drag. There is little to no change in narrative style or characters throughout the book. We're introduced to Bone's \"dead moods\", what we might now recognise as schizophrenic or psychotic/depersonalisation episodes. Times when the illusion of self and consciousness are completely freed from him, and he is overwhelmed by a desire to kill Netta.

\n

But these are never explored. He's had dead moods for his entire life, but he's not known Netta his entire life. Are they an expression of things he truly wants, or some perfect negative of his \"normal\" self? We're never given any hint of an answer.

\n

At no point do you believe that Bone actually will change, or wants to change. He has no mastery of himself, he is subject to the abandonment of others. Romantically and platonically, people leave Bone. It's sad, but also I have no sense of who Bone was. He's taken advantage of by those around him, they see him as nothing more than the taxi fares and gin bottles he can buy. And they're not wrong. They're obviously callous and unkind and taking advantage, but... what else is Bone? Our poetic narrator.

\n

If nothing else, read sections of the book, just for the language. It is singularly the largest redeeming feature, making this book worth the (literally groan-inducing) effort that it took from me at other times. It reads as though freshly graduated from the school of Dickens, though with the bone-tired-from-the-effort-of-alcoholism that can\u2019t be bought at eighteen years old. A mature student of the Dickensian school, then.

\n

I\u2019m unsure if the prose capture the 1940s accurately, or instead a few decades before. I\u2019m not familiar with literature of the time. The little interactions between characters, or our narrators internal monologue all shine. Simply worth reading. Hamilton was a talented writer, and though I\u2019ll gladly turn my nose up at his choice of subject, the way he wrote it was good.

\n

Read it, but don't expect to be drawn in. 2.5 \u2b50

", "slug": "hangover-square"}, "wow-no-thank-you": {"title": "wow, no thank you", "author": "Samantha Irby", "date": "2020-09-01T00:00:00", "book_review": true, "preview": "Samantha Irby came onto my radar in 2019 after a reading slump from that time I was burned out by my job in a VC startup. _We are never meeting in real life_, her previous set of e", "content": "

Samantha Irby came onto my radar in 2019 after a reading slump from that time I was burned out by my job in a VC startup. We are never meeting in real life, her previous set of essays published in 2017, was displayed prominently in a central London bookstore it was a) bright yellow, and b) covered in a picture of a hateful cat - so I started believing in destiny and bought the book, read the book, and adored it.

\n

In 2020 I went through a reading slump because of burnout caused by being freelance but also by the extremely pressing apocalyptic vibes of the time (which have totally passed). This time, Irby let me know that she was publishing another set of works on Instagram (by public posts, not DMs) and rather than thinking about how I'm likely to deal with burnout in this cyclical manner until something changes, I bought the book, read the book, and felt a little bit better.

\n

This is the second time Irby's books have been a tonic for worrying cases of Readers-Block - something I don't want to google because I'm really hoping I just made it up[^1]. I read this book quickly because it is short, not because I am fast at reading - but I did read it quickly nevertheless, and I was sad it was over.

\n

Despite the affection I feel towards this book and Irby's writing style, I have a hard time describing anything about her writing in a way that would make anybody actually want to read it. So if you think you're in the market for cathartic, nsfw, but still celebratory personal essays - then you should buy this book. If you can laugh at yourself and the way you're far less cooler than you want to be, but also low-key maybe resent yourself for it - then buy this book. It's good and it's funny and the days are long enough without having to read the contemporary literary city romance du jour just because everyone else is reading it and you don't want to.

\n

[^1]: I just googled it and I'm definitely not the first person to be this clever which is not surprising but it is a shame.

\n

Now please, let me try and explain the punchline to somebody else's joke. Irby will let you know, in pretty much these exact words, that she either is, or has been, a dirtbag with leaky bowels who thought for much of her life that she would die alone, played out by endless CSI re-runs that dance light across her decaying body in an tiny flat in Chicago. But she's funny with it, ya know?

\n

For example, in we are never meeting in real life she writes in one essay about the time she had ate a bad hamburger before an interstate drive and had to squat out diarrhoea on the side of the standstill, snow-covered highway in front of strangers and also her college friends. And then in literally the next piece she writes about her dead father. In wow, no thank you Irby flits well between insecurities in her roles as a step mum, staff writer in Hollywood (lol what), Somewhat Famous Person, friend, and newly middle-aged woman. But she also speaks about how, obviously, she shouldn't get a dog, about how dirt-poor she was growing up, and generally what an all round gross kinda human she was and continues to be.

\n

I like self-derogatory humour. Some people use it as a way to fish for complements, some people genuinely think they're hot trash, but other people, like Samantha Irby, can talk bad about themselves and somehow do it without damaging meanness and with surprising tenderness and patience. Wow, no thank you is a hopeful book, and it made me feel less alone and strange. Even though nothing I just wrote (not even that bit about shitting on the side of the highway) would lead you to think that.

\n

At the same time, Irby doesn't smother you with \"just be yourself \ud83e\udd84\ud83c\udf08\ud83c\udf39\" or hashtag-relatable content. I've never got the impression that Irby is saying something just to make you feel good or just to make herself feel bad - she's just... talking. But talking in a way where she can tweak, re-word, refine, and prune the anecdote so that when you finally sit down for coffee/cocktails with her, the stories are honed. Sometimes they ramble, but so do I.

\n

I enjoyed wow, no thank you - obviously. It's not scribbled with notes in the margin and I'm not going to get it tattooed on by body, but it's dog-eared and battered from where I got half way through a chapter on a train or used it to grind along a kerbside (or however else it got so damaged). It's the kind of book you can easily resume and easily pause and therefore the kind of book that deserves to become a bit battered. I'd recommend it, yeah.

", "slug": "wow-no-thank-you"}, "project-hail-mary": {"title": "Project Hail Mary", "author": "Andy Weir", "date": "2021-06-03T00:00:00", "book_review": true, "preview": "When you read a Dan Brown book you leave it ready to put on your tin foil har. Andy Weir books make you feel ready to don a lab coat. He writes books that are clearly well research", "content": "

When you read a Dan Brown book you leave it ready to put on your tin foil har. Andy Weir books make you feel ready to don a lab coat. He writes books that are clearly well researched and very involved, but they\u2019re still readable. Dan Brown gets (at most) one of these two things.

\n

Project Hail Mary is inevitably going to be compared to Weir\u2019s 2011 The Martian, a book which received (well deserved) critical and public acclaim. It\u2019s a good book (read it) and an okay movie (watch it with friends, drink if you want). Just like The Martian, we follow a lone human (Ryland Grace) confined in a spaceship in space and faced with a laundry list of life-threatening problems. Grace is there because there\u2019s an existential threat to the human race, and so he\u2019s got to get on a space ship to solve it.

\n

Whereas The Martian\u2019s Mark Watney speaks to us through Captain\u2019s Log entries (v. enjoyable), Project Hail Mary has a more traditional narrative. Weir\u2019s 2017 Artemis follows a bigger cast of characters, so the narrative is more traditional. In fact, Artemis suffered a bit too much from bing \u201cmore traditional\u201d which is why not a lot of people talk about it.

\n

The writing in this book is solid. It\u2019s caricatured in places, and rarely (if ever) poetic. I wouldn\u2019t highlight or want to remember any particular part of this book. But I didn\u2019t expect it to be. Weir presents us with some really interesting biological/evolutionary theories and ideas, which challenge what you might think of as \u201clife\u201d. I don\u2019t need lyrical prose if you\u2019ve good big thinkers like that one. Still, don\u2019t expect to have your morals shifted.

\n

Take his book as something to be enjoyed on its own. It\u2019s like a party: good for you to do, but hard for you to explain why.

\n

We follow Grace through various engineering and biological challenges, twists and turns, which he dutifully solves as he tries to save a) himself, and b) the rest of humanity. The pacing is textbook. It is predictable and unsurprising, but well-enough written that it never lags, though towards the end you certainly start to predict the rhythms.

\n

The other problem is that the stakes never differ, or feel actually on the line. A problem emerges which is a 6/10 emergency, Grace does something to solve it and it goes down to a 0-3/10, and then something unexpected happens and we\u2019re at an 8-9/10 before he solves things and we move on to the next cycle.

\n

Even though you might not understand the problems, you always know that Grace is going to solve the problem, because Grace always has solved the problem. Everything is going to be okay in the end,.

\n

The content of the problems is what makes them interesting each time, though. Weir brings a level of knowledge and a depth of research that make you feel glad that you\u2019re not on a spaceship and that humanity isn\u2019t depending on you. Weir has the great scientific quality of \u201cX happened\u2026 so therefore Y\u201d. He\u2019s able to set the table rules in physics, chemistry, and biology and then explore problems close enough within those rules.

\n

If you\u2019re a practicing research scientists in any of these areas I\u2019m sure you\u2019ll roll your eyes at it. I\u2019m sure it doesn\u2019t withstand informed scrutiny, but I enjoy it.

\n

Despite all this heroism and know-how, Grace is a coward. Not an entire coward, not cripplingly. Humans can be many things in many contexts. Grace is a high school teacher in his 30-somethings (before he goes to space). His life has been shaped heavily by a lack of action or boldness in everything other than his academic career. Even in that he doesn\u2019t commit to it.

\n

We don\u2019t see any character development or changes in him. At the end of the book you know that he\u2019s the same person he was at the beginning, and I\u2019m unsure if he\u2019s had any level of self-awareness or knowledge. But (low-level spoilers here) he does manage to save the world and humanity, so maybe he\u2019s earned the right to stay a flawed man.

\n

It\u2019s a reminder that \u201ccowardly\u201d people can do good things, and that Andy Weir can write excellent science fiction, just maybe not great character work.

\n

I listened to the audiobook of this one, and I would definitely recommend. There are parts of the book which play with sound/language, where having an audio component really made this shine. The production quality added in a few non-vocal aspects which really brought it to life. I would totally recommend picking this up on Audible if you even remotely like audiobooks.

", "slug": "project-hail-mary"}, "hamnet": {"title": "Hamnet", "author": "Maggie O'Farrell", "date": "2020-10-18T00:00:00", "book_review": true, "preview": "_Hamnet_ follows Agnes, the wife of William Shakespeare, and her family - her brothers, children, in-laws - as well as several of the greater village populous. The book makes very ", "content": "

Hamnet follows Agnes, the wife of William Shakespeare, and her family - her brothers, children, in-laws - as well as several of the greater village populous. The book makes very few references to William, and never actually names him. He is always \"he\", \"husband\", \"father\", \"him\". Describing Agnes as \"the wife\", as I did mere sentences ago, serves only as an introduction, and as a drastic under-selling of Agnes.

\n

Set in a 1500s southern England, the book darts between the characters' present - following the life and early death of Hamnet, Agnes' only son - and the years preceding these events: Agnes' childhood, meeting her husband, raising a family. The heart of the plot is sparked by an historical fact: Shakespeare did have a son called Hamnet, who died aged 11 in 1596 from the \"Pestilence\" (the Black Death). Shakespeare never mentioned this death directly in his writing, and it's still unclear what impact this death had on the writer.

\n

O'Farrell never addresses this issue head-on, but rather through negative space and leaving feelings or events unaddressed or unexplained. This device is turned effectively against William, a man we know very little about - something which is true both in this book and in the broader historical perspective. His absence, rather than his presence, is what dominates this book.

\n

Hamnet is an exploration of the death of a child, and how it could have such little evident impact on the work of someone from whom we have so much writing, and who we associate with such breadth and depth of human expression. Where did the grief and sadness go? Grief is certainly present in this book, though O'Farrell spends more time, and perhaps more effort, on the theme of our identity set against our family and work. She covers love in various forms, secrecy, obsession, and obscurity in engaging ways - because we are all many people, circumstances dependent. Agnes struggles to reconcile a free and wild upbringing with the confinements and expectations of house-bound married life to a man who is rarely present, in any sense of the word.

\n

Much of Hamnet's story pins on character, with major plot events or twists being thin on the ground. O'Farrell shows us the small but rich inner lives of a village in the 1500s. We follow several characters throughout the book, and although Agnes is certainly given the most attention, O'Farrell has a way of fleshing out characters in short phrases and segments which, although sometimes spread many pages apart, feel cohesive.

\n

Just like you can't pull plot from character in this novel, I don't think you could pull character from language. To be frank, O'Farrell's use of language in this book is masterful. It is precise and pointed, it is emotive but it does not linger or repeat.

\n

There is a section near the middle where she describes how the Black Death arrived to England from Italy - it is a complete departure from the day-to-day lives in an English village, but she captures your attention and explains everything in human terms. This book paints portraits of people with familiar language, and allows the world to build around that - even if you don't realise you're building it.

\n

I also want to praise the light mystic / magical elements which O'Farrell scatters around Agnes. She is a woman who knows things. These are never fully addressed or explained, which is fitting: Agnes never questions or second guesses them herself. They are a part of her, and although Agnes knows other people don't have them, she never exploits or divulges too much to anybody. This adds an extra sense of life to the already very-much-alive world which O'Farrell has created as a backdrop to a vibrant piece of work.

\n

In Hamnet, O'Farrell has written a study of the human psyche when it cannot define or express itself. She has written in such transportive language, with light mystic elements, but the plot is almost irrelevant at times. There's a seeming lull in pace at certain points, and perhaps, at times, O'Farrell leaves a little too much unexplained or open to interpretation. Sometimes these are invitations to imagine the characters more deeply, but sometimes I felt conflicted or unsatisfied.

\n

Despite this, I would recommend reading Hamnet - ideally in the Autumn/Winter season, under fairy lights, perhaps with a coffee or tea while the rain thrums gently outside. It is a literary work of art, allow it to transport you somewhere else. 4.5 \u2b50

", "slug": "hamnet"}, "kings-of-the-wyld": {"title": "Kings of the Wyld", "author": "Nicholas Eames", "date": "2020-12-13T00:00:00", "book_review": true, "preview": "_Kings of the Wyld_ is a fantasy book which feels like three or four middle (or-upper middle) aged dudes getting drunk, playing Dungeons & Dragons, while classic Rock and Roll play", "content": "

Kings of the Wyld is a fantasy book which feels like three or four middle (or-upper middle) aged dudes getting drunk, playing Dungeons & Dragons, while classic Rock and Roll plays in the background. In a fantasy world where adventurers are treated like rockstars, the book follows an old band of adventures getting together for one last hurrah to save one of their daughters. The book knows what it is, and doesn't try to overreach itself. But at the same time, it does a solid job of portraying personal trauma and the process of ageing. If you like fantasy, and are familiar with the tropes, I highly recommend this book as a fun, and slightly meta, piece of fantasy. If you're less familiar with the genre, you'll likely still enjoy it, but realise there are some in-jokes or puns passing you by.

\n

The book is set in a fairly standard high fantasy setting - with the most notable geographic feature being The Heartwyld: an expanse of untamed forest and planes which are overrun by your standard fantasy monsters: centaurs, giant spiders, dragons, zombies, trolls... you get the idea. Though humanity was once terrorised by these creatures, humans have increasingly started killing them for sport and entertainment. Bands of adventures start to emerge, killing larger and greater numbers of beasts, before the sport is moved to giant Colosseum-like arenas. These bands of adventurers are treated just like the celebrities in our not-so-monster-ridden world.

\n

The premise of the book is relatively simple: the daughter of Gabe, the band's frontman, is stuck in a besieged town on the other side of the Heartwyld. He gathers the old band, Saga, back together for One Last Adventure to get her back. Saga was once the greatest band of all time, but since then the members have retired to a quieter, provincial way of life. Bringing them out of retirement sounds like a good narrative, but Kings is pretty honest about showing us how much the group really have aged, and how they're not the spritely young men they once were.

\n

We spend the book following Clay, Gabe, Moog, Matrick, and Ganelon - the members of Saga, as they trek across the map to save Gabe's daughter.

\n

Kings of the Wyld brings a relatively unique (at least to me) perspective: that of older or retired adventurers. We come into the story once they're well past their glory days and once friendships have been formed. This allows the book to step back from the immediate, arguably senseless, violence that we would expect on a traditional Great Adventure fantasy trope, and have a more honest, if not flawed, look at the people and actions involved.

\n

We're also introduced to a broad range of supporting characters: a new band of lovable rogues led by a charismatic archer, the band's old booking agent who's grown (even more) selfish and greedy, a two faced bounty hunter, a gold-loving cobalt. These all seem like familiar stereotypes, but they bring the world to life - the book doesn't focus solely on the members of Saga, and it feels like Saga really lived out their greatest day and then the world moved on past them. Somehow all the tropes and archetypes fit really nicely, and it never feels clich\u00e9. Tongue in cheek? Yeah, but it treads a nice line.

\n

The plot of Kings follows a similar pattern - although there's nothing particularly complex, unforeseen, or politically/socially astute contained within it - Eames builds a really interesting set of cultures, characters, and creatures. You're taken on a tour across a massive space, travelling in giant air ships, trudging through snow, burning down bars. It's really quite the adventure. You never hang around anywhere too long to get bored.

\n

Not every book has to ask you to rethink the role of religion in society, or the nature of destiny and duty. Some fantasy books can just be a good romp with some realistic characters. Humans are empathetic creatures, and as a reader before long you start thinking about the characters, and their feelings or situations, even if they are ridiculous. Eames sneaks in some real emotional moments underneath the adventure, and that kind of tonal shift is the mark of a good storyteller.

\n

Both pacing and language are only as long as they need to be, Eames has no issues with moving you on, even if you'd maybe like to hang around for a few more pages to see what kind of insanity could ensue.

\n

A lot of reviews I read for this book seemed to rate and note the humour in Kings - but I've got to stay, I didn't find it especially funny. There are moments of levity or little puns, but for the most part it shows a pretty grim and unflattering world, every now and again poking fun at the fantasy and rock-and-role genres. I liked this decision, it made a nice change, especially as Eames didn't play up the meta-jokes about fantasy tropes so much, and I don't think he ever broke the fourth wall, which I was worried he might do. It was enjoyable but far from the Pratchett standard, but I don't think comparing anyone against that would be a good idea.

\n

This book didn't bowl me over with anything unexpected, but it was a fun journey with an interesting twist, even if the premise itself is overcooked. It's a good escapist read if you know you're a fan of fantasy, but I don't know if I'd recommend it if you've not dipped into the genre for a while - or maybe I would, maybe it's the perfect re-introduction. I don't know, I'm not very stedfast in my opinions. 3.5\u2b50

", "slug": "kings-of-the-wyld"}, "on-connection": {"title": "On Connection", "author": "Kae Tempest", "date": "2020-11-14T00:00:00", "book_review": true, "preview": "Kae Tempest is a London-based artist who works with words. I first discovered their work in 2016, with the release of _Let Them Eat Chaos_ - a conceptual spoken word album which im", "content": "

Kae Tempest is a London-based artist who works with words. I first discovered their work in 2016, with the release of Let Them Eat Chaos - a conceptual spoken word album which imagines a London street at 4:18am. To be perfectly honestly I think Tempest has a well honed skill with words. Their work has spoken to me with clarity in times when not a lot else could get through. Some of Tempest's phrases and lyrics are burned, deep, into my brain and emerge with remarkable frequency when I'm just trying to live my life. So Tempest could have filled the hundred-or-so pages of this book with near nonsense and I'd still recommend it to anyone. Fortunately, they didn't do that.

\n

In this relatively short, and surprisingly personal, essay, Tempest talks about the purpose and process of making art. Of the difficulties of creation, of the things which make watching, hearing, seeing, experiencing art interesting, and of the things you have to accept as someone who wants to make art. I was delighted to find Tempest speak of their own past, and privilege, and experience. They have historically been rather cautious about sharing personal details, which is fair, but it's nice to see and read.

\n

The margins of this book were filled with highlights and underlines, it's a short piece and it's crammed with things I want to pay attention to, and to remember. It doesn't go on when it can be concise, but there were perhaps moments of repetition, or points which were presented and then immediately abandoned. It's a refined set of thoughts, but that doesn't mean it doesn't branch off every now and again. Which is fine, this isn't a textbook.

\n

As the book's title suggests one of the central turning points in this book is the role of art as a tool to connect us. As a tool for empathy, to remind us of others' inner lives, to connect us to ourselves. This connection is the source of tension - around which we can hang a narrative or theme to engage the audience with our art. Tempest asks us to consider both ourselves and the subject of our art - what are the things your character is trying to say, and what are the reasons you, the artist, think this is worth saying or hearing? What does this say about the subconscious version of your self, who you can watch but only if you really try? Tempest openly draws heavily from the Jungian ideas of subconscious.

\n

A secondary point which Tempest mentions rather nebulously throughout the first third of the book is our culture of capitalism. A good thing to be aware of, and criticise, but something which they only detail relatively shortly. Despite the brevity, it's a wonderful point: we are surrounded by notions of productivity and efficiency which value taking something, extracting it, refining it, and making something more valuable from these raw materials. We cannot view our relationships with others, or with ourselves, in this way. We cannot connect with people if we are constantly looking to extract and refine whatever we can from them or from our relationship with them, even if that thing is art.

\n

There's a bittersweet note in this book being released during the COVID-19 pandemic. Tempest talks about the unique ability of poetry to level an audience. To connect everyone listening to one act, one narrative, one performer, one voice. The ability of us to gather, hear something, and then move apart connected more closely to the people around us, despite having nothing more in common than when we arrived. It's pretty unique in human experience. We'll get back to gathering like that in the future, but it felt so implausible in the here and now, when I have been to precisely one live music event in the last eleven months, and I don't think I'll be going to any for the foreseeable.

\n

Tempest lives by example in this book - encouraging us to ask if there is anything unspoken or unacknowledged in our art. To consider if we the audience, or we the creator, would benefit from considering art in relation to our self. The vulnerability and open-ness they share throughout the book is encouraging, though maybe could still seem cagey if the reader isn't aware of Tempest before picking up this book. Despite that, I think anyone who loves or makes any kind of art, or who spends a lot of time working with people, will recognise the heart of this manifesto as useful.

\n

At very least, it is a short book, even if you hate it (but still feel compelled to finish it) then it's not going to take more than a few hours of your time. Not that that should be the ultimate selling point of a book, but you get my intention. Read this book, it might help you know yourself better, and give you a way to shape or vocalise your thoughts. 4\u2b50

", "slug": "on-connection"}, "queenie": {"title": "Queenie", "author": "Candice Carty-Williams", "date": "2020-09-26T00:00:00", "book_review": true, "preview": "_Queenie_ is an excellent debut by Carty-William. The novel's titular narrator pins you to the page - she has a strong and unique voice, yet also unreliable and unlikable at times.", "content": "

Queenie is an excellent debut by Carty-William. The novel's titular narrator pins you to the page - she has a strong and unique voice, yet also unreliable and unlikable at times. It takes you through something which feels both personal and also cultural: micro-aggressions, personal and collective trauma, mental health, and love and friendship in the early 21st century. It's a really gripping and motivating work that Carty-Williams manages to end on a hopeful, if a little well-trodden, note.

\n

Queenie is first-person narrative of a mid-twenties Jamaican-British woman living in London as she comes out of a big breakup. I can easily see the narrative resonating best with a younger audience, with sprinklings of e-mails and WhatsApp Group Chats scattered throughout the narrative, it feels like how I talk with my friends: frequently and with short messages. She's funny, but it rarely feels jarring or gimmicky or unrealistic. Sometimes the humour's intentional, sometimes its situational

\n

As well as the titular Queenie, the book has a (mostly younger) cast of friends, colleagues, family members, and a whole bunch of awful men. I'm serious, there are a lot of terrible men in this book, one of them calls his penis \"The Destroyer\", one of them licks Queenie's shoulder and says it \"tastes like chocolate\", even towards the end of the book they stop getting human names, and just get nicknames (Balding Alpha) which I think is a really nice subtle mechanic. Terrible men aside, Queenie's sassy young best friends (The Corgis) are 100% here for it, and her Jamaican family are trying their best. Sometimes the friends feel a little relegated to \"best friends of the protagonist\", but that fits nicely with the sometimes selfish first-person perspective that dominates at least the first half of the book. Either way, it's nice to see non-romantic love given a lot of screen time and responsibility in forming a life in response to a trauma. Even if our narrator doesn't acknowledge it or see it all the time, the book's got a lovely sense of community.

\n

As someone not from an immigrant family, who hasn't spent significant time in the homes of any first or second generation immigrant families - the and cultural presence and attitudes within a Jamaican household unit was introduced well and treated kindly. There is no othering of any party, nor does anyone explain more than is strictly necessary - you get a good sense at how some people live their day-to-day lives, and that's lovely.

\n

I can however, speak more for life as a young person in London. Queenie is so clearly written by someone who lives, walks, and sees London. The painting of strangers, her relationships with her friends and co-workers, the bemoaned but helpless state of gentrification. As someone who also loves this city, it felt right at home. Similarly, as someone in their late twenties who doesn't doesn't feel as though they have their life together, as if some friendships are competitive and some life goals are unfulfilled - this book makes me feel seen and a little less worried. It doesn't belittle or undermine the time and personal effort it can take to rebuild a life after something comes through and sweeps all the pieces away. We all know these things, but it's never a bad thing to be reminded of.

\n

It's not always particularly easy or comfortable reading, but Carty-Williams has created a deeply personal narrative without serving them up through a parade of unlikely or unrealistic scenarios. Issues of personal and cultural trauma, and self-destructive self-esteem issues are put in front of you but they often go unexamined or un-critiqued by the narrator, both because they are not noteworthy to her but also because she does not have the ability to recognise or confront them herself. This book draws empathy out of you like an angry tired toddler going to sleep - you might not want it to happen, but your brain's going to do it anyway.

\n

I think this is made even more effective by the first-person narrative. The book feels personal, but more cohesive than a stream-of-consciousness might give. You get patterns and trains of thought which are mostly, but not always, refined or perfect. The first person perspective was pulled off very nicely by Carty-Williams. She combines this with elements of an unreliable narrator, with facts or events being omitted and only referenced later, sometimes by other characters. It's just enough to make you question Queenie, despite being inside her head. Similarly, the passing of time feels uneven and variable. This is an inveitable during a trauma or dramatic event - time can slip or crawl by, seemingly with little control over it. This is something we've all been experiencing in the COVID pandemic, so maybe I'm just a little sensitive to it right now.

\n

With that said, the pacing wasn't perfect. Somewhere in the second third it certainly slumped, and some events or plot points felt a little awkwardly placed. It's like Carty-Williams had something she wanted to show a part of Queenie, or contemporary racism in London, but which didn't fit naturally within the flow of the plot. It's hard to find space between your protagonists' redemptive narrative and an ongoing societal observation/criticism, and that certainly shows at times.

\n

On the whole though, Queenie handles societal criticisms with admirable maturity. With the recent massive (re-)rise in the Black Lives Matter movement throughout 2020, Carty-Williams manages to take an approach which does not feel clich\u00e9 and which engages you in the conversation. It does not feel tired, fuelled entirely by emotion, or reliant on impersonal facts or figures. Carty-Williams has certainly benefited from the current awareness, but she does not depend on it. There doesn't seem to be any singular agenda being pushed ahead of the narrative and it remains foremost a work of fiction driven by characters and empathy. For someone who's interested in the lived experience of these cultural issues, Queenie provides them to you without always highlighting them. You get a real \"oh cool this again\" when people make what are quite clearly racist remarks, even though \"I don't see colours\" and \"I'm not racist but...\"

\n

I think a lot of people, young or old, would benefit from reading Queenie: it's a well written, narrative-driven book which communicates in a thousand subtle ways how it feels to be mid-late twenties in London in 2020. I can't speak to how it conveys the lived Black experience, but it is explained clearly and introduced without pandering. Even if you just want an interesting read to understand mental health a little better, this book will do that. I really liked this book and I'm very excited to see where Carty-Williams applies her noteworthy aptitude for character next. 4 \u2b50

", "slug": "queenie"}, "the-phoenix-project": {"title": "The Phoenix Project", "author": "Gene Kim, Kevin Behr, and George Spafford", "date": "2020-12-02T00:00:00", "book_review": true, "preview": "*The Phoenix Project* (TPP) is a a fiction book for nerds (said the nerd, on his blog). It's a parable for people who design, build, or deploy software. I want this article to jus", "content": "

The Phoenix Project (TPP) is a a fiction book for nerds (said the nerd, on his blog). It's a parable for people who design, build, or deploy software. I want this article to just be about the book itself, not its content. The things I, as an engineer, found interesting about The Phoenix Project deserve their own post. Instead, this piece takes a more literary, or meta, look at The Phoenix Project.

\n

TPP is set in Parts Unlimited, a (fictional) automobile parts manufacturing company in America. As a company, Parts Unlimited is carrying a great deal of technical debt and business pressures. So it's set in a very boring, but realistic, scenario - and follows some very boring (but interesting and important) discussions and events which transpire in the process of building software in Parts Unlimited.

\n

TPP follows Bill, an middle-rung operations engineer - someone who is responsible for deploying software to become available to the end users (clients, stores, internal staff). Within the first chapter of the book, Bill is promoted from his comfortable job into a higher management role, which he does not want to take. The rest of the book follows Bill as he slowly realises just how bad the process of building and deploying software has gotten in his own company. The titular Project Phoenix is a long-overdue software product which the company planned and built for the last 12-24 months as a response to increased velocity from their competitors. Bill, with the help of his mysterious sensei (and potential board member) Erik, spends three hundred pages implementing solid working principles and protocols into Parts Unlimited, informed heavily by current manufacturing practices.

\n

It's actually quite a hard book to explain. While The Phoenix Project is technically fiction, in that the people and places are made up, its goal is to explain a certain (very real) way of building software - and similarly to explain the consequences of other approaches. Where other books may be concerned with exploring relationships, ideas, or language - this one wants you to understand that you really need to be able to visualise work-in-progress in your engineering teams. It shows you how a lot of people in a business think about both their job in the business, and the job of the business to them.

\n

Look, if you're a software person, this book has probably already crossed your radar. It's one of the cornerstones of modern Dev-Ops, at least in the last five years. It spawned a number of other influential books like The Dev Ops Handbook, The Unicorn Project, and The Three Ways. If you're not aware of this book, or what words like \"Dev-Ops\" and \"Sofware\" mean, then you probably stopped reading half way through the last paragraph (at the latest).

\n

My immediate reaction after finishing this book is that there should be more books like it. It is a fantastic way to introduce people to the forces and constraints in building and managing modern software. If you're inside of the software bubble, it showcases the nature and scale of business and financial forces; if you're in on the business front it introduces you to the pressures and complexities that software people are under. If you're both (like a CTO or CIO) then it will help you think about ways that communication and information flows between IT and other parts of the business.

\n

I build software for the web, an area famous for evolving quickly, for re-inventing the wheel with new technologies, and for being an engineer with a degree in an unrelated subject (like music production or... environmental science, for example), thick glasses, and a MacBook Pro. There's a certain culture, at least that I've experienced, that engineers should always be on the professional development hype. I don't think this is unique to web developers, or even to software engineers, but I do know it's pretty prolific in my field. This can make it very easy to jump from one project, language, framework, or trend to the next - and never stop to consider what you're building or why. It can mean reading sparse documentation, or just forging ahead and ignoring existing documentation.

\n

TPP brings a much more abstract level of thinking to the process of building software, and places both engineers and software within their wider contexts. Individuals are in teams, which are in departments, which are in businesses. Software projects are managed by teams, and linked to business objectives, etc. etc. TPP shows the value of thinking about these things, and introduces them without ever pointing them out.

\n

A lot of these benefits are emphasised strongly because the book only gives you an overview of the specific technologies used. It becomes almost impossible to get lost in the weeds, the book keeps you firmly out of the garden. In fact, to continue this analogy, the book sits you down with the head grounds-keeper and makes you follow them around for a few months while they do their job. For engineers, especially those who are closer to the strategic or planning aspects (or who wish to progress there), this is a really good thing.

\n

Engineering tends to attract people who are problem solvers, and a lot of the problems which are presented in TPP are large and fuzzy. For example: how does the business decide what software gets built? When can we say software is \"done\" or requirements have been met? How do you know who needs to be aware of your planned actions and changes to hardware (real or virtualised)?.

\n

You could begin to optimise tiny parts of these specific questions, maybe increasing the efficiency or throughput by 5-10% on a single part; or you could examine the system as a whole. TPP encourages tackling these big questions, and doesn't assume that people will hear you say \"we would like to completely redesign this from the ground up\", and the respond with \"sounds great, take all the money and time that you need\". These decisions are messy, both personally and for the business.

\n

Something that works really well in the parable format is the introduction of archetypes: certain kinds of personalities or a certain kinds of jobs. Our tiny chimp brains find these things useful for understanding other people. For example it's why I actually enjoy hearing people talk about the star signs, and it's why we have so much fun arguing who's a Carrie, Samantha, or Miranda . TPP introduces us to a relatively small (maybe 10 person) cast of people who work at a company. This is a good number: it's enough to focus on each of them, their personalities, and the way they contribute to (or block) other people. Hopefully it's enough to help the reader think, at some point, \"Ah, this guy's a bit like Brent\" or \"Ah, she's a Patty\". This is a hugely useful generic human skill which we encourage in our personal lives, but which we often assume \"you'll learn it on the job\" when it comes to our working lives. This is a nice little helping hand, especially if you're newer in your career or come from a smaller or less diverse team.

\n

While I have praised TPP for not being too technical, this does come at the cost of giving us a lot of names and phrases to Google if we want to actually learn the details. This is good though, it gives you the vocabulary to go away and google things that are relevant, and the chance to ignore things which aren't. It means you can read this book in several sitting and get a good overview, but also to dig deep into anything you find particularly interesting. To this end, TPP knows its role is more of a gentle introduction than a technical primer - it assumes you don't know anything, and that you may not even be able to diagnose, let alone solve, any of the technical problems. Luckily, that's largely irrelevant.

\n

With all this said, the book certainly wasn't one that I simply couldn't put down. In parts it was tough to read. Notably some of the characters and interactions were a little too caricature-ish, and some of the sections invoked horrible flashbacks of people who knew nothing about software asking something impossible or telling you how to do something in a bad way. I had quite a visceral reaction to these sections, and from conversations / online reviews, I know I am not the only one. This speaks to the authors' experience in actual workplaces, and their ability to capture the practical difficulties that enterprises might be facing.

\n

I've also got some other questions, primary among them: why has everyone in this book served in the military? Bill, our protagonist, has. So has his boss. And so has his teacher. And so have a couple of other people he meets. Why are all these veterans working at this failing automobile parts manufacturing company? I guess that it's a good way to signal \"get to know about your colleagues' lives before their current job\", but also it could be seen as \"assume everyone loves routine, command chains, and discipline\" (which they don't).

\n

Perhaps a more serious critique would be to ask why this book adopts the mystery-thriller literary practice of leaving us out of problem solving. There are plenty of \"I screwed my eyes tight and thought about it, I was so close to solving it\" and \"He was almost onto something\". It felt a little staged, but also I guess you need something to stop this book descending into some kind of technical swamp.

\n

All in all, The Phoenix Project is a good book, mainly because it knew what it wants to be: an introduction to modern IT practices in an enterprise setting for anyone remotely involved in IT within a business. It's not got stunning language, considered character work, or a suspenseful plot - but it has a lot of clarity and charm. If you work in software, especially in a position where you can affect change, I would really recommend picking this up and reading it the whole way through - there's a very high chance that you'll find something useful to you. 4\u2b50

", "slug": "the-phoenix-project"}, "an-absolutely-remarkable-thing": {"title": "An Absolutely Remarkable Thing", "author": "Hank Green", "date": "2020-11-08T00:00:00", "book_review": true, "preview": "An Absolutely Remarkable Thing (AART; because I'm not paid by the word here) is a wonderful Sci-Fi(-ish) adventure by Hank Green, one of the content creators in the first wave of t", "content": "

An Absolutely Remarkable Thing (AART; because I'm not paid by the word here) is a wonderful Sci-Fi(-ish) adventure by Hank Green, one of the content creators in the first wave of the YouTube-meets-mainstream movement. It's a delightful first piece in his The Carls series, and even if the characters fall a little flat - the story is compelling enough to make this book a delightful and worthy read. Green's obviously got a lot to say about the current state of internet, fame, media, and global attention. He doesn't stuff it down your throat, but uses it to shift his story forwards.

\n

AART follows April May, a young twenty-something art graduate living in New York, who's thrust into international fame after she stumbles across a giant metallic samurai-like sculpture who she calls Carl, in the streets of New York. Pretty soon April, and then everyone she comes into contact with, start having the same dream every night: they 'awaken' in a giant uncanny-valley city, full of riddles and puzzles that feel like they were made by an AI who sucked information out of Wikipedia. We follow, from a first-person perspective, as April is thrust into international recognition and fame, as she tries to solve the mystery of the Carls, and facilitate international cooperation against a potential threat from outer space. It's pretty fantastic when you spell it out.

\n

The thing about basically-instant fame thrust upon \"normal\" people is that they're completely unequipped to deal with it. The first-person narrative in AART does an excellent job of showcasing this, even if April's flaws are show-ponied in front of us sometimes. We get a good sense that reality, society, and her friends are warping in front of her. They may appear close or present, but they often feel out of reach, or beyond influence - as the person April was transitions into the idea or figure or character of April. Green does a good job of fleshing out the characters who stay in a relatively tight orbit of April, and doesn't parade a seemingly endless number of characters. He directs your attention to those who are important, and signposts clearly when someone's just passing through.

\n

As the book goes on, the relationships become increasingly dominated by their dependence on April and the entire Carl phenomena to define them. In some places, peripheral characters' strengths and capacities are a little superficial or passed over. For example one of the characters spins up something like an entire tech start-up within weeks/months, and it's just sidelined as a narrative tool to push the story forwards. Other characters fall a little flat and only appear when they need to do something for April, even though their friendship pre-dates The Carls. Rarely does anyone else show weakness or signs of struggling. Sure, April becomes increasingly self centred, and it might be hard to force these details into the story, but I noted their absence.

\n

However I find myself forgiving a lot of these flaws in characterisation and narrative in favour of an extremely compelling story. This book was an adventure, really. There were clues and puzzles to solve, a well established villain and tight pressure from them, and at least two moments which shocked me in their unpredictable-ness. The pacing escalated well throughout the book and maintained itself nicely, and the book didn't outstay its welcome. It is a relatively short read, and there's always something happening.

\n

The world is pretty much a modern day (2020s) America, with the exception of a woman president which, look, actually including Trump in this novel would have been an awful idea. There's a nice inclusion of both internet and portable technology, which is refreshing - it seems almost inconceivable to me that a book about a 20-something woman from New York wouldn't have a ton of group chats. Green utilises this in the way we do in real life - it's not a thing, it's just a tool that the characters use.

\n

Green clearly understands the modern world at both a macro and a micro level. He understands how people talk to each other, how 'traditional' and 'modern' media are in tension with each other, how the western world spends its attention, and how we conflate infamy and expertise. These kinds of critiques and commentaries are placed nicely within a Sci Fi-ish adventure, and never showcased explicitly. It becomes a high-resolution and completely believable backdrop to a more fantastic story. The book doesn't try to over-reach in those regards.

\n

As someone who doesn't read a lot of Sci Fi, and who hasn't read a lot of Young Adult recently (as vague as the YA genre is), I enjoyed reading this book. It immediately left me wanting to pick up the sequel, if not for the poetic writing or poignant philosophy, for the compelling plot. When I read cheaper/junkier crime novels I'm often left feeling a little embarrassed or like I should go read something \"real\". That wasn't the case with this book. I was invested in what was happening, so yeah it's a good book 3.5\u2b50

", "slug": "an-absolutely-remarkable-thing"}, "utopia-avenue": {"title": "Utopia Avenue", "author": "David Mitchell", "date": "2021-02-09T00:00:00", "book_review": true, "preview": "_Utopia Avenue_ is David Mitchell's latest piece of fiction in the meta-novel he is writing. Which is to say this book is set in the same mild-fantasy universe as several of his ot", "content": "

Utopia Avenue is David Mitchell's latest piece of fiction in the meta-novel he is writing. Which is to say this book is set in the same mild-fantasy universe as several of his others. It follows the motley crew of musicians and management which form the titular rock/folk/pop band in London in 1967, including cameos from near every famous London-based musician of the time. I've no strong attachment to the era or to early rock-n-roll music and the book never relied on nostalgia or knowledge. Mitchell does a fine job of creating a sense of a time of social and artistic revolution. Maybe it's because I read it eleven months into a global pandemic, but man... he really sold it to me. Despite the often dark and sometimes fantastical undertones of this book, it is foremost about people and their relationships. Romantic, platonic, and professional relationships to each other. Our connection to ideals and philosophies through the art that we make and consume (\"appreciate\" sounds less destructive but also less intense) and how that connects individuals to groups to societies. So I guess this is a book about... everything?

\n

This need to balance stories and dynamics at the individual, ideal, and population/crowd level is tough. It's a lot of plates to keep spinning. Or to mix metaphors it's a lot of cattle to herd. Mitchell mostly does a fine job, but every now and then somebody, some strand, some mention gets left behind and is picked up later, occasionally with a feeling of curtesy over curiosity. Giving space and attention to certain characters often rewards us, looking at you Jasper - you enigmatic guitar prodigy who spent time in a psych ward. Other times, characters flit between cast and side-character. At times, certain narratives felt simplified or condensed.

\n

These possible shortcomings are redressed by the weaving of Utopia Avenue into Mitchell's broader shared universe. The supernatural-cum-fantastical elements in this book are rewarding in their subtleties, unanswered-ness, and existential consequences. Utopia Avenue is a book which left me with a sense of animism: that the world is alive. That the separation of human, world, soul, and other aren't as strict as we see them here in the west. It's the same feeling that Studio Ghibli films leave me with, and it is one which is uncommon in western media. Little surprise, then, that Mitchell's wife (Keiko Yoshida) is a native Japanese speaker, and they met in Hiroshima. I've not done the requisite research to attribute these things together, however, maybe Mitchell was like this anyway and that's why he's so drawn to the Japanese culture. I digress.

\n

The final act of Utopia Avenue is as mystifying and bewitching. A feat it shares with Bone Clocks, Mitchell's 2014 novel. What I love dearly is both the magical elements, and how carefully they are placed and rationed, so that nothing can simply be dismissed as \u2728magic\u2728.

\n

The book feels optimistic about humans, and about our ability to create for and inspire one and other. This quality is what draws me endlessly to John Green, who has entirely nothing to do with this book or David Mitchell but who proudly beats the same optimistic tune over a din of (not unreasonable) pessimism. One, perhaps forced and on-the-nose, moment has the aforementioned Jasper (or possibly Mitchell, through Jasper) consider aloud in front of a press conference if music can change the world:

\n
\n

Which begs a question. \u201cWho or what influences the minds of the people who change the world?\u201d My answer is \u201cIdeas and feelings.\u201d Which begs a question. \u201cWhere do ideas and feelings originate?\u201d My answer is, \u201cOthers. One\u2019s heart and mind. The press. The arts. Stories. Last, but not least, songs.\u201d Songs. Songs, like dandelion seeds, billowing across space and time.

\n
\n

Despite adoring Bone Clocks, I really struggled to get into Cloud Atlas (2004). But Utopia Avenue has reminded me of what I loved so much about Mitchell, and also how many of his books I have not read (six). Leaving a book feeling excited to read the author's existing body of work, despite previously failed attempts, is one of the finest endorsements of a book I can think of. Unfortunately it is a purely quantitative, personal review which isn't so translatable to others, but it is symptomatic. This book delivers worthwhile ideas with an unusually captivating language.

\n

So I hope you read this book and it reminds you of the wonder of the world. Of the joys of creativity and human connection, and of how you can bend genres because they're there to serve curators not creators. Even if you've read all Mitchell's work and hate it (but still find yourself here) then I don't know what I could say to dissuade you. 4.5\u2b50

", "slug": "utopia-avenue"}, "after": {"title": "After", "author": "Dr Bruce Greyson", "date": "2021-05-05T00:00:00", "book_review": true, "preview": "**Declaration of interest** I am a spiritual person. I didn\u2019t come into this book desperately seeking answers, or in need of comfort or certainty. You\u2019re never going to get that fr", "content": "

Declaration of interest I am a spiritual person. I didn\u2019t come into this book desperately seeking answers, or in need of comfort or certainty. You\u2019re never going to get that from any book, I\u2019m afraid. I believe that we are not just our bodies, and that consciousness exists (at least partially) separately to the brain. I came into this book because I was interested in hearing the experiences of a healthcare and scientific professional, and how they experience / grapple with these questions. And to hear from people who had almost died. That sounds pretty cool.

\n

Death, as we know, is the only inevitable thing in our life that isn\u2019t taxes. But people seem to spend a great deal more time and attention trying to cheat or bemoan taxes.

\n

After: A Doctor Explores What Near-Death Experiences Reveal About Life and Beyond makes you think about death. Barely two pages pass where Greyson isn\u2019t telling us about a patient they saw who nearly died in some morbidly unique way. All throughout, Greyson approaches the subject of near death experiences (NDEs) as a practiced researcher and medical professional, and in doing so does what all good authors do: places their subject matter bang in the centre of something much larger. Death, living, almost dying, trauma, spirituality, and our relationships with ourselves, our families, and our mortality all come up. And while questions about the experience and impact of NDEs on someone\u2019s life comes relatively answered, these broader questions about how we live are left open.

\n

At its core, however, it is a book about NDEs. So let\u2019s talk about that first.

\n

Near death experiences are experiences that people have when they almost die. In some cases they do actually clinically die, but they eventually come back. The experiences themselves are vivid, and people who have them can tell them apart from dreams. Apparently they\u2019re not quite like anything else. The term NDE was coined 1975 with Raymond Moody\u2019s Life After Life, though reports of NDE-like events predate this. It has remained active grounds for research by people involved across neuroscience to philosophy and anthropology.

\n

Current research suggests that some 10-15% of people who almost die experience NDEs. They are present across cultures, religious/spiritual beliefs, ages, and lifestyles. Greyson takes us through the building block questions like \u201cwhat is an NDE?\u201d and why they\u2019re worth studying. We get an overview of a few common characteristics: from the relatively innocuous change in time perception and clarity of thought, to seeing one\u2019s body from from outside your self, the \u201clife review\u201d (the addled phrase \u201cmy life flashed before my eyes\u201d), and meeting and interacting with deceased people.

\n

We are well-guided (though perhaps a little briefly) through the process of an NDE. From its immediate characteristics, to how it changes people in the weeks and years which follow. People who experience NDEs often live a different life after their experience, compared to those who almost died but did not have them. Sometimes they can cause conflict if the experience doesn\u2019t conform to somebody\u2019s pre-existing spiritual beliefs. In general, NDEs seem to be a force for good - leading people to live more patient and compassionate lives.

\n

This is a well structured non-fiction book. Any aspiring non-fiction writer would do well to pay attention to Greyson\u2019s ability to plant the seeds of one question in one chapter, and then answer it promptly in the next. In some cases he points at something he\u2019s just said and them tells you he\u2019ll clarify it much later. You\u2019re never left wondering about things - Greyson has clearly guided many a novice down this garden path. This makes for an engaging read, one that you could burn through.

\n

At times it is a little frustrating that the evidence seems to be \u201cI met Jane who almost died, and here\u2019s what she reported\u2026 I met Alex who almost died and they said\u2026\u201d. However, this does provide more personable that a table or chart might not. Still, it would have been nice to have a bit more formalisation.

\n

In fact the entire book seems to work hard to directly avoid an academic tone. Rigour is very clearly cut off in favour of conversation and engagement. We get glimpses into the fact that Greyson obviously has a wealth of experience in dealing with NDEs and their consequences on others. However, I never got the sense that he had truly mastered the gnarlier corners of the field, or was attempting to push the shape of research forward from a collection of personal testimonies.

\n

Depth is sacrificed for breadth in this book, even to the extent where I wonder if Greyson\u2019s success can be attributed more to the impact and consequences of his patients\u2019 experiences than to him as an individual or researcher. I get the sense he might give an excellent hour long seminar, or be lively company at a dinner party, but rather less that he fulfils the detail-oriented academic air. I suspect at least in part that this is because he has less literature to delve through, join together, or refute. He is a story teller, a founding father with a vision of a new nation. He is not a civil servant sorting through the minutia of allocating land and settling legal disputes.

\n

At the same time, the only way that you\u2019ll get a sense for the actual experience of an NDE is if you hear them spoken about. You can hear \u201cout of body experience\u201d and not think about it too much. These are loaded, emotionally- or spiritually-charged terms, for me at least. Having three or four concrete examples, each with undeniably odd situations around them (like noticing the state of someone\u2019s attire while dead and having your eyes covered) does a better job at making you confront these experiences. I don\u2019t think the same could be achieved with the cool, polished marble of figures and numbers.

\n

This becomes even more important when people talk about experiences which step past both our every-day lived experience, and the capacity of our language to communicate ideas.

\n

It is here that we depart the actual topic of the book, and start talking about the meta aspects. It is here that Greyson is able to throw out half a dozen or observations about medical and scientific research, each fundamental to the way we conduct, review, and communicate research. In short - all very interesting ideas. Certainly they are not ideas to adopt wholesale. This won\u2019t be the book that topples the peer-reviewed, double blind study, but it\u2019s a step towards there.

\n

The most interesting question this book raises isn\u2019t \u201cwhat happens when we die?\u201d it is \u201cwhat is evidence?\u201d. Greyson works in the gate-kept, largely conforming and heterogeneous landscape of academic research. The focus for many practitioners is on getting enough published research out to justify their positions and move towards promotion and tenure. It is not in their interest, really, to rock the boat too heavily. It is a much wiser choice to make sure your research looks, broadly, as it is meant to look, which means it looks like everybody else\u2019s, and like everything that came before it.

\n

This is not the most effective way to study every part of the human experience. If you hold NDE experience to the same standard as a vaccine trial (double-blind gold standard control), you will never get any data or information. From that stand point, NDEs simply do not exist.

\n

With the prevailing attitude that NDEs do not exist, if you almost died (especially if you tried to take your own life), and you experienced going someplace else and meeting your deceased grandparents or parents, would you tell the doctors around you what happened? Nope, you\u2019d probably stay quiet and maybe tell one other person in your life. Because NDEs do not exist, and there are no vehicles to get your NDE story outside of yourself.

\n

You would be worried the doctors would think you crazy, or judge you, and not listen. There\u2019s a high chance they\u2019d diagnose you with some kind of psychotic episode and maybe keep you in hospital longer. You would have gone through two very impactful events in your life (nearly dying, then having an NDE) and you will have no professional support to guide you through processing these and integrating them into your life.

\n

The healthcare professionals made sure the mechanics of your body wouldn\u2019t fail, and then sent you off. This is not the gold standard, end-goal of medical care. The question of \u201cwhat is data\u201d is not just a philosophical one, it is one which impacts us and our healthcare system.

\n

Greyson makes a very convincing case for a human- and experience-centric approach to research. Both in the design of experiments and the consideration of publication. There is no point in doing research if it cannot be effectively conducted, reviewed, and published. If the standards for conducting, reviewing, and publishing research remain narrow, then only some kinds of studies will be published. Or things will be studied with inappropriate methods, because they suit the medium (research) not the subject (NDEs).

\n

Research should push our collective understanding forward, and medical research should (eventually) result in better care. To support people who have NDEs, regardless of what you think they actually are, you need to understand them. To understand them, you need to be flexible in how you collect data about them. We need peoples\u2019 testimonies and experiences to be treated as sacredly as though the were field observation or computational data.

\n

Even if you don\u2019t care the slightest about the spiritual or moral implications of this book, read it. You might think it all poppycock, but it\u2019s a well told poppycock. Perhaps the strokes are too-broad and the author too American, but this is a good, accessible non-fiction book that raises more insightful points about our (the West\u2019s) approach to healthcare and wellbeing.

", "slug": "after"}, "magician": {"title": "Magician", "author": "Raymond E. Feist", "date": "2021-03-15T00:00:00", "book_review": true, "preview": "The first in Feist's *Riftwar Saga*, Magician has the air of a pulp fantasy novel. First published, abridged, in 1982 and unabridged a decade later, this book oozes nerds in the '", "content": "

The first in Feist's Riftwar Saga, Magician has the air of a pulp fantasy novel. First published, abridged, in 1982 and unabridged a decade later, this book oozes nerds in the '70s playing D&D and I love that. It has it's bona fides as a fantasy novel and that's what made me pick it up in the first place. Unfortunately, I could never find myself truly getting into Magician in a way that I have with more contemporary fantasy series (like Brent Week's Lightbringer, or Peter V. Brett's Demon Cycle). The piece was paced oddly, the characters undeveloped and shallow, and as a whole it felt too broad and unfocused. There's a fine line between telling an epic story with a sense of something larger than what the reader is being shown, and having an author move endlessly along a chain of \"and then\"s. Unfortunately, this series hit the wrong side of that line and I was never given anything good enough to forgive it.

\n

The book starts with two boys (one orphaned, naturally) growing up in a medieval-setting fantasy castle. I expected us to stay there a lot longer, a la Robin Hobb's Assassin's Apprentice series (a 4\u2b50 series btw). Strong but clich\u00e9 start. Almost immediately Feist whisks us off somewhere else, and before long we've covered seemingly large spaces of time and personal development in just a few chapters. This might speed up the pacing, but when you're writing fantasy you have to educate your readers, which is why \"undiscovered genius\" is a common and useful trope in fantasy: our protagonist can learn about the world with us, but do all the hard work (like studying for all those pesky magic exams). Instead, Feist introduces Pug and Tomas (our young keep boys) just before they start their apprenticeships and then comes back to them years later in the middle of their studies. We're not much wiser about their day-to-day lives, their skills, their character development. Later we spend seemingly endless pages on board a boat with characters who phase in-and-out of importance, and then maybe a dozen pages are given to Pug after he has his memory wiped and goes through an entirely new magic training in a parallel world. The pacing was way off - I could never infer importance from length or attention.

\n

This isn't even a review about Feist's book anymore. I don't want to spend time dissecting what I don't like about something if it doesn't lead to a productive understanding about what I do like, and how it could be better. Unfortunately I just don't think I like this kind of book. That also means I did not like this book very much, which is a shame because it seems like such a beloved classic.

\n

But I do like fantasy. So let me explain to you why both these things are true.

\n

There is a feeling that Feist has already go to the end of this book and is relaying it to you, almost haphazardly in the pub when really you'd rather be talking to the cute boy or girl you've been making eyes with. Good storytelling is joint discovery, you and the story teller are stumbling across things, surprising things, unexpected things, at the same time. Feist's writing in this book lacks that feeling, and it's a shame. A good plot, a rich political ecosystem, an interesting magic system are the core ingredients to a good fantasy epic, but there's nothing holding them together. Croissants might just be butter, flour, yeast, and milk but so are a lot of things - the art is in the mixing and waiting.

\n

As much as I want to love good old pulp fantasy, I don't know how much I actually enjoy it. A lot of my favourite fantasy series are more modern. It's only a forty-year gap, in the scheme of writing it's really not that long. Orwell's 1984 was published over seventy years ago, Steinbeck's East of Eden a few years after that, and Atwood's The Handmaids Tale a few years subsequent. All books that remain remarkably readable and excellently rich for modern readers.

\n

Reading this book acted more as a counter point for contemporary fantasy (things published in the last 10-15 years). Fantasy has become less of a distinct entity, separate from fiction. Writing fantasy isn't a necessarily a decision about niche or genre, it is a stylistic or world-building aspect. Sure, some modern writers are going deep on the epic and high fantasy (see: GRRM), but a lot of others are writing good books, with crafted characters, set in a world that has magic and swords and dragons. And that's great, I love swords, and magic, and taverns.

\n

More people can write and publish their books, and more people can find and access them. The barriers to everyone in this equation have gone down, and the result hasn't been the dilution of quality we probably feared it would be forty years ago. This means that if I want to read a book about men who make potions or women who can make magical illusions with their art, I don't have to pick the writer just because they're a fantasy writer.

\n

I like good books first, and fantasy second. I love good books written in a fantasy setting, but I (personally) cannot forgive a bad book because its characters inhabit a world where there is magic. No matter how well explored the consequences, or certain aspects of the political and economic ramifications of there being magicians.

\n

With so many new, creative voices in fantasy, many of who are women and People of Colour, I would rather spend my time exploring what's new in the genre. Our attention and our conversations are two of the best tools that we have to make meaning and change with out brief lives on earth, and I think those things are better spent on emerging and under-represented artists (if I was made to chose, which I am not).

\n

I'm glad I read a classic of the genre, but not because of the book itself - rather to get a better lay of the land. I'm glad I read it but I won't be reading the rest of the series. 1.5\u2b50

", "slug": "magician"}, "the-silence-of-the-girls": {"title": "The Silence of the Girls", "author": "Pat Barker", "date": "2021-01-24T00:00:00", "book_review": true, "preview": "Pat Barker's take on the classic story of the Battle of Troy is told from the perspective of Briseis, the noble taken slave when Achilles sacks Lyrnessus. Consigned to life as a be", "content": "

Pat Barker's take on the classic story of the Battle of Troy is told from the perspective of Briseis, the noble taken slave when Achilles sacks Lyrnessus. Consigned to life as a bed slave for Achilles, she is later taken from Achilles by Agamemnon, which in turn causes Achilles to stop fighting for the Greeks. In the tradition of classic epic poems like the Iliad, women and slaves are treated entirely as property - not as humans. By re-telling a classic from this previously unconsidered, almost inanimate, point of view Barker is able to shift away the dignity and majesty that normally tint classic or epic poems. Barker's retelling is not quite a reimagining, but she does a wonderful job of maintaining focus on the broken societies and individuals involved in the story, and of just how crude things would have been during the seige on Troy.

\n

Barker does a superb job of describing the setting: a war camp set up between a battlefield, Troy, and the ocean. Each of these settings are essential to the themes which run through the book: the idyll and treasures of war, and Achilles' own divine connection to the ocean (his mother, Thetis, was a Neried - a sea nymph). Barker describes the war camp as something which straddles permanence, as a home for many soldiers and the supporting staff and slaves, and the temporary make-shift encampment. Her descriptive prose are never indulgent, but over the course of the book they beat out an immediate world. The use of small comments are often the quick assessing glances of characters gives the entire book a great sense of place.

\n

Briseis experiences the world around her immediately, but the events and beats of the plot often have to come to her. Word is brought, or she sees the consequences of battles and political manoeuvres. Her situation inside the house and bedroom of Achilles offers some nice speculation about what we don't see in the original epic poems. This small scale, domestic focus carries heavily throughout the book, and brings a sense of intimacy to Achilles and his inner circle. It brings pangs of sympathy for Briseis' own struggles as a woman taken from her life, moved from nobility to slave, and as witness to relentless violence.

\n

The result is a story that keeps its pace up right up until the 80-90% mark. Towards the end, things really drift off, and I couldn't get a clear sense if Barker was trying to wrap things up or leave them open. The Silence of the Girls breaks the strict narrative structure of the original epic source material, that attempting to break form makes sense. I just didn't get a sense of commitment to this idea, which so I found the ending a little disappointing.

\n

I was worried that Briseis would remain a victim to circumstance. That as a woman and a slave, I would commit three hundred pages to someone simply experiencing and coping with the world. This is a poignant part of the story, and not one I would want to be glanced over. Barker acknowledges it but doesn't overdo it. At times our narrators fears feel a little repetitive, and without any real bite, but she's fleshed out. I am always wary of books which adopt a diary or confessional style, which this one does. However it doesn't get in the way.

\n

At times the pragmatism and frankness of her writing leave me wanting more. I always wanted a little bit more presence, a bit more flesh on the bones. The story is told almost entirely from the first person perspective, and it feels a little constrained by that, at times. This is entirely a personal preference, and Barker's style is consistent throughout. It just grated on me.

\n

This doesn't get in the way of exploring the world or the themes, however. Personal and violent trauma is explored carefully and with respect. We see Achilles, and other great characters portrayed with more humanity and dimensions that the typical archetypes they can become. From the opening sentence of the novel, \"Great Achilles, brilliant Achilles, shining Achilles, godlike Achilles... how the epithets pile up\", you know this is going to be tackled. And it is. The reimagining of a more human, faulted, prideful and unloved Achilles comes through.

\n

The themes were interesting, but delivered a little plainly. Nothing struck me suddenly, and little specific details or phrasing stays with me. Perhaps the book is too human and not godlike or mythical enough for my personal taste. What the narrative or style lack is made up for easily in the sturdy telling of a classic story. 3\u2b50

", "slug": "the-silence-of-the-girls"}, "sistersong": {"title": "Sistersong", "author": "Lucy Holland", "date": "2021-06-13T00:00:00", "book_review": true, "preview": "_Sistersong_ is the debut novel from Lucy Holland. Set in Dumnonia, the Celtic kingdom which lasted between the 4th-8th century in what is now South West England, it follows the th", "content": "

Sistersong is the debut novel from Lucy Holland. Set in Dumnonia, the Celtic kingdom which lasted between the 4th-8th century in what is now South West England, it follows the three children of the king (introduced as Riva, Synne, and Keyne), as they come of age and start to see the word \u201cas it is\u201d.

\n

The world now is far from the one the siblings grew up in. Threatened by the surrounding Saxons, losing connection to the land\u2019s magic, and waining religious beliefs all give this book an excellent backdrop. The world that Holland constructs (and the people she puts in it) are granular and realised. Holland believes a world into being, almost effortlessly. Dialog never feels forced, and the relationships between the siblings are rendered wonderfully.

\n

\u201cFantasy\u201d literature is a broad scope, and books like Sistersong do it justice by creating these complex, real characters. Although the book is set in an historical-fantasy setting, it is just a setting. I don\u2019t think I\u2019ve read a book that gives such, almost casual, voice to figures who might otherwise be voiceless. The prominence of trans, or gender identity, themes in this book came across as far more important than anything else. But still, other elements and people and their relationships come through.

\n

Yeah, there\u2019s magic, but even if there\u2019s magic there\u2019s still siblings who argue, and parents who don\u2019t accept when their children grow up, and men who only want one thing (sex). I would have a hard time putting this book into any particular genre

\n

Despite this excellent character work and writing, the pacing was off for me. The first and last third of the book felt right: things moved along at the right pace. Though I definitely felt the book swerve after maybe 100 pages. I feel like a certain pathway for the plot was set up, and then we just hopped over to another story. This felt jarring.

\n

The middle third felt a little aimless at times, and without more of the world to investigate, or seeing things change, it felt like a slog to get through. The world painted is pretty bleak: the weather isn\u2019t great, there\u2019s a threat of a foreign invasion, and there\u2019s generally a lot of mistrust. I don\u2019t know if Holland is trying to create this feeling of claustrophobia or fear, but it\u2019s all tension with no real consequence. It\u2019s exaggerated by the more focused chapters on either side. For a long time\u2026 nothing happens.

\n

Removing content from a creative project is hard. Especially when you spent ages making it. I think this book could have benefited from a bit more even pacing, and more ruthless copy editor.

\n

Then again, maybe Holland wanted a book driven entirely by character, where plot is just a thing that happens in the background. That\u2019s a fine aspiration, but it didn\u2019t feel consistent.

\n

Despite that, I enjoyed the themes: family, relationships, coming of age, and identity. They\u2019re themes that are strong in our oldest stories and ballads as humans, and they\u2019re as relatable now as they\u2019ve ever been (apparently). Holland his tried to give new depth or new voice to an existing story - and has done so without being preachy, or really without making it a thing.

\n

Read this book. 3.5 \u2b50

", "slug": "sistersong"}, "first-you-write-a-sentence": {"title": "First You Write a Sentence", "author": "Joe Moran", "date": "2021-02-04T00:00:00", "book_review": true, "preview": "I loved this book. _Will_ love this book again, because I know I'm going to read it again. And then probably again after that. Moran's two hundred page treatise on the process of w", "content": "

I loved this book. Will love this book again, because I know I'm going to read it again. And then probably again after that. Moran's two hundred page treatise on the process of writing and re-writing is meatier than you would expect. Every few pages serve you a meal, a new way to think about reading or writing: how active is the voice? Remember punctuation? Does this make sense? Moran shows you the importance of these questions, and the consequences of (not) adhering to them. I think this book does a superb job at explaining and dissecting written communication which, like a lot of human rules, are real but unspoken. It's not a dry style guide. Moran appeals to emotion and common sense to make his points, peppering his rationale with quotes and examples. More people should read this book, even if they \"only\" write e-mails, press-releases, statements, love letters, long instagram captions, or anything else longer than a few sentences.

\n

The thesis running through this book sounds something like \"consider your sentences carefully and you'll probably write better\". Although the book zooms in (to grammar, and Part of Speech) and out (to paragraphs and narratives) it always returns home, to sentences. A good essay, to me, draws your full attention to something overlooked or undervalued, but which is full of life and worthy of consideration. Examine something and, invariably, you'll see beauty or beauty reflected. Fortunately, a good sentence doesn't hide its reward behind expertise or mental gymnastics. Sentences can be intuitively seen as good or bad, and your reader will be judging them. The pleasing-ness of a particularly rhythmic, expressive, or concise sentence is something most readers would notice. Stephen King reportedly wrote The Gunslinger, his magnum opus, from the first sentence: \"The man in black fled across the desert, and the gunslinger followed\", one of the finer opening lines. So by considering the quality of our sentences, we begin to improve our writing from the grass-roots up.

\n

Writing a book on how to write must be daunting. You're describing a medium in that medium, so you've got nowhere to hide. By the end of the first chapter I was convinced that Moran had enough craft and flare to keep me invested, and that feeling didn't change. This is the first Moran book I have read, however, so I cannot speak for the quality of his entire portfolio. There's some truth to \"those who cannot do, teach\", but any trace of that is scent is overpowered by the waves of unconditional passion for writing and language that roll off this work. Moran fulfils the eccentric-university-lecturer stereotype we often see more in American media (we quite like grizzled and pessimistic educators here). There are times when you can hear him delivering these ideas in front of a whiteboard in a room built and decorated in the sixties, complete with grey-blue-black worn carpet. He's informed enough to be useful, and impassioned enough to make sure you know exactly why you're being taught something. The ideal traits of a Higher Education educator, which Moran is.

\n

The book is set out across seven chapters, though each chapter is almost self-contained. The book moves from a general introduction of the book's thesis, to the more detailed grammatical and linguistic specifics, before opening back up to the implications and power of a good sentence. This seems like a sensible structure, it's possible to come back to the forty or fifty pages at a later date, and dig into something again. However, even at only two hundred pages long, it does make certain passages or ideas hard to re-find. This is a problem easily remedied by scribbled underlinings and notes in the margin, but it is frustrating if you want to revisit something but aren't sure where exactly it is. I suppose this is the price of a more intuitive, rather than ontological structure for the book. The book is narrow in scope - the chapters aren't vastly different enough to be truly distinguishable. Each chapter is a meal best enjoyed whole, and not in bits. Even so, I would recommend no more than a chapter a day - a lot of these ideas need time to percolate.

\n

Moran strikes a difficult balance here: does he act as provost for platitudes, which the reader must take and apply as she sees fit, or does he provide us with the certainty of syntax, edge-cases, and rules. Too far into generalities and you're not actually offering anything useful, and you risk sounding self-aggrandising and vague. Too far into the specifics you've lost the more creative, or fresher, crowds. Reading, and to a lesser extent writing, are intuitive acts - by waylaying out readers and writers with rules, you're sucking the joy out of the acts. The best way I can can describe the effect of reading this book is the introduction of a little voice at the back of my head whenever I am writing, and sometimes when I am reading. The little voice chirps along to Moran's ideas of good writing: that we can't assume the reader is interested or invested, we must explain ourselves, we can use active voice, sentence length, and order of clauses (claus-der?) to make sentences clearer. Or conversely we could use our new found powers to obscure and bore.

\n

Broader than that, Moran has given me an appreciation for the sentence. I wouldn't be so bold as to say I'm never going to write a mediocre or bad sentence again in my life. That's obviously going to happen, probably daily. But when I put the book down (surprisingly long after I picked it up), I felt convinced that no single sentence should go into my writing un-interrogated. The sentence might not actually be the purest, platonic ideal of writing, but it's important. At the meta-level, I adore the careful consideration of something so singular. The result tells you about the object of study and the person doing the studying, so this book packs twice the delight. Learning the process is more actionable than learning the product. The result is one of the clearest, most actionable, and impassioned calls for better writing from someone who just wants there to be better writing. 4.5\u2b50

", "slug": "first-you-write-a-sentence"}, "once-upon-a-river": {"title": "Once Upon a River", "author": "Diane Setterfield", "date": "2021-04-04T00:00:00", "book_review": true, "preview": "This is a lovely book where classically fairy tale things happen. Set on the River Thames in Oxford around the turn of the 20th century, it follows individuals and families as a gi", "content": "

This is a lovely book where classically fairy tale things happen. Set on the River Thames in Oxford around the turn of the 20th century, it follows individuals and families as a girl is found not-quite-dead in the river. Everybody sees somebody different in this child, they see the lost daughter they wished they could re-find, or the lost sibling who died some thirty years ago. We follow the people of the village as they attempt to care for, claim stewardship over, and make counter-claims about her. This otherworldly, captivating child precipitates the best and the worst parts of our characters and their pasts.

\n

I\u2019ve been describing Setterfield\u2019s book as \u201cfairytales for grownups\u201d which sounds like a good description to me, but I\u2019m also worried it\u2019s a little dismissive. So please interpret it generously. This book made me feel like stories made me feel when I was younger: something wholly separate from real life. Something that I enjoy living in.

\n

The book opens on a pub somewhere along the Thames, near Oxford, where the local townsfolk gather to tell and hear stories. As beginnings go it\u2019s only a few steps over \u201conce upon a time\u201d but it works. It sets the tone and the expectation: this is a capital-S Story . And by knowing itself, its medium, and its limits, Setterfield gives us permission to get utterly lost and captivated in it.

\n

A difference, though, between this book and an actual fairytale is how it weaves in and out of fantastical elements. You can read it most literally as a piece of historical fiction, or more fantastically as a piece of light urban-fantasy set in the past.

\n

The core of the story is people: the big cycles of life and death, and the smaller infinite little plots that make up our lives, our families, and our communities. This book never loses focus on the individuals, which reminds me of Ken Follett\u2019s Kingsbridge series of novels. At times, the characters seem villainously evil and heroically chivalrous or noble, but archetypes have a place in stories.

\n

Each character seems a little reduced to one trait which dictates everything they do: maternal love, selfish greed, parental guilt, financial gain. It\u2019s a story about people, but those people seem a little simplified at times.

\n

Still, I love a character-focused book. I love going page-to-page asking how would people like this react in a situation like that? Like a fairytale, it\u2019s analogous to life: it gives us tools to recognise and understand the actions of people around us, and Setterfield does this well.

\n

So I mean it in no belittling way when I say that Once Upon A River is a lovely book.

\n

It doesn\u2019t try to introduce new ideas, cunning literary devices, or poetic prose. Sometimes you need this no-nonsense \u201cimagine these people doing these things\u201d story.

\n

There are still moments of gentle beauty and fantastical elements. The language is florally embellished in places, as if it were a well-crafted tale being told aloud to you in a pub in the early 1900s. It\u2019s never self-indulgent, either - the language or words never distract or get in the way.

\n

There are certainly a few times where characters seem to transform or shift in a moment. It\u2019s like they were vehicles towards the resolution of the story: for there to be a happy ending they must accept that this child isn\u2019t their daughter, or to be in love one must let their fears go. I did take particular issue with one character who, for very personal and rational reasons, decided that she did not want to have a child - but abandoned those beliefs when she met the right man. A narrative that queer/asexual and anti-children people often face. The \u201cyou just haven\u2019t met the right man\u201d argument. It maybe would have been nice for the woman to not want children and realise it\u2019s because she wasn\u2019t maternal, or maybe was queer - and resolve the story that way. Setterfield had the chance to break an expectation or convention yet still fulfil a fairytale ending, sort of like a genie, but instead she took the predictable and easy route. But I can\u2019t criticise a book too harshly for wanting to stick to what\u2019s already known, and for sticking to its genre. Still, its a missed chance for more representation.

\n

On some deeper level, I think having the characters change so quickly is a nice reminder that sometimes we need to only give ourselves permission to change our beliefs or our action. But I think I\u2019m looking into that a bit too much.

\n

It was a nice read, a nice escapism read. It\u2019s a book I\u2019m going to remember because of how it made me feel, not because of the characters or writing. A good solid read for when you need something palatable and easily digestible. 3 \u2b50

", "slug": "once-upon-a-river"}, "cats-cradle": {"title": "Cat's Cradle", "author": "Kurt Vonnegut", "date": "2020-10-03T00:00:00", "book_review": true, "preview": "After _Slaughterhouse 5_, _Cat's Cradle_ is the second Vonnegut book I've read. I've heard wonderful things about Vonnegut, and this book exemplifies a lot of those, namely uncomfo", "content": "

After Slaughterhouse 5, Cat's Cradle is the second Vonnegut book I've read. I've heard wonderful things about Vonnegut, and this book exemplifies a lot of those, namely uncomfortable observations and a black, dry humour. The book circles a number of themes, principally the dangers of purely objective or impersonal scientific research, and the role of religion to society and people. It hits these notes well throughout the piece, but I found the meandering, seemingly powerless, plot arch a little unstable at times - like there wasn't anything for me to reliably hold on to. Our narrator is very much at the whims of those around him, and feels more like a vehicle to show different things to the reader rather than a person.

\n

This lack of depth to our narrator could be purposeful - he is, after all, essentially writing a memoir which covers his (ultimately unsuccessful) attempt to write a biography of the Dr. Felix Hoenikker. Hoenikker is a scientist working on the creation of nuclear weapons, who is the classic absent-minded genius. Though fictional, Hoenikker is a semi-transparent copy of (the real) Irving Langmuir: the Nobel laureate who actually did once leave a tip for his wife after she prepared him breakfast at home.

\n

Hoenikker is dead, so we have to piece Hoenikker together from the testimonies of his children and people who knew him. We are presented a portrait of someone doing very dangerous work around nuclear weapons, but who cannot form or understand the most basic of relationships with even his immediate family. The placement of someone who is not aware of, let alone able to discuss, the moral implications of their possibly apocalyptic work is an undercurrent through the work. To be fair - it is an interesting note, it's easy to praise science for its own complexity, and forget the messiness of actually using it.

\n

From this setup, we get some moments which show moral indifference and ignorance as almost indistinguishable. Hoenikker's work is purely hypothetical to him and his kind, but globally important to the rest of the world. I have never had to struggle with in any of these questions in the real or immediate context (which I'm grateful for). It is fairly clear that the book was conceived in a place where the Arms Race and scientific research dominated the author's attention. Vonnegut clearly had to wrestle with these thoughts in a very applied setting. Historically and contextually, it is clear that this is a very important and well-timed book.

\n

The world and events which form around our narrator is often full of moments of black humour, of the absurd, of hypocrisy where all you could do is laugh. Which is, from what I hear, the realm of Vonnegut.

\n

Cats Cradle also throws us into the existential ocean with Bokonism - a fictional religion created by Vonnegut. The essence of Bokonism lies with foma - which are harmless untruths, and the related belief in some kind of predestination. Bokonism explores the genesis, adoption, and persecution of a religion - it's a very concise, sometimes oversimplified (though often for humour) examination of religion.

\n

Again, here Vonnegut finds the most bleak or despairing parts of humanity and you're forced to laugh at it, because the alternative to feel a bone-deep worry or despair.

\n

Unfortunately, these ideas weren't enough to carry me through the book. They could have been if I had found the narrator a bit more fleshed out, a bit less willing to just accept everything. He feels like an observer, like his role is just to document what's happening. He's a journalist/author writing a book, so it wouldn't be odd to pair these observations with some kind of cross-reference, anecdotes, fact-checks, or journalistic flair. He didn't subtract from the story, but he definitely didn't add anything to the book.

\n

While this fits with the helplessness/comfort of predestination from Bokonism, and it is indeed fun to piece together the life/thoughts of a person through what other people share about them - the narrative itself just didn't engage me. Maybe I've been ruined by expecting too much to happen in a plot, but I don't think that's true.

\n

I felt I could have stopped reading at any point and not wonder about what was going to happen next. Especially towards the end of the book things just get more and more absurd, but it's left to us, the readers, to notice this absurdity. Which is a nice touch, but at the same time there doesn't seem to be a ceiling or climax to how weird things can get. There's no tension or threat, it just keeps getting weirder. This is only really in the last 10-20% of the book - it's a real gear change.

\n

Admittedly, it has been a while since I have read a \"modern classic\", and so I wonder if I would have enjoyed this book a little more if I was better prepared, more critical, or more aware of the historical/personal context. I read it in 2020, a year when literature served more of an escapist purpose than academic exercise. Nevertheless, the book had enough interesting ideas and darkly funny moments, and was frankly short enough, that none of these became deal breakers. I'm glad I have read it, I just didn't particularly savour the reading. 2.5\u2b50

", "slug": "cats-cradle"}, "mrs-death-misses-death": {"title": "Mrs Death Misses Death", "author": "Salena Godden ", "date": "2021-04-17T00:00:00", "book_review": true, "preview": "Godden has been writing and performing poetry since she decided to move to London instead of going to university. \u201cGodden is a poet\u201d headlines my review because it is so evident in", "content": "

Godden has been writing and performing poetry since she decided to move to London instead of going to university. \u201cGodden is a poet\u201d headlines my review because it is so evident in every page of this book. Every transition from unknown narrator, to fourth-wall breaking direct address, to poetry, to \u201cnormal\u201d prose. Godden barely pays attention to consistency when she writes, because she is trying to get across an idea. All books are poor transcriptions of spoken word stories that buoyed humanity through tens of thousands of years, long before we invented written word, paper, and typesetting. This book just acknowledges that more than a lot of other books I have read.

\n

Mrs Death Misses Death was written almost entirely in service to an idea. Sometimes you\u2019re not sure what that idea is, and other times you\u2019re frustrated that it is just an idea, without resolution or arc, but most of the time you are spell-bound by how Godden writes. This is \u201cexactly the sort of thing you expect when a poet writes a novel\u201d, to quote Sara Collins in her review for The Guardian.

\n

This is all to say that Mrs Death Misses Death is interesting at a meta level. Perhaps more interesting than it is at the direct substantive level. The characters and story are secondary. The book is written by Wolf, a \u201cbi-gender\u201d young poet in London who meets death when she sells him some tobacco at a local store. Death, who has always been personified as male, tall, and slender, is shown here by Godden as a young, poor, black woman in London. Because this is the most overlooked, the least seen, kind of person. Wolf is captivated, maddeningly so, by Mrs Death, and Mrs Death is glad of the chance to speak to someone about the endless and laboured process of collecting souls as they leave life. Told in part by Wolf through testimony or flashbacks, sometimes in poems, other times from the perspective of Mrs Death - we explore this idea and the consequences of being or meeting death.

\n

The book was written over the past five years, long before anyone could identify a spike protein, face mask, or socially distanced funeral out of a lineup. It was written before death figures filled our every news report for months and months on end. It was written independently of contract, i.e. Godden was writing without obligation to a publisher, and this freedom shows. Humanity and experience, largely unfiltered or unguided, are at the centre of this book, and I don\u2019t think the same result could be achieved if it was rushed or shaped by the need to fulfil or attract external attention. Despite this \u201cbusiness ruins art\u201d talk, the book has already been snapped up for film or TV by Green Door Productions (a company owned by Idris Elba), as well as receiving generally favourable reviews. It\u2019s not an art-or-money situation.

\n

Despite liking the idea of this book, and broadly adoring the language and sentiment, I didn\u2019t find it entirely engaging or sticky. Whenever I was reading it, I enjoyed it, but I did not find myself coming back to it unintentionally. If you can, read this book in as few sittings as possible, I think.

\n

It is not a book where things happen, or where particular ideas are explored explicitly. It seems to follow a very brief period of time, a snapshot. We get glimpses of some of the things Mrs Death has to deal with, and the sadness and anger she feels as being seen as a man, and as being the opposite of life \u2014 but we never see that in action. We are with Wolf for the entire book, and Wolf is your classic unreliable narrator, and starving poet. We explore the tension between a childhood trauma caused by the early death of Wolf\u2019s mother and their subsequent upbringing by their bitter and probably cruel grandparents. This idea of intergenerational trauma was something that I loved in Queenie, but here it is not explored in as much length or detail.

\n

I am glad I read this book, especially as somebody who loves books and poetry. I love that it wasn\u2019t a \u201ctraditional\u201d book, and how Godden sees the world, or at least frames the world, in some interesting ways. The sentiment of grief and unresolved trauma runs consistently throughout this book, affecting both Wolf and Mrs Death, a supposedly other-worldly spirit or idea. It normalises the idea that death is a hard thing for those left alive to process. It treats that difficulty with patience and I hope lends sympathy and empathy. But there still weren\u2019t any moments which shone above all others in this book. I would recommend it to you if you love books and reading and language and ideas, but not if you love stories and characters. This from a man who can\u2019t sit easily through a Chekov or Pinter play though, so don\u2019t listen to me. \u2b503.5

", "slug": "mrs-death-misses-death"}, "how-do-we-know-were-doing-it-right": {"title": "how do we know we're doing it right?", "author": "Pandora Sykes", "date": "2020-09-20T00:00:00", "book_review": true, "preview": "Sykes' collection of essays covers a surprisingly large amount of ground for a relatively short book. She turns her attention to a lot of the inner turmoils that seem to plague mil", "content": "

Sykes' collection of essays covers a surprisingly large amount of ground for a relatively short book. She turns her attention to a lot of the inner turmoils that seem to plague millennials' inner monologues, as well as broader societal issues: fast fashion, the \"true self\", instagram husbands, and work-life balance all feature. How do we know we're doing it right? clearly comes from a lot of careful conversations, introspection, and research but at times Sykes seems to lose herself under disjointed quotations of other peoples' words. When she does start to connect others' research to her own opinion, the two feel a little disjointed, which is a shame because both raise good points worth discussing.

\n

I hadn't heard of Pandora Sykes before I saw this book in a local bookshop. I'm a sucker for strong feminist essayists, and also for buying books on a whim so I picked this up. It turns out this is Sykes' first collection of essays, though she's a seasoned editor, journalist, and broadcaster according to her own website.

\n

I was initially worried that I'd bought a well-written book aimed at a more female more middle-aged more parent audience. The first couple of chapters spoke about parenthood and domestic life, and the environmental and psychological toles of fast fashion. Both of these things are issues that we should all be aware of, regardless of our role as child guardian or garment buyer, but both aren't things I spend a lot of my time being affected by[^1]. Not to brag, but I have practically no children and I'm really trying to avoid shopping in H&M (or at least feeling appropriately guilty when I do). Though it was fun to have a well-spoken and funny woman complain about the state of a hypothetical husband and baby-daddy - some parts of the book definitely felt less relevant or less targeted at me. I could clearly see what was being said, I just couldn't relate.

\n

[^1]: Men can be equally as targeted by fashion marketing which preys on insecurities - fortunately the algorithms that serve us adverts never place them in front of me.

\n

And then something happened. Suddenly Sykes was talking my language: in talking about social media use and its effects on us, she spoke about her own very purposefully spent time unplugged not because it was \"so good\" or \"well balanced\" but because she recognised it's what she needs for her brain to function in a way that makes her happy. Not because she wants to humble-brag or shame others, but because genuinely it is the right choice for her. This is something I've had simmering at the back of my brain for a while: that the inner monologue a lot of creatives rely on is being pushed aside for this content. It's not even limited to creatives - everyone can benefit from providing their mind more unoccupied space move in, or less noise to speak above depending on your metaphor of choice.

\n

She mentions, but I don't think does justice, to the constant input from, or demands made by, technology on our attention and time. She makes some really great points about Cultural Homework - about how there's always that series or film to watch. But this almost already feels outdated against the algorithm-run media platforms of Twitter, podcasts, YouTube, and Netflix. There's always more material, there's always something \"we think you'll love\" or something \"everybody's talking about\" even if no one you know ever actually speaks about it. These recommendations will be served up to you unless you actively stop it. This is a different point to the Cultural Homework idea, but I think it's got a lot more potential to destroy the internal conversations, meandering thoughts, and quiet moments that make us... us.

\n

I'm a software engineer by day but creative by night, and these are issues I think about a lot, so I don't think it's fair to judge someone's work for not writing about things that I personally find very interesting. In all, Sykes does what all good essayists do: taken some nebulous thoughts and feelings and put them into coherent words.

\n

It's also wonderful to hear the strong feminist currents through pretty much all the pieces. Sexism, like any other kind of prejudice, is plagued by the idea of a micro-aggression. While the right wing of the political spectrum have got a hold of this word and use is pejoratively to dismiss any discontent as an overreaction, Sykes is able to pinpoint specific examples and lay them in front of you. When she's talking about social media usage from a woman's perspective it becomes plain how female empowerment, voice, and worth still rely on external validation for their power, which often comes from their aesthetic beauty.

\n

This slight shifting of the rules is not the same as the ground-up change that we need. Changing the standards of \"beauty\" is not the same as changing the \"source of power\". It's easy to be placated by a celebration of stretch marks and natural hair (looking at you, Kendrick) and Sykes reminds us that we still need to go further.

\n

As a dude, I don't want to talk about why something might make me feel inexplicably icky, because often I am a witness not a participant, and often the last thing we need now is another dude speaking on behalf of women. This means that I don't have a lot of experience putting into words why something makes me feel icky - but this book gave me that. It gave me concrete examples and it gave me a well-considered viewpoint from both a participant and an observer perspective.

\n

And she does all this without ever asking for, or demanding, you believe her. Perhaps if I came into this book without already agreeing with her, I wouldn't have found the arguments so convincing. But I don't think her intention is to convince or persuade so directly. I might as well score the book a 0 because it taught me nothing about the economics of wool in 1400s Morocco. Instead, the tone I got was of someone patiently and considerately explaining why they think and act the way they do, and let's stop for a second to realise that this is totally the ~~~magic of books~~~ and the wonder of reading.

\n

While it's very clear that she has her own opinion on the matter, this often feels disconnected from the citations or research she puts in. She'll often throw in a bunch of quotes from books, or personal e-mail exchanges (which aren't published by the way, but I'd 100% read that in a serialised newsletter, Sykes) and then in a paragraph move onto something which feels... sort of related? I got a lot of good book and author recommendations, but it felt like she had a quota for her bibliography? I'd prefer to see these references linked better into the main body of text, or at least acknowledged consistently. Sometimes she'll come back to mention and author or a work, but a lot of the time it's \"as [AUTHOR] says in [WORK] 'word word word'\" and then we never hear about [AUTHOR] or [WORK] again in any detail.

\n

With that said, I would recommend this book. I made a lot of notes in the margins - I got a lot of good further reading, and she gave me a lot of examples and words for things which I will use in the future. I look forward to anything Sykes write in the future and I'll definitely pick it up, as I think there's room for a tighter, more informed writing style. Alternatively, she can keep things just the way she is, and I can feel like my clever patient badass friend is explaining things to me and I'd still read it. 3.5\u2b50

", "slug": "how-do-we-know-were-doing-it-right"}, "2020-08-29-apple-what-are-you-doing": {"title": "Apple, What are you doing?", "author": "Thomas Wilson", "date": "2020-08-29T00:00:00", "book_review": false, "preview": "I have loved Apple solidly for eight years, since I was 20 and gifted a Mac Mini for Christmas. I wrote my Masters thesis on that thing in a ground floor bedroom of a student house", "content": "

I have loved Apple solidly for eight years, since I was 20 and gifted a Mac Mini for Christmas. I wrote my Masters thesis on that thing in a ground floor bedroom of a student house overlooking suburbia at 3am on a Tuesday night. I finished my Ph.D. thesis on a MacBook Air (which certainly didn't deserve to be put through what I asked it to do) as I sat, hunched over, on a rainy November afternoon, in a tiny flat in Paris that smelled like fresh lemon and ginger.

\n

MacOS is the operating system is the vehicle I drove from environmental scientist to software engineer, and so changed my life trajectory inexplicably. I love the build quality of their machines, the UI aesthetic decisions, and the entire world of Open Source software which was opened up to me by its POSIX compliance. This is helped by the fact that I moved into a Web Development: an argumentative ADHD-sort of community but one that really likes to share and discuss things openly.

\n

This is the community which modelled to me \"this is how a good engineer behaves\" - looking around and seeing Kent C. Dodds, Sara Viera, MPJ, Chantastic, Dan Abramov, Sophie Alpert, and so many others just like... be chill patient folk who take the time to explain what they're doing and thinking and making.[^And surrounded, obviously, by so many other who are not chill or patient]

\n

So to see one of the largest companies in the world (2T\\$ now) scrapping with developers and (multi-)national legal systems for using practices which look an awful lot like monopolistic and anti-competitive practices seems wrong to me, and also a lot of other people in the dev and tech spaces.

\n

The Hey Drama

\n

Hey.com is an e-mail service released by Indie Tech Darling Basecamp. They released Hey with admirable ethical (no tracking) and technological (no unnecessarily complex stacks) intentions to change some aspect of the e-mail domain. They priced their product at \\$99/year, which you could only buy through their website.

\n

They created desktop, web, iOS, and Android apps for people to access their Hey e-mail accounts - and before the public release they had their iOS version approved on Apple's App Store. In the lead up from beta to release, Basecamp made bug fixes to their iOS and submitted it for review (as every developer must), and had their app rejected because it did not provide a way for iOS users to create an account in the App.

\n

To be clear - this functionality had never been in the Hey app. It had not been present and then suddenly removed.

\n

Any in-app purchases (IAPs) result in a 30% cut going to Apple (or a 15% cut in the case of a recurring annual subscription after the first year). It's not hard to understand Apple's immediate concern: Apple are missing out on a potential \\$30 each time a user downloads the Hey app and creates an account in app and signs up for a year's worth of service. Apple stated that until this IAP option was added, they won't approve any further changes to Hey's iOS app. This meant bugs would go unfixed, weeks-days before Hey was to be released to the world at large.

\n

One can easily understand the outrage this caused in Basecamp, and then further afield. David Heinemeier Hansson (DHH), the CTO at Basecamp and general holder of strong opinions tweeted:\n\\

\n
\n

There is no chance in bloody hell that we're going to pay Apple's ransom. I will burn this house down myself, before I let gangsters like that spin it for spoils. This is profoundly, perversely abusive and unfair.

\n
\n

In the end, Basecamp offered users the chance to create a two week \"trial\" account in the app - so technically users without an account could open the app for the first time and get started with sending/receiving e-mails.

\n

This isn't even a satisfying conclusion or resolution - it feels more like Apple just wanted to do... something. Tim Cook's recent defence of the 30% cut included the argument that it's only included when a business \"acquires a customer on an Apple\" (source). But now you're demanding a way for an App to turn a new user into a customer - even if that process has historically only been done outside the iOS ecosystem (e.g. Netflix)?

\n

If you want to see more about the Hey scandal, Basecamp covered the issue in an episode of their own podcast, Rework.

\n

The Fortnite Drama

\n

In the weeks leading up to writing this article, a similar skirmish has started between Epic Games and Apple. This time it's over Epic's Fortnite, an extremely popular Battle Royale-style game (last-person-standing).

\n

Fortnite was released on PC in September 2017, and later on iOS in March 2018. The app's in-game economy uses an in-game currency (V-Bucks) that lets people purchase cosmetic items, things that look fun but don't affect the core gameplay. Earlier this year, Epic updated the app to allow users to make IAPs using this in-game currency - as opposed to the system-level iOS integration.

\n

In a similar argument they raised with Basecamp, Apple blocked updates to the App as these IAPs did not use Apple as the platform/payment provider, and so did not offer the 30% cut. As of 28th August 2020, Apple removed the Developer Account associated with Fortnite from the App Store. Users can no longer download the Fortnite App on iOS.

\n

Similar to Basecamp, Epic's rejection of these terms has been very public. In fact, probably more spectacle-making than Hey's, with the release of a riff on Apple's famous 1984 Macintosh advert. Additionally, the opening pages of Epic's lawsuit read well enough that one could argue they were written for non-lawyers.

\n

Unlike Basecamp, Epic have so far been willing to create some kind of compromise, no matter how purely technically correct that compromise is. Both Apple, and the US legal system have argued that Epic's repeated, intentional non-compliance with the rules mean that Apple are within their right to remove them from the App Store.

\n

It's not just Epic Games anymore

\n

The twist in the Fortnite story came when Apple threatened to remove the both the developer accounts associated with Fortnite and Unreal Engine - a free-to-start video game engine owned by Epic.

\n

In case it is unclear: Unreal Engine is a technology for building games other than Fortnite. It's used by developers across the world, including games in Apple's own Apple Arcade

\n

If it went away on iOS anyone building games for iOS that used Unreal Engine just... couldn't. Quoting Kevin Gammill the General Manager of Gaming Developer Experiences at Microsoft:

\n
\n

\"Unreal Engine's sudden loss of support for iOS and macOS would create significant costs and difficult decisions\" for game creators, who \"would have significant sunk costs and lost time using Unreal Engine for game creation, and would have to choose between (a) starting development all over with a new game engine, (b) abandoning the iOS and macOS platforms, or (c) ceasing development entirely\"... It is abundantly clear that Apple's retaliatory steps are intended to harm Epic and its licensees. (court proceedings p.9)

\n
\n

Luckily the courts swept in and prevented Apple from doing this. U.S. District Judge Yvonne Gonzalez Rogers commented:

\n
\n

Apple has chosen to act severely, and by doing so, has impacted non-parties, and a third-party developer ecosystem. In this regard, the equities do weigh against Apple

\n
\n

Creating a Developer Ecosystem

\n

I am concerned that Apple's anti-competitive, monopolistic practices are harming the consumers of and third-party developers for their own platform. So I suppose, actually, my concern is this: Apple aren't distinguishing between end-users and developers - they're both just consumers of a service.

\n

Or perhaps they see little problem with applying pressure to the development community to stop others from raising such vocal fights against the conditions of the App Store and IAPs.

\n

This from a company which famously celebrates quality and diversity of their platform. Every years at WWDC they give out awards for the third-party Apps and games which are well designed.

\n

Equally, from a business perspective they profit from the diversity and quality. The fact that indie-devs, talented teams, and huge corporations can all publish something into the App Store gives the iPhone an appeal across demographic, generations, and personality. Just want e-mail, a PDF viewer, and a spreadsheet viewer? No worries. Want to cram your phone as full of bright-and-loud games, also fine, friend. Artistic type who wants to take and edit photos or videos, check.

\n

Apple are acting acting as if they're irreplaceable, and as if there are no alternatives for developers, or as if this diversity and quality across the board is inevitable and without condition. This is literally why they're on trial for anti-trust - they're abusing their market position, capitalising on a lack of viable alternatives, and influencing the ability of developers to speak out, or find alternative revenue streams.

\n

In the recent antitrust hearings, Tim Cook argued the 30% cut is justified because the App Store is a trusted place for the discovery (user), distribution (developer), and payment (both) of Apps globally. A particularly pessimistic reading of this statement makes it sound as if the App Store is the only platform for doing so. That without Apple, all businesses, talented designers, and savvy engineers would be unable to reach customers - or that end users would be paralysed by choice or stifled by lack of options. The Wild West of the internet, with its ample e-commerce and payment platforms stands as a blatant contradiction of this statement.

\n

How many people rely, if not entirely then at least notably, on IAP revenue for food and rent? How many people have had to increase prices for IAPs, or to encourage more IAPs just to negotiate around this 30% cut? Epic Games won't go broke because of a 30% cut of purchases made on iOS devices, but an indie-dev easily could.

\n

Apple aren't willing to budge on this 30% figure. PayPal charges 2.9% + $0.3 for a transaction, so does Stripe. Gumroad charges 3.5% + $0.3. Shopify charge 2.4-2.9% + \\$0.3. Apple are justifying a 10x increase on web payment providers, and then fight back these claims of injustice from developers who try and find ways around them (ignoring that Netflix, Amazon, and other big players seemingly get around this without problem).

\n

Instead, this is... The Developers' fault? In a statement made on the Fortnite case, Apple said:

\n
\n

Instead [Epic Games] repeatedly submit Fortnite updates designed to violate the guidelines of the App Store. This is not fair to all other developers on the App Store and is putting customers in the middle of their fight

\n
\n

There just seems too much irony, gaslighting, and hypocrisy in this statement. This cannot be an actual lack of self-awareness on Apple's part - someone must have raised these questions internally. Someone must have noticed.

\n

As someone who builds software, it raises serious questions about the value that being on the iOS store adds, and the additional work that would need to be done to make a native app useful over, say, a web-based purchase. If I was building a new product, this would push me more towards web-only or a more read-only iOS experience. It makes me as a developer question how much Apple value my business, especially when they have global insights into the most valuable kinds of apps and could build out their own alternatives to crush my business if its part of a popular genre.

\n

This is the environment that Apple are creating for consumers, developers, and businesses who want to use their platforms - and it doesn't seem right. This is bad PR, this seems damaging in the long run. It seems an awful lot like the company could maintain their standards of quality and security without a lot of these practices (he says, with literally no evidence to back it up). It worries me that one company can raise all these questions and concerns.

", "slug": "2020-08-29-apple-what-are-you-doing"}, "2021-03-06-design-workflow-build-components": {"title": "The Frustrating Mismatch of Design by User Journey but Build with Components ", "author": "Thomas Wilson", "date": "2021-03-06T00:00:00", "book_review": false, "preview": "How do you design a good app?\n\nIt's a charmingly amateurish question, but I've spent the past five years primarily trying to design and build web apps and I don't know the answer.\n", "content": "

How do you design a good app?

\n

It's a charmingly amateurish question, but I've spent the past five years primarily trying to design and build web apps and I don't know the answer.

\n

I regularly get sick of looking at my current and old designs and ask \"why don't these look like a competent adult made them, and can I make them actually good?\". I'll typically then do two things:

\n
    \n
  1. Go to Dribbble and meander around until I find things that look vaguely like what I want and then get frustrated that these mockups are so simplified and informationally un-dense they're only partly applicable to my current situations, and
    2. \n
  2. Do a web search for \"how to design good UI\", then get given countless \"seven tips to improve your UIs\" and \"UX fundamentals for UI design\" that will tell me that a UI is basically just colour, spacing, and typography which, yeah true, but is incredibly unhelpful in the abstract.
    3. \n
\n

These are two vastly different types of data: one is a finished product for an often fictional or simplified use case, and the other are abstract design principles. Mushing those things together to understand, critique, and then be able to produce your own design is the skill of becoming a better designer. It's not intuitive or easy and you can't just search for the answer on the internet.

\n

Build in Components

\n

But as an engineer I want to, because that's how I find a lot of my answers. That and doing it wrong the first time.

\n

Being an engineer I build web, and more recently mobile, interfaces. Both of these technologies have been moving towards the component-model: building self-contained little things or widgets that are composed together to make bigger things, like screens and applications. React, Vue, Svelte, and Angular all use this model. SwiftUI introduced it for iOS and Swift, and Jetpack Compose (seems) to do the same for Android and Kotlin.

\n

This component model is declarative. I'm not 100% convinced I actually know what declarative means because I am not a clever man, but broadly I think of it as f(state) => ui - which is to say that the UI is a function of state. Given some data, this is what the UI will look like. You get to say \"when the data looks like this, do that with it\". For example if an item in a list is selected, make sure this text is underlined, or this string in the cart should be the total cost of every item in the cart with the \u00a3 character put in front of it.

\n

Components as a first class citizen in building UIs lends itself really well to encapsulation: a component should care only about the data that it needs to present information to the user, and contains the complexities of any internal interactions or logic. It doesn't need to be aware of anything else.

\n

Let's illustrate this with a button (I'm sorry, I know it's tired and over-worked, but it's simple). Imagine we have a Button component that only takes two bits of data (like a prop, or an input, or an argument): a label, the text that goes in the button, and an onClick function to describe what happens when a user presses/clicks the button. The benefits of encapsulation work for everyone:

\n
    \n
  1. The button only has to do what it needs to do. It doesn't care if a label comes from an internationalisation (i18n) file, a database, or generated dynamically when the user does something (like added above \u00a3100 worth of products to their cart).
    2. \n
  2. The page / larger component (like a molecule in Atomic Design) doesn't need to contain boilerplate code about rendering and event-handling for buttons. If I had four buttons on a screen (which, let's just be clear, would be madness) the page they're on doesn't need to worry about anything but finding a label and an event handler.
    3. \n
\n

These are really great benefits for the engineers building UIs and web software. They can make code easier to understand, more consistent throughout the codebase, and more separated. These are not guaranteed (I can make any code into spaghetti, honestly it's a super power) but they are easier to achieve with this component-first idea of software architecture.

\n

Design in User Journeys

\n

But that's not how the user of a UI thinks about buttons at all. Nor is it helpful when you're trying to design your app. The buttons on a screen let our users, guests, customers, patients, staff, whoever achieve something. And as a designer thinking about the specifics of the button is part of the job, but it can't be done in isolation to every other part of the web page.

\n

It's so easy to find good advice on building components in code. There are tricky conversations to be had about them, about how to extend them and manage them as the complexity grows, but that advice is pretty specific and concrete. It is so much harder to get someone's opinion on figuring out how a button integrates with the Sign Up page, a \"buy now\" button on a product card, a \"add two factor authentication\" button, or a \"request help\" button. These are questions about the purpose and intention of the app you are building.

\n

We are taught to build at the focused and specific level of components, but to design with with so much more information in our working memory. What screen am I on, how did I get here, and where can I go? How do I know if my data is saved or (in)valid? What does it look like if I'm browsing versus editing? If these questions aren't answered properly it creates this weird jilted UI and UX experience as I move around a product. Seeing a mocked up screenshot from a single state of a single page on Dribbble is never going to help me answer these questions, no matter how pleasing the curves, shadow, and pastel colours.

\n

The Frustration

\n

I have experienced (and witnessed) the bike shedding meets deer-in-the-headlights moment of designing a new app or website where you're terrified to make decisions about the label placement on your forms. It genuinely stops me from making decisions and moving forward, especially at the beginning, when your app is an idea and a mostly blank Figma file.

\n

The form inputs aren't important, but they are when they represent 50% of the screens you have currently designed. I have been terrified to move on from designing my sign up screen until I have perfected the form and form input components. Because I was so aware that they're components: they'll be used everywhere. They are perfect lego blocks and if I get them wrong here everything will look terrible.

\n

My fixation (or obsession) with designing by components has limited my ability to focus on anything bigger. But as a user, my fixation on the flow through an application will stop me noticing anything smaller. Yeah, the onboarding was confusing, and I can't figure out how to access my profile page but holy smokes have you seen the border radius on the cards and the top navigation? They match perfectly!

\n

No matter how perfect your button is, it's not going to salvage an app with competing or confusing Calls to Action, with disjointed screen layouts, mixed metaphors, or obscured ideas. Similarly, the UX conventions of colour, spacing, and typography won't help you answer these questions. Yet if you don't build a system around these basic elements, the visual clarity and rhythm of your UI as a whole will suffer.

\n

Similarly, if you don't build your codebase with well encapsulated components, you're going to have a real hard time modifying and extending your app's code.

\n

Designing an app demands that we ask questions about the app, not the components, that we see the entire blueprint. Building components demands we exclude all thoughts about the app at large and focus solely on this little corner, this one detail. This is the titular frustration of having to build in components, but design by user journey and flow.

\n

That's it. That's the end of the article and I'm sorry I can't close with a unifying theory, or three step framework to build perfect UIs every time. I just want to build actually good apps, and it's difficult, ya know? The context switching between design and developer brain is hard.

", "slug": "2021-03-06-design-workflow-build-components"}, "2020-09-25-things-i-learned-7": {"title": "Things I learned this week #7", "author": "Thomas Wilson", "date": "2020-09-25T00:00:00", "book_review": false, "preview": "- **This unknown origin**: No one is quite certain where the term \"rule of thumb\" came from. It has been mistakenly attributed to a British Judge's rule that a man can beat his wif", "content": "\n

What I've had on rotation

\n\n

Cool Articles

\n", "slug": "2020-09-25-things-i-learned-7"}, "2021-02-19-things-i-learned-28": {"title": "Things I learned this week #28", "author": "Thomas Wilson", "date": "2021-02-19T00:00:00", "book_review": false, "preview": "- **This collective noun**: If I was to make a list of small-talk and first date conversation topics it would go something like this: food, the tube, podcasts or books, and then co", "content": "\n

What I've had on Rotation

\n", "slug": "2021-02-19-things-i-learned-28"}, "2020-11-19-figma-variants-without-buttons": {"title": "Introducing Figma Variants with 5 Components that aren't Buttons", "author": "Thomas Wilson", "date": "2020-11-19T00:00:00", "book_review": false, "preview": "Figma recently introduced Variants - a way of extending and varying your components. Components in Figma, and in modern web development, are reusable and encapsulated elements of a", "content": "

Figma recently introduced Variants - a way of extending and varying your components. Components in Figma, and in modern web development, are reusable and encapsulated elements of a design - with the classic examples of a Button or a Card.

\n

Variants add new flexibility, and utility, to components in Figma by introducing properties and values to them in a programmatic way. If you have experience writing modern web applications, these variants and properties are like a specific subset of props which you pass to a component. I say subset, because some things will still need to be manually edited within an instance of a component - like the text in a card. Other things, like a \"variant\" or \"type\" be be edited (e.g. info, danger, or primary) which in turn could switch the accent colour, and the icon used (from an i, to an alert, to a logo). Think about all the common variations of a component you make for different use cases - variants are a way to define those before you come to use them.

\n

Variants were released relatively recently, and I think they're cool. While they require more conscious work to create, they make it much easier to compose a mockup or design using an existing design system. Additionally, the need to create a set of names for both your properties, and their possible values, forces you to develop a verbal language around your design.

\n

In this piece I'm going to give five examples of where variants have helped me, in the last couple of weeks. I'm not going to use the Button component as an example - because that's a tired workhorse, and I'm definitely a bit sick of it.

\n

Component Examples

\n

Don't bury the lead, here are some components to show how variants in Figma can be used. None of the are Buttons (did I mention that?), but they are all components I've used in the past couple of weeks. Where I didn't make the component myself I've linked out to the original author.

\n

I've standardised on Variant as a property name for a generic \"type\", \"context\", \"kind\", or \"variety\" in components. This is the same language as Material UI uses to describe this property and variation. I personally don't like to use Type - because it's already a word loaded with meaning in typed language. Context also has a meaning in React. Naming these kinds of properties is hard, but you have to stay consistent.

\n

Shoutout to UI Guideline for providing inspiration and starting points.

\n

#1: Toast

\n

Toasts are those little alerts that pop up or down into a screen with a transient messages. Often you want to vary the accent colour, or icon, depending on the context of the message. There's only one property here (Cariant) which controls this accent colour.

\n\n

\"An

\n

#2: Note or comment

\n

Eduard Gim\u00e9nez released a set of comment components into the Figma Community. The Note This file contains a set of sticky-note-like component which teams can use to annotate their designs in Figma.

\n

Eduard has used two properties on his variants: Color, which describes the accent colour of the icon and top of the note, and Dark which is a boolean for if the note should be in a dark mode.

\n\n

\"An

\n

#3: Calendar Day

\n

I've recently been using the Eva Design System as the starting point for a design language. As part of this, I've been working with calendars and date pickers - which have turned out to be a classic example of hidden complexity.

\n

Calendar days represent a single day within a week or month view, often used in the date-picker component.

\n

Eva broke them down across three properties, each a boolean flag:

\n\n

\"An

\n

#4: Card or Modal

\n

I've been building a number of screens and modals recently (as part of my design work at Oxwash), and Variants have let me use a common component as the background on each of these instances.

\n

The Card component typically represents the background and container for some content, e.g. a product in a product list. A Modal, however, is normally overlaid on the screen, as if it had a higher Z axis value (i.e. it pops out of the screen). Visually they are very similar, but conceptually they are quite different.

\n

I found by adding or removing an icon in the top-right (e.g. to close a modal) - both were pretty much identical.

\n\n

\"An

\n

#5: Tooltip

\n

I've also been using Tooltips at Oxwash - tooltips are little containers of text that appear on hover (or tap, for mobile) to offer some additional information.

\n

Technically, tooltips are quite complex, but in terms of design I've kept them simple, with just a couple of properties:

\n\n

\"An

\n

Wait, couldn't Figma do that before?

\n

Erm, yeah, sorta? Previously you could use naming conventions of components to help organise related components and then swap them out with siblings/cousins/grandparents. You did this with the naming conventions of the component, e.g. you could organise your three different types of alert component by calling them:

\n\n

This works when you've only got a couple of variations of a component. Specifically it works when your components only vary along one dimension, e.g. the accent colour of the alert. What happens when we have a couple of aspects the component can vary by? What if we want different components for mobile, for dark mode, for actionable alerts (e.g. with a button or link)?

\n

All we've got is a single string, so we absolutely have to i) maintain strict naming conventions of both the possible values of a property, and ii) identical order of properties in those strings. For example, the following components both parse well to a human, but would be structured very differently within figma:

\n\n

This would make it hard to swap components out with the related ones. Figma essentially creates a directory, or folder, -esque structure so these kinds of inconsistencies eventually force you to move around a lot, or do a lot of searching. This will also make your components less discoverable, which is essential if you're a design team who shares Figma files to a wider organisation.

\n

Also it's just messy. I don't like non-productive mess.

\n

Properties I have found useful

\n

There are a couple of properties I have found myself reaching for, and finding useful - especially when you're trying to work out all the fiddly details in a specific design. These include:

\n", "slug": "2020-11-19-figma-variants-without-buttons"}, "2022-08-23-explaining-tdd": {"title": "Explaining Test Driven Development", "author": "Thomas Wilson", "date": "2022-08-23T00:00:00", "book_review": false, "preview": "Test Driven Development (TDD) is a way of writing software where the author writes a test first, and *then* writes the \"actual\" code.\n\nThe \"actual\" code here is the bits of softwar", "content": "

Test Driven Development (TDD) is a way of writing software where the author writes a test first, and then writes the \"actual\" code.

\n

The \"actual\" code here is the bits of software which do the dirty work. They might process a payment and then send a receipt e-mail. Let's call this your Worker Code, because you can imagine it like a set of tiny robot workers going about their day and running your business.

\n

The \"test\" code are bits of software which tell your worker code to do something, and then check the output. If the tests don't get back the exact thing you told them to expect, then they fail. Otherwise, they pass. They're like little Quality Assurance robots, or little robot Miss Trunchbulls, or a room full of little robot NASA workers doing pre-flight checks.

\n

TDD's Value

\n

So there's a practice called TDD, where engineers are encouraged to write the test first, and then the worker code second. This might sound a bit arse-about-face, or like you're doubling the work to do a thing.

\n

Despite this, TDD is good because:

\n\n

It's more valuable to test before because:

\n\n

Worker code adheres to a strict, explicit contract is good because:

\n\n

Malicious Compliance & TDD

\n

Tests aren't inherently good. Like all robots, your test code only does exactly what you tell it to do. Robots follow the letter of the law, not the spirit.

\n

Worst case scenario, your engineering team have spent their time time and attention (v. expensive) on a thing with no value to you as a business, or to your customers.

\n

Even worse, you can do this and show some nice quantitative metrics that everything's a-okay. Better than okay, thriving. Perfect. Industry leading.

\n

What you've got is an expensive way to look busy, where the business pays the cost. This is borderline malicious compliance.

\n

Malicious compliance is the natural predator of TDD's value.

\n

Good tests give orders to your worker code in the exact same way that a real world customer or user would. Bad tests give irrelevant or mundane orders.

\n

How can you tell these two things apart? How can you guarantee you're doing one, not the other? Not to be flippant, but that's the nuance in TDD. The discipline comes in over-valuing tests that act like real-life users, and devaluing tests for tests sake.

\n

I won't discuss it here - but it's something I'm working through in my head and with my team.

", "slug": "2022-08-23-explaining-tdd"}, "2020-10-23-things-i-learned-11": {"title": "Things I learned this week #11", "author": "Thomas Wilson", "date": "2020-10-23T00:00:00", "book_review": false, "preview": "- **This thing about how we sleep**: In Western Europe, about 35% of young adults sleep with a soft toy every night, and about 44% of people keep hold of their childhood soft toy. ", "content": "\n

What I've had on Rotation

\n\n

Cool Articles

\n", "slug": "2020-10-23-things-i-learned-11"}, "back-to-bear": {"title": "Back to Bear, Goodbye Notion", "author": "Thomas Wilson", "date": "2019-08-15T00:00:00", "book_review": false, "preview": "This piece turned out a little long than expected because I really want to clarify that this is not a \u201cWhy Bear is better than Notion\u201d article. It is a \u201cWhy Bear suits my needs rig", "content": "

This piece turned out a little long than expected because I really want to clarify that this is not a \u201cWhy Bear is better than Notion\u201d article. It is a \u201cWhy Bear suits my needs right now better than Notion\u201d discussion. So there\u2019s a little more nuance in my explanation.\nThe crux of my point it is this: I am a scatter brained person who develops software, makes dance, and exercises semi-seriously - and I need a digital tool to help me manage my thoughts, writing, documentation, and general projects. I previously used Bear, a beautiful and simple markdown-esque note keeping app, but forgot about it when I moved cities and jobs pretty much all at once. In my new life I started using Notion, a cross-platform feature-rich editor, but I\u2019ve gone back to Bear.\nI went back to Bear because I like the simplicity - it let me categorise, expand, delete, and move things around in a way which is much closer to how I think about my life and work. Also, as a developer, if I want complexity I\u2019ll roll my own: between Google Docs and serverless providers I can achieve a lot.

\n

A brief love letter to Apps

\n

I live my life in a couple of lanes: I\u2019m a front-end software engineer in a small team at a rapidly growing scale-up, and also a dancer/producer for a small contemporary dance company, and someone who likes to write and journal for their own personal development. I am asking a lot from any app, I want it to collate my thinking of software architecture; document specific practices across a range of projects; and keep track of myriad side projects, restaurants I want to visit, narrative structures and scene ideas; document research material and my evaluation of it; and outline workflows for funding applications. I want to do these things with as little context switching as possible. I want a killer app that doesn\u2019t exist: not only are these a contrived set of requirements, but how I think about each of them, my mental models for them, are different.\nBut I really love the search. I love apps. I love the promise that a new App brings - it\u2019s like buying a new blank notebook, non-blank regular book. It\u2019s the promise of a new you, a new way of thinking, doing, producing - one step closer to the way you work now, and a more productive, happier, wealthier, and skinnier version of yourself. I think this is the feeling which fuelled first decade after the iPhone was released, when everyone wanted to talk, read, write about the killer app for iOs (and now iPadOS) or OSX (and now OSX).\nIt definitely feels now like this conversation has slowed down, the conversation is less around specific apps. However, every now and again, hype rises out of Product Hunt or Hacker News to offer up some crafter, artisanal interfaces. Bear and Notion have been two such apps: I\u2019ve seen them on twitter, in online publications, and other developers mention them.

\n

Bear

\n

Bear is a beautiful note-taking App built for the Apple ecosystem (iOS, iPadOS, MacOS) by Shiny Frog. The premise is simple: you write in a markdown (or markdown-esque) syntax, which gives you access to a limited set of features: body text, headings, lists, links, images, inline code, bold, italics. Notes themselves are organised by any number of tags ( anything starting with \u2018#\u2019 ) which can be nested, e.g. post/post versus blog/portfolio. It\u2019s been recognised by Apple number of times for their fantastic visual design. Which makes sense: it does one thing well, feels simple, but can be integrated into very powerful workflows (e.g. exporting to markdown and plain html). This is Apple\u2019s philosophy, surely.

\n

In Praise of Bear

\n

There are a couple of things I really liked about using Bear:

\n\n

My time with Bear (2017-2018)

\n

After graduating my Ph.D. into my first software development job I was looking around for note taking apps, so I could keep track of what was happening in meetings, product development ideas, and my own personal learnings. My first job came with a lot of context switching - I was on a number of different projects, so flexibility was important.\nI came across Bear, probably from an App Store feature, and loved it. But around 6 months after starting the job, I relocated from Southampton to London, and not soon after I started actively looking for new job opportunities. The job I was in was okay, but not what I imagined it would be, or what I needed at that time in my professional journey. this is important because I was going through a lot of personal change and turbulence - I didn\u2019t have a system in place for anything, and it would have been pointless to develop one because things were changing so rapidly.\nSo I left bear behind accidentally, I simply stopped using it and it never occurred to me to start using it again around the time I moved to London in early 2018.

\n

Notion

\n

Describing Notion is much less simple than Bear, they describe themselves as an \u2018all-in-one workspace\u2019. It offers an astonishing amount of functionality: Kanban boards, structured tables with filters, embedded web pages, todo lists\u2026 honestly I do a disservice in trying to list them all.\nI started using Notion in early 2018 after moving cities and jobs - two big changes which broke a lot of my old habits and tools. I think I first saw it in a coding livestream by MPJ on his YouTube channel funfunfunction , and then finding this profile by invision on Ivan Zhao, the co-founder and CEO. He seems like a cool guy, really product focused, and making something productive and beautiful. So I started using Notion personally, and at work.\nI used it to help me organise my first ever cycle tour across France in 2019 (I got half way through and then rained off - 3/10, would not recommend), to track my route and AirBNBs. I used it to write documentation for projects at work. I kept a track of my personal and seasonal goals (shoutout to Cortex for introducing me to the idea of yearly and seasonal themes.)

\n

In praise of notion

\n

I initially got on really well with Notion, it had a number of really nice features:

\n\n

Moving away from Notion

\n

After 4-5 months, I started to notice some noteworthy drawbacks to using Notion in practice:

\n\n

Returning To Bear

\n

Since moving back to Bear, I\u2019ve found writing a lot more pleasant and less intimidating. I actually managed to start and then finish this piece, for example. Migrating all of my information from one to the other has been a little bit of a pain, but it\u2019s now so easy for me to get started creating something, without worrying about where it belongs or how I should categorise it at the moment of creation. I have my beautiful, overflowing dumping ground, and in six months I look forward to coming back to Notion begging for their opinionated organisational structure. Until then, vive l\u2019ors.

", "slug": "back-to-bear"}, "2022-06-05-vibe-check-4": {"title": "Vibe Check #4", "author": "Thomas Wilson", "date": "2022-06-05T00:00:00", "book_review": false, "preview": "Every year my brain tricks me. *June*, it says, *June is summer*. And every year around this time I get long daylight hours but seemingly endless wind, rain, and rarely-over-twen", "content": "

Every year my brain tricks me. June, it says, June is summer. And every year around this time I get long daylight hours but seemingly endless wind, rain, and rarely-over-twenty temperatures. Some days have been beautiful, but many (like today) are unadventurous. I sit inside a cafe to write.

\n

The weather can do as it pleases (despite what we tell it to). Summer is a state of mind. I love how far we are from the long nights and dismal days, I love waking up when it's light and getting into bed just after it goes dark. I love the promise of summer holidays to come, and the days still getting longer (though not for long). The days feel expansive and my brain feels like it can really settle into something.

\n

This month I feel I've really progressed. I've spoken more French out loud in the last month than the year which proceeded it. I've made things with my sewing machine, things someone else would recognise as clothes. The spacecraft of code that keeps my employer's business afloat has had some cool maintenance work done, especially around some of the most unvarnished, exposed, edges. We're trying a new way of building the space ship.

\n

While we're talking about code and craft, the fellows over at the Shop Talk podcast discussed a few metaphors which resonated with me:

\n
    \n
  1. Comparing your team members and working styles to D&D classes (clerics, paladins, rogues). I like this metaphor because it reminds you that people contribute in different ways, and often in ways which complement each other. (Episode 493)
    2. \n
  2. Building software isn't like building the plane while it's flying. I think this metaphor is common because it's funny and dramatic, not because it's true. It's not how airlines do their repair and maintenance work, they do everything they can to keep planes in the air and on flight. Maintaining and improving production systems is a balancing act of keeping all the flights on time and in the air, while gradually improving the planes in the air. (Episode 516)
    3. \n
\n

This month I've needed to slow down and focus so that I can enjoy the work. Normally I tell myself that so that I can do the work. Only one project at a time. Be present in the act of making. Write things down, even when you feel you don't have to.

\n

Highlights from this month include

\n\n

Books

\n", "slug": "2022-06-05-vibe-check-4"}, "2020-08-21-things-i-learned-2": {"title": "Things I learned this week #2", "author": "Thomas Wilson", "date": "2020-08-21T00:00:00", "book_review": false, "preview": "- **This useful thinking tool**: good writing starts with observations, and moves to analysis. Making the transition is difficult. One way to spot a mental crutch is to see where y", "content": "", "slug": "2020-08-21-things-i-learned-2"}, "2020-10-16-things-i-learned-10": {"title": "Things I learned this week #10", "author": "Thomas Wilson", "date": "2020-10-16T00:00:00", "book_review": false, "preview": "- **This Tiny City**: St. David's is a city with a population of about 1,000 people. In 1886 it was stripped of its status as a city, being described as \"lonely, and the neighbouri", "content": "\n

What I've had on Rotation

\n\n

Cool Articles

\n", "slug": "2020-10-16-things-i-learned-10"}, "2021-06-05-weekly-43-vision-problem-action": {"title": "The Weekly #43: Vision, problem, and action", "author": "Thomas Wilson", "date": "2021-06-05T00:00:00", "book_review": false, "preview": "The Weekly is a weekly essay where I write about something I\u2019ve been thinking about in the last seven days. They\u2019re under 1000 words, and this week I want to talk about vision and ", "content": "

The Weekly is a weekly essay where I write about something I\u2019ve been thinking about in the last seven days. They\u2019re under 1000 words, and this week I want to talk about vision and problems when you\u2019re building a new product.

\n

I\u2019m building the lexicon, where I am (un-ironically) trying to build the world\u2019s most useful language learning resources. I like Duo Lingo, but I don\u2019t think it helps you much in the real world \u2122\ufe0f. It\u2019s born out of my desire (and previous moderate success) to be come proficient in French. The pandemic slashed my French proficiency, though.

\n

Over the past few weeks I\u2019ve been thinking more about this product idea. I think there\u2019s enough scope in the vision of \u201cbest language learning resources in the world\u201d that I can meaningfully do something new. I think I know enough about computers and learning to do something impactful.

\n

The first thing I did? Set up a landing page with a sign-up form for a mailing list, and released two (free) sets of flash-cards with the most common words. If you want them, you know where to find them.

\n

None of these things (which took real time and energy) solve any of the core problems that I\u2019m trying to solve, though. I\u2019ve got a vision for the company, and these things move me generally in the direction of it. I can\u2019t sell anything if people can\u2019t find where to buy it.

\n

But I don\u2019t think I solved the high value problems.

\n

In his essay how to get startup ideas Paul Graham says:

\n
\n

You should only work on problems that exist. And yet by far the most common mistake startups make is to solve problems no one has\u2026 The verb you want to be using with respect to startup ideas is not \"think up\" but \"notice\u201d\u2026 The most successful startups almost all begin this way.

\n
\n

I created this vision because I noticed a problem: I want to learn a language in an efficient way, that gets me to real-world use quickly. Having a landing page does nothing to solve that particular problem.

\n

What Graham says is (probably) true, but I also think they miss out on another dimension of problems: the specificity / uniqueness of them.

\n

Getting Specific: Flashcards

\n

Let\u2019s get specific.

\n

I produced some flashcards sets. These keeps within the vision, but what problems do flashcards solve?

\n
    \n
  1. Target-language translations of words (\u00eatre \u27a1\ufe0f \u201cto be\u201d)
    2. \n
  2. They decide what word\u2019s you\u2019re learning
    3. \n
  3. The can be used in Active Recall
    4. \n
\n

This list, broadly, runs from most generic to most opinionated solutions.

\n

1. Bilingual translation Could you learn French with resources which just showed you the words in the target language. Verser, manifestation, et vaccin.

\n

Have you just learned to pour/contribute, protest (noun), and vaccine ? No. You maybe could have guessed the latter, though.

\n

To remove the bilingual elements of language-learning flashcards would be an unexpected feature. Maybe replacing them with image/sound can help (an auditory component for French \u2194\ufe0f English translations would be beneficial) but largely, you need the bilingual text. This isn\u2019t a high-value problem.

\n

2. Decide what wordsWhat words should I learn? This is a more interesting problem. It\u2019s actually one of the core problems that lead me to think about the lexicon. I don\u2019t think we teach useful words to new language-learners.

\n

The problem of \u201cwhat words do we learn, and in what order\u201d is a problem worth solving. So I used data-backed findings to decide on the most common verbs. This is a higher-value problem.

\n

3. Encourage Active Recall\u00a0Active Recall is, almost irrefutably, a core component of any language-learning practice. When you use flashcards, you should see the prompt and guess the answer (actually guess it, like, say it aloud) before viewing the answer. Anything else is passive recall or lying to yourself.

\n

Active recall is essential to any effective language learning practice, and I was leaving it as optional. \u201cHere\u201d, I said, \u201care some flashcards. You know how to use them effectively, right?\u201d.

\n

A foolish assumption that was probably false (no one teaches these skills de facto in schools) which essentially let the user determine exactly how effective or useful the language-learning resource was going to be

\n

I had a chance to solve an important and unique problem (how to pair the \u201cright\u201d words with the \u201cright\u201d learning method) and I delivered it in static flashcards. I moved towards the vision without solving the particular problems: actually increasing your French vocabulary.

\n

I left the hard work of solving the problem to the customer. I shifted responsibility.

\n

Visions are slopes, problems are places

\n

I was guided by a vision, without thinking about the unique and important problems.

\n

A vision is like a slope. It\u2019s easy to know when you\u2019re heading up or down hill, and you can conform to a vision by degree: head directly down hill, or go diagonally.

\n

If a vision is a slope, a problem is a place. Or a least a region. The further away from the problem you are, the easier it is to head towards it. When you haven\u2019t started, doing almost anything will get you closer. Setting up a landing page and a mailing list, for example.

\n

But you get a bit closer and you\u2019ve got to change bearing. You were heading east, but now you\u2019ve got to head north-east. And then north-north-east. Anything other than that and you start veering away your destination. Maybe you\u2019ll find a different problem along the way (the infamous pivot) or maybe you won\u2019t.

\n

A mailing list, a landing page, and some static flashcards are not the world\u2019s most useful language learning resources. They\u2019re part of the vision but not the product,

\n

Set vision, solve problems.

", "slug": "2021-06-05-weekly-43-vision-problem-action"}, "2020-09-06-javascript-promises-introduction": {"title": "Why are you like this, JavaScript? An introduction to Promises by using Fetch.", "author": "Thomas Wilson", "date": "2020-09-06T00:00:00", "book_review": false, "preview": "Let's start with a correct, but pretty dense, definition: JavaScript Promises are a first-class abstraction for handling asynchronous actions, like:\n\n- Fetching data from a remote ", "content": "

Let's start with a correct, but pretty dense, definition: JavaScript Promises are a first-class abstraction for handling asynchronous actions, like:

\n\n

First class? That's a programming term to say that this kind of value (i.e. Promise) can be stored in a variable or passed as an argument. Other first-class citizens in JavaScript include booleans, arrays, and functions. This means that JavaScript has an internal way of representing and understanding Promises, and we don't have to do any kind of coaxing, coercion, or pollyfilling to use them since ECMAScript2015.

\n

Asynchronous actions? Promises represent the eventual value returned from a function (or more broadly, an action). This means that when we ask for the value of a Promise, JavaScript can distinguish between what is the value at the time you requested, and is this the last, unchanging value of the Promise. In JavaScript Promises, we call these two states:

\n
    \n
  1. pending - where we've described and started the async operation, but it's not completed, or
    2. \n
  2. settled - that async operation has completed (successfully or not) and the value we have isn't going to change again.
    3. \n
\n

Let's take an example and show how we can use Promises. Actually, no, let's show how we can't/shouldn't use them. Imagine we own a taco truck, and we have a menu that changes every day. This means we don't want to build a fully static site, and we want to use JS to add a little dynamic behaviour. To make sure our website always shows us today's menu we:

\n
    \n
  1. Run a fetch function as soon as the page loads which retrieves today's Taco Menu as an array of tacos from an API end point,
    2. \n
  2. Parse that data to extract the id and the name for each taco in that array, and
    3. \n
  3. Iterate through this parsed list and insert new DOM Elements onto the page using any number of JavaScript libraries or frameworks.
    4. \n
\n

Which in some code would look like[^1] :

\n

[^1]: There are some problems with this example (namely that it's actually using Promises under the hood, but please ignore those)]:

\n

```js\n// \u26a0\ufe0f Code is purposefully error-ful, don't run\n// \u26a0\ufe0f gollyilovetacos doesn't exist (yet) - this is illustrative

\n

const menuItems = fetch(\"https://api.gollyilovetacos.com/v1/menu_items\")\nconst parsedMenuItems = menuItems.data.menu_items.map(item => ({\n id: item.id,\n name: item.name,\n}))\n```

\n

This is going to throw us an error (something like Uncaught TypeError: can't access property \"menu_items\", fetch(...).data is undefined). Why? No legit, it you genuinely don't know, please think about why.

\n

It's because fetch returns us a Promise. The code above applies a synchronous way of thinking onto the Promise: we declare it, parse it and parse it (on those two last lines) exactly as if it was synchronous (i.e. the data would resolve immediately) - so on that last line we're looking to get the data attribute of the Promise, as if the Promise was an object representing the API response.

\n

Promises are references to the eventual values, which is different to storing the value itself. We were trying to access the data.menu_items on the Promise which doesn't exist.

\n

The only things that exist on a Promise are: then and catch. This is the most technical definition of a function: Promises are Objects in JavaScript which have a then function, so says the spec.

\n

Before we dig more into promises, I think it's important to ask why bother? Especially when the JS community had a way of handling things like this before ECMAScript2015. Promises aren't technically anything new.

\n

Can't I already do that in JavaScript?

\n

So what? Can't I just use event handlers or callback functions? Yeah, you absolutely can. In fact, these are two ways that we handled async processes in the land before promises. They're both a little bit problematic, however. Events, for example, can fire before we (or rather, the control flow of our program) can assign event handlers to them. This means that can't always guarantee that an event will be handled using the event handler we define.

\n

Alternatively you can use callback functions. Callbacks are kind of like events and handlers, only because you pass pass a function as an argument to a function (possible because functions are a first-class object in JavaScript btw, just like promises) - you don't run the risk of the event firing outside the scope of the event handler function. The problem with callback functions is they can easily get out of hand - as soon as you start chaining data through more than a couple of asynchronous functions, you can end up in Callback Hell: where you're calling callbacks in callbacks in callbacks.

\n

Callback hell is actually a really good example of a particular kind of code smell: technically correct, but difficult for a human to parse, or interpret. We should always be thinking about how code reads to someone new, or even to ourselves if we context switch for five days or six months.

\n

Using somebody else's Promise: Fetch

\n

I want to round off this introductory post by using the Fetch function: which is one of the more common ways that JS devs interact with promises.

\n

Fetch is (browser[^2]) JavaScript's own in-built function for making HTTP requests, and it uses promises. If you've ever used XMLHttpRequest in browser JavaScript, it's a bit like that. If you've not, then you've not got anything to unlearn to alright, let's go.

\n

For now, let's just get our hands on one, and not worry about what it looks like under the hood (as in, medieval fantasy hood not car hood, obviously).

\n

This is one of the benefits of coding to an interface, and if you're really deep into JavaScript land and lost without a map I just want you to know how useful interfaces can be. If you're much newer to JavaScript Land or Software Continent, don't worry I'm just throwing some playful shade.

\n

[^2]: The fetch function is available in most browsers. If you're going to do this in the Node /server environment, you'll probably need a package like node-fetch or some other polyfill.

\n

Sidenote: Emojis in code snippets

\n

I like Emoji, I think they can quickly signify meaning. In the code snippets below I use the following emoji in code snippets to explain things:

\n\n

Back to the show

\n

If you're on a Desktop, I want you to go to Chrome[^3] and open the dev tools (\u2318 + \u2325 + I on a Mac, Control + Shift + I on Windows) and go to the Console tab. We're going to go ahead and get a random Game of Thrones quote because the kind people of the internet have not only created, but made freely available, servers which will serve us wonderful data like this for free (GitHub link).

\n

[^3]: It does actually have to be Chrome, I tried on Firefox and some errors get thrown. Don't worry about them.

\n

We're going to do all of this using Promises and I need to you shut your jaw, I know it's amazing but flies will get in there.

\n

We'll be using an API endpoint to get a random Game of Thrones quote, it's a GET request to https://game-of-thrones-quotes.herokuapp.com/v1/random, and it'll return data that looks like:

\n

json\n// \u2139\ufe0f An example quote from the Game of Thrones Quote API\n{\n \"sentence\": \"Fighting bravely for a losing cause is admirable. Fighting for a winning cause is far more rewarding.\",\n \"character\": {\n \"name\": \"Jaime Lannister\",\n \"house\": {\n \"name\": \"House Lannister of Casterly Rock\",\n \"slug\": \"lannister\"\n }\n }\n}

\n

Actually, if you're really new here, go ahead and just copy-paste that URL into Chrome's address bar. Because it's a GET request, we don't need to worry about anything fancy. You'll get back a plain-old bit of (unformatted and un-syntax-highlighted) text with the data right there in your browser window. This is just like any other HTTP request (the same as going to https://www.reddit.com), it's nothing special.

\n

Calling Fetch

\n

Let's crank the HackerMan dial up a notch and fetch that same data using the console in Chrome's dev tools. In the console type:

\n

```js\n// \u270f\ufe0f Go to the Game of Thrones quotes server and get a random quote

\n

fetch(\"https://game-of-thrones-quotes.herokuapp.com/v1/random\")

\n

// \u2139\ufe0f The console will log you something like:\n// Promse {}\n```

\n

Oh.

\n

That's actually a little disappointing, no?

\n

So what have we done here? I'm being serious - read the gosh darn code and console output and think about what you did then try and explain it to yourself. I'm being serious, say it aloud or write it out - actually go through with the words that you would need to say.

\n

If you did it, I'm proud of you. If you didn't then gee golly, friend I wish I had your confidence in my knowledge. Here's what we did:

\n
    \n
  1. We instantiated the fetch function with a URL for the Game of Thrones quote API. By default, fetch knew that we wanted to make a GET HTTP request (and not a POST or PUT, etc.).
    2. \n
  2. The console then logged out the implicit return value of our statement (which was to call fetch). From this log statement we can see that fetch returns us a Promise.
    3. \n
\n

And that little <pending> sitting there? Why that just means it's not fulfilled - remember earlier where you learned about the possible states of Promises in JavaScript (fulfilled or pending. You know, like 500 words ago. That's that! An unfulfilled promise in the wild.

\n

Storing the Promise in a variable

\n

So how do you actually get the quote in the response, when it comes back?. Well, we didn't store the Promise we generated in the above code-sample, which means we have no way to do anything with it - like check if it's back yet.

\n

Let's fix this, and take a look at the settled promise value:

\n

``js\n// \u270f\ufe0f Go to the Game of Thrones quotes server and get a random quote, and save it to thequote` variable

\n

const quote = fetch(\"https://game-of-thrones-quotes.herokuapp.com/v1/random\")

\n

// \u2139\ufe0f The console will log you something like:\n// undefined

\n

// \u270f\ufe0f Wait a few seconds, then let's look at the value of quote\nquote

\n

// \u2139\ufe0f Will log\n// Promise {: Response}\n```

\n

Oh cool, we made the request and it returned... now what? How do we get the data out of it.

\n

You know what's really cool about Promises? When you create them, you don't have to specify what to do on their success/failure right away. You can create the promise, then handle it later. So assuming you did the above, and you've got a variable called quote:

\n

```js\n// \u270f\ufe0f Add the onFulfilled event handler to the promise

\n

quote\n .then(response => response.json())\n .then(data => {\n console.log(data.sentence)\n })

\n

// \u2139\ufe0f Will return something like:\n// \"Fighting bravely for a losing cause is admirable. Fighting for a winning cause is far more rewarding.\"\n```

\n

You know the drill: tell me what you did here. In a list, out loud, what's happening?

\n

Oh, there's not inline list this time. There's a lot going on here that we've go to break down. Are you ready?

\n

1: Call the then function

\n

We take the Promise which has a Game of Thrones quote in it (somewhere) and we call the then function. This is really important: then is a function on a Promise.

\n

then is a function that takes one or two functions as arguments:

\n
    \n
  1. Argument #1 : The onFulfilled function - which runs when the async operation behind the promise is successfully completed.
    2. \n
  2. Argument #2 : The onRejected function - which runs when (or if) there's a problem completing the async action.
    3. \n
\n

Here, we're only giving it one argument, so we're only defining the onFulfilled part. JavaScript is cool with us leaving the onRejected argument as undefined so now everyone who didn't like that thing about Interfaces has smug little smiles on their joyous faces.

\n

So we're calling the then function with one argument: an anonymous arrow function (i.e. a function that we've not assigned to a variable somewhere else) which takes one argument: which we've called response - which represents the HTTP Response that fetch returned to us.

\n

2: The json function

\n

We call the json() method, the return value from which is returned implicitly[^4]. The json function is defined on the Body of the Response object that fetch returned to us- so don't worry about where it's coming from.

\n

json() essentially takes the HTTP response body that fetch got, and parses it like JSON, so that we can treat it like an Object in JavaScript.

\n

One last thing: json() is an async function, so it returns another promise.

\n

If you're curious about json(), here's the MDN docs

\n

[^4]: Implicit returns in arrow functions in JavaScript don't have the curly ({ }) braces. For example () => 5 will return 5, whereas () => { 5 } will return undefined

\n

3: Promise Chaining

\n

Because that first then function (implicitly) retuned a Promise (from the json() function), we can then call the then function on that that Promise so that we can actually handle the data from the API. This is called Promise Chaining - because you are flowing the result of one async action into another async action handler.

\n

All this work for a damned quote.

\n

Promise chaining is an application of Functional Composition: the way we compose together individual functions into production lines, or conveyor belts, which take in raw data at one end, and produce formatted data at another.

\n

So we take the result of the fulled Promise that the json() function invocation returned - which is a plain-old-javascript object. We refer to this as as data in that second then function - where we read and enjoy with humour or dread, or whatever it is that GRRM was going for.

\n

This isn't the place to talk about functional composition, but if you're already familiar with JS, you can learn more about it here.

\n

Doing the same thing at author-time for Promises

\n

Now that we've covered each of the individual parts of a promise, and you've either got confused and left or scrolled to the bottom, I just want to mention that normally you'll declare your then functions in the same place you create your Promise.

\n

This will give you code which looks like:

\n

```js\n// \u270f\ufe0f Go to the Game of Thrones quotes server and get a random quote, then process the data in-situ (so don't take it anywhere else)

\n

fetch(\"https://github.com/shevabam/game-of-thrones-quotes-api\")\n .then(response => response.json())\n .then(data => {\n console.log(${data.character.name} says:)\n console.log(data.sentence)\n })\n```

", "slug": "2020-09-06-javascript-promises-introduction"}, "2022-08-18-why-no-oo": {"title": "'Why is no one writing Object Oriented?'", "author": "Thomas Wilson", "date": "2022-08-18T00:00:00", "book_review": false, "preview": "I am leading hiring efforts for my small engineering team. We're looking for our third senior engineer (maybe five years of experience shipping code, and a little bit of time lead", "content": "

I am leading hiring efforts for my small engineering team. We're looking for our third senior engineer (maybe five years of experience shipping code, and a little bit of time leading some technical or pastoral efforts).

\n

Our technical interview process runs some one-to-two hours and starts with a problem. Something invented but plausible for a small, operations-software hybrid company. We introduce the problem in fuzzy human-friendly words, and then spend the rest of the interview turning it into well-defined terms. We codify it. And then we code (some of) it.

\n

I'm looking to see if a candidate has built quality software, collaboratively. Have they made sure they understood the messy meatspace malaise, and can they can devise some precise presentable platonic solution. Did they use good people- and then computer-words to describe it.

\n

Because we give such a tangible problem, we really encourage our candidates towards using classes. Classes also happen to be really good at organising code together, so we also encourage them everyday in the engineering team.

\n

This is Object Oriented Programming (OOP), and it's an old term. You're going to come across OOP in theory, if not practice.

\n

Yet having candidates arrive at \"this could be a class\", and not \"this would be good as a set of pure isolated functions procedurally chained together in this file\" has been hard. Bewilderingly hard.

\n

Experience writing and managing software can give you a good box of tools, if you're actively looking around you. I'm interviewing experienced software engineers and asking them to model some entities and their behaviour, and they're not reaching for classes.

\n

\"Yeah, I guess we can try to use a class\" feels weirdly unsatisfying.

\n

In my darker moments I despair - why is no one doing OO?

\n

Why have a quasi-random group of web software professionals repeatedly resisted one of the oldest, most common enterprise application patterns? I don't know. But I could make some cynical guess at notions of:

\n\n

Frameworks (Rails, Spring Boot), architecture patterns (MVC, MVVM), Books (Domain Driven Design, Clean Code/Architecture) all put Objects/entities/ models right there, obvious and near the centre.

\n

They're there because they add value. Not to fill pages or as homage to bygone software practices. Software engineering and computer science are a competitive ecosystem, and evolution would select against them if there wasn't something there.

\n

How is the industry producing young, competent, practicing professionals who struggle to model real world problems? Why is no one doing OO?

", "slug": "2022-08-18-why-no-oo"}, "2021-10-28-how-to-onboard-new-software-engineers": {"title": "How to onboard new software engineers without paying high interest", "author": "Thomas Wilson", "date": "2021-10-28T00:00:00", "book_review": false, "preview": "In the past four months I've hired about five software engineers (including interns). So I've been thinking about how we onboard new engineers to the team. This has been especia", "content": "

In the past four months I've hired about five software engineers (including interns). So I've been thinking about how we onboard new engineers to the team. This has been especially important because over half the engineers have never had an engineering job before, or even a job as a university graduate.

\n

This means that onboarding isn't just about introducing someone to the company or the engineering team, it's about bringing people into both their first \"proper\" job.

\n

It feels awesome that I can make someone's first experience as a software engineer so good. Or at least have the potential to do so.

\n

Tell you what doesn't feel super: the onboarding process. It takes a lot to introduce anyone to the way that professional software engineers plan, do, and think about work. It means that my time is spent teaching, not doing. And while teaching is doing, I definitely notice a loss of momentum and bandwidth in the (already quite small) team.

\n

A new engineer will land in your team anywhere between 0-90% ready to start contributing code to production. The goal of an onboarding process is to get that slider to 100%.

\n

I argue that slider is tending towards 0% unless you're effectively onboarding them. That is, if you bring someone onboard and then make cursory efforts to keep them get them up to speed, they'll slowly grind down to 25-50%.

\n

I also suspect it gets harder to move this slides close to 100% over time. Onboarding is like a high interest debt: if you're going to pay it, you'll pay less if you pay it quicker.

\n

In thinking about onboarding in our team, and in our company, there are a handful of insights that I think are worth sharing explicitly.

\n

Cook from chilled not frozen: If someone comes into a new job knowing the bare bones of the job (anything that's in their contract, who their manager is, and where they'll be working) ten they're coming in frozen. There's been no progression between the end of the interview process, and the start of the working process. I (very purposefully) run a pretty high-touch interview process, and by the time a candidate receives an offer, there's been some good rapport built between us and them. Making sure that the candidate knows exactly when and where they're expected in on their first day is table-stakes. Defrost it even further by setting clearer expectations and timeframes. Bonus points if you can CC their colleagues into these emails.

\n

Do it in person: we're a remote-by-default hybrid engineering team. Honestly I think that works great for us[^That's not to say it's easy. Remove work comes with its own challenges which are real and can slowly strangle a company or team] but onboarding should be done in-person, or as close to synchronously as possible. There are just so many little things, like using new Browser, using Slack not Teams, MacOS not Windows, that can make \"simple\" things deceptively hard. If you're doing something in person, or synchronously, you can put a real early stop to some rabbit-hole chasing. You also get the best feedback possible for improving your onboarding process.

\n

Read from a script: Despite doing it in person, have a really clear (ideally ordered) checklist of things that need to be done on the very first day of onboarding (accounts to create, software to download). New starters should have access to the checklist, but the checklist is not the interface. You, a human being, are the interface. Allow someone to synchronously ask questions, send emails and messages on the new starter's behalf.

\n

Have many checklists: I've written three lists for onboarding new engineers: accounts and software, a list of people they need to arrange meetings with, and the code deployment pipeline. Each of these have different time frames and purposes. Break things up, instead of having one big old long list.

\n

Complete the checklist ASAP: Focus should be on getting a new starter to the end of all the lists ASAP. Accounts and software should be as as close to complete by the end of the first day. We aim to have an engineer go through the deployment of a bugfix/quickfix ticket in the first two days (sometimes three days), and by the end of their first week I want them to have events in their calendar to meet everyone they need to.

\n

Force one-ones with the entire business: We're an engineering team in a highly ops-focused startup, and we're hybrid remote as a team, but distributed across three cities as a company. This means that the chance of water cooler chat is pretty low. I think there's incredible value in having engineers meet as many members of the team as possible, across as many functions as possible. This is especially important where internal staff are also users of the software you're building.

", "slug": "2021-10-28-how-to-onboard-new-software-engineers"}, "2021-05-06-weekly-39": {"title": "The Weekly #39 (or #1, whatever)", "author": "Thomas Wilson", "date": "2021-05-06T00:00:00", "book_review": false, "preview": "I\u2019m going to stop writing my \u201cthings I learned\u201d blog posts. They don\u2019t serve me in the way that they used to. As [I wrote recently](/blog/2021-04-27-excommunicate-your-ideas): kill", "content": "

I\u2019m going to stop writing my \u201cthings I learned\u201d blog posts. They don\u2019t serve me in the way that they used to. As I wrote recently: kill your ideas and side projects, gladly and without delay.

\n

Death is more of a transition, though. The things I learned this week post is becoming simply _The Weekly.

\n

I\u2019m not sure what I\u2019m going to use it to write about, I\u2019m going to take a few weeks to try some new formats out. Starting next week. This week I had to kill an old(-ish) friend.

\n

Thirty seven weeks ago (in August of 2020) I started writing a weekly blog post with a collection of random tidbits I had learned that week. I\u2019d also put music recommendations and any cool articles I had come across. It was a great way for me to justify the time I spent on random corners of the internet, and share my love for the world. There\u2019s just so much cool stuff going on. Bees cook their enemies, authors write seminal science fiction books over a summer in an Italian villa with other famous poets, some dudes stop millions of pounds worth of books from Gatwick airport.

\n

But I don\u2019t browse the internet as much anymore. If you keep looking at your screen the algorithms will keep serving you up content and it felt a) distracting, and b) like you would never reach the end of it. The algorithms are much less inclined to serve you up random historical facts, and much more inclined to show you snappy videos and hot takes. This is the problem with advertiser-driven models of business. But I digress.

\n

I hate homework, and browsing the internet, fighting against the gain of The Feed , started to feel like homework. The knack to a healthy side project is tricking your brain into thinking that it\u2019s not homework (it definitely is though).

\n

So I was doing something I didn\u2019t enjoy or want to do because I felt I had to. That\u2019s disingenuous. I don\u2019t want to be disingenuous and I want to spent my time on projects that fulfil me (even if I never do ship them).

\n

What now? I want to keep doing weekly posts. I get a lot from it. For the past two weeks I\u2019ve put out a post nearly every 2-3 days. I obviously don\u2019t need the impetuous to write this week. But some weeks I do. As much as I bemoan \u201cit feels like homework\u201d, sometimes we need that homework. Delayed gratification and all that.

\n

So I\u2019m going to continue writing weekly, and call them The Weekly. I\u2019ve got a few ideas about the kinds of thing I\u2019d like to write about, most entirely in the realm of non-fiction, but still distant enough from my day job that I\u2019m not just a software engineer all day every day. But hopefully something with a little more overlap to other areas in my life. Something where the algorithms of content can keep their tentacles away from.

\n

I\u2019m uncertain if I would like to write timely or evergreen content. I see the benefit in both. I have written both. Let\u2019s see.

\n

This is the The Weekly #39 (or #1 depending on how you count). It\u2019s taken me a few days to decide this was the best idea, and I don\u2019t much fancy trying to whip up something entirely new in the next two days. Accept this apology or don\u2019t.

\n

You should write If you are reading this don\u2019t write anything but think you might like to, or would simply like to write more, do it. Weekly. First thing on Saturday morning or last thing on Friday, pull up a chair to your kitchen counter, pour yourself a mug of something hot or a glass of something fun, and start writing. No one\u2019s going to read it anyway.

", "slug": "2021-05-06-weekly-39"}, "2020-10-31-things-i-learned-12": {"title": "Things I learned this week #12", "author": "Thomas Wilson", "date": "2020-10-31T00:00:00", "book_review": false, "preview": "- **This high fat diet**: Whales, like dolphins but also humans, are mammals. This means they feed their young with milk. As you would expect, the blue whale has the largest mammar", "content": "\n

What I've had on Rotation

\n\n

Cool Articles

\n", "slug": "2020-10-31-things-i-learned-12"}, "2021-02-26-things-i-learned-29": {"title": "Things I learned this week #29", "author": "Thomas Wilson", "date": "2021-02-26T00:00:00", "book_review": false, "preview": "- **This lineage of cats**: Chartwell House, in Kent, England, was the home of Winston Churchill. It's now owned and operated by the National Trust, a British institution, allowing", "content": "\n

What I've Had on Rotation

\n\n

Cool Articles

\n\n

Fun Things

\n", "slug": "2021-02-26-things-i-learned-29"}, "2020-11-27-things-i-learned-16": {"title": "Things I learned this week #16", "author": "Thomas Wilson", "date": "2020-11-27T00:00:00", "book_review": false, "preview": "- **These Tattoos**: In the late 1880s, a man called Sutherland Macdonald became the UK's first professioanl tattoo artist. Although he was already an artist, he started the tattoo", "content": "\n

What I've had on rotation

\n\n

Cool Articles

\n", "slug": "2020-11-27-things-i-learned-16"}, "2020-12-05-things-i-learned-17": {"title": "Things I learned this week #17", "author": "Thomas Wilson", "date": "2020-12-05T00:00:00", "book_review": false, "preview": "It's time of year again: Spotify have released their _Rewind_ - showing you what you listened to throughout this year. After the _year_ (or decade, or complete non-year, whatever h", "content": "

It's time of year again: Spotify have released their Rewind - showing you what you listened to throughout this year. After the year (or decade, or complete non-year, whatever helps you) that 2020 has been, I think a lot of people have looked to music for a bit of refuge, or good news, or distraction. Go and check yours out, it's a cool little use of data, presented in a really nice way. In other news, the UK has approved the Pfizer/BioNTech vaccine, and the first people should receive their doses in the next couple of weeks. Things are starting to look up, we may be over the hump of this.

\n\n

What I've had on rotation

\n\n

Cool articles

\n", "slug": "2020-12-05-things-i-learned-17"}, "2021-03-13-things-i-learned-31": {"title": "Things I learned this week #31", "author": "Thomas Wilson", "date": "2021-03-13T00:00:00", "book_review": false, "preview": "This week we celebrated International Women's Day. My love and support goes out to anyone who identifies with that label. Let's keep pushing for fair representation and pay, acknow", "content": "

This week we celebrated International Women's Day. My love and support goes out to anyone who identifies with that label. Let's keep pushing for fair representation and pay, acknowledgement of domestic labour as work, and maybe some systemic government-backed support for domestic abuse victims and sex workers that doesn't involve the police where it's not necessary. Anyway, here's a funny a bit by Iliza Shlesinger that I love.

\n\n

What I've had on rotation

\n\n

Cool Articles

\n", "slug": "2021-03-13-things-i-learned-31"}, "2021-08-11-things-i-learned-35": {"title": "Things I learned this week #35", "author": "Thomas Wilson", "date": "2021-04-11T00:00:00", "book_review": false, "preview": "The slightly cold-snap here in London continues. The optimistic sewing and sprouting that took place in my garden (such as it is in urban West London) have largely had to retreat t", "content": "

The slightly cold-snap here in London continues. The optimistic sewing and sprouting that took place in my garden (such as it is in urban West London) have largely had to retreat to the comfort of the indoors. Covid-related deaths continue to fall in the UK, as we begin optimistically opening up after a very long winter. I\u2019ve started to have more normal moments - more going into a (socially-distanced) office, going to (socially-distanced) gatherings of people outside of my household. With this spirit of early optimism (and copious tree pollen) in the air, let\u2019s begin:

\n\n

What I\u2019ve had on rotation

\n\n

Cool Articles

\n", "slug": "2021-08-11-things-i-learned-35"}, "2022-02-28-vibe-check-1": {"title": "Vibe Check #1", "author": "Thomas Wilson", "date": "2022-02-28T00:00:00", "book_review": false, "preview": "It's basically March and the days are finally getting longer! On Sunday, the sun was up to greet me as I made coffee. Tiny sweet peas and strawberries bud on the window sill. Th", "content": "

It's basically March and the days are finally getting longer! On Sunday, the sun was up to greet me as I made coffee. Tiny sweet peas and strawberries bud on the window sill. The flow of spring into winter feels miraculous.

\n

It's getting lighter, but it's secretly the coldest, wettest month. That's how it feels, I've no idea what the data says.

\n

Things I've done this month which have brought me joy:

\n\n

We're now in to 2022. It's begun, and the peace and hope of New Year's have fallen away. I find my head more full of ideas and problems, of managing a maturing engineering team in a fast-moving organisation. And also of a semi home-brew D&D campaign. Routine and way-finding are butting heads (I should write horoscopes).

\n

To my delight, I find myself still reading. Highlights this month include:

\n", "slug": "2022-02-28-vibe-check-1"}, "2021-04-27-excommunicate-your-ideas": {"title": "Excommunicate your ideas", "author": "Thomas Wilson", "date": "2021-04-27T00:00:00", "book_review": false, "preview": "Your side-projects deserve a decisive, merciful death at your hands. You dragged them into this world, you\u2019ll fling them out. And do it quickly.\n\nI want to talk about killing our m", "content": "

Your side-projects deserve a decisive, merciful death at your hands. You dragged them into this world, you\u2019ll fling them out. And do it quickly.

\n

I want to talk about killing our much beloved side-projects, and why this is totally a good idea. Then I want to talk about why this could be a terrible idea. I\u2019m not here for resolutions.

\n

There are two parts of my personality, plucked from the universe-scale D&D Players Manual, which make the question \u201cshould I carry on with this side project?\u201d difficult to answer:

\n
    \n
  1. \u00a0I like to flip-flop - just because you made a decision in the past doesn\u2019t mean it\u2019s the best decision, or that you owe your current time your past self. Your past self was probably dumb and optimistic anyway. What do you know now that you didn\u2019t know when you made the choice? Do you know that you\u2019re not enjoying yourself, that you don\u2019t have the money, that it\u2019s not worth the time or investment? Cool, just put your tools down. This kind of thinking got me out of working freelance, a decision I thought I would love but actually did not. Vive l\u2019empoi.
    2. \n
  2. I like to commit - if you\u2019re going to make a decision, act like you\u2019ve made the decision. Sometimes that\u2019s about writing a blog post about random things you learn every week even when you don\u2019t want to. Sometimes it\u2019s about finishing puppy school (with your dog, obviously), or building an MVP of that website you\u2019ve wanted to build since 2014. Inaction is a choice. Relaxation and space are a choice. You can commit to restoring some inner peace and spend every night for four months in silent meditation, or watching Netflix, or going on dinner dates with different friends. Or you can commit to learning a new language, reaching a new fitness goal, whatever. I really don\u2019t care what the goal is, but I like to achieve goals.
    3. \n
\n

These two make for often uneasy bed fellows. Not quite sitcom-worthy misanthropes, but the two can make it difficult for me to feel confidently happy or fulfilled. Second guessing? That\u2019s a lot easier.

\n

I am a front-end and full-stack software engineer by trade and craft. For the past several months I have been building DashDot, an iOS app for interval training. I started this project because it solves an actual problem I have, and because I wanted to try building something for a different platform.

\n

I\u2019m going to stop building that app. I\u2019m not going to caveat that sentiment with \u201cfor now\u201d or \u201cat the moment\u201d. I have excommunicated it from my life, and I have no intention to pick it back up, or open that Xcode project. I might do those things, sure. I might try again in the future. I just don\u2019t think I will within the next lunar cycle, and I\u2019m not setting any expectation to myself that I will, either.

\n

The minute I made that decision, I felt lighter. I was free from doing something that I had increasingly come to resent. I\u2019m not going to go into all the nerdy details about why I didn\u2019t like iOS development - but the short of it is that I do not want to do it. So I won\u2019t.

\n

Maybe I\u2019m weird and this is totally natural to some. Maybe some people love giving things up and can do so without nary a backward glance. You\u2019ll know we\u2019re similar people if hearing that you can do this, that you can simply stop, is a gleeful relief or reminder, not an obvious re-statement. Got a side project that simply isn\u2019t worth the investment any more? Great, kill it. No one\u2019s going to come looking for the body.

\n

Though the killing metaphor is satisfyingly dramatic, I think excommunication is the better analogy. The idea of the project isn\u2019t dead, I can still go back to it. You can start building your ideas again whenever you want. Instead, I\u2019ve made the choice to have no interaction with it: I\u2019m not going to design, build, refactor, or plan anything else to do with this project. It\u2019s going to take up no more of my mental time and energy. It has been banished from my kingdom of effort and attention.

\n

You might be ready to excommunicate when\u2026

\n

You ever catch yourself, mid-activity and think \u201cwait why am I doing this\u201d. How might you know when it\u2019s time to excommunicate that project from your life? Here are some smells I\u2019ve been looking out for

\n\n

But what if I just keep picking things up and putting them down?

\n

I\u2019m worried about being that guys who gets a new personality-defining hobby every other month. I don\u2019t want to be telling my friends how great it is to feel the wet clay between your fingers, and then eight weeks later consider my chances as a professional oboe player. There\u2019s nothing wrong with that, you have to pursue your own happiness in this life, but there\u2019s more than that.

\n

I worry sometimes that I jump between things, never finishing them or accomplishing anything with them. But also, massive spoiler alert, no matter how long your streak on Duolingo, you\u2019re still going to die. If you can wring joy from the scarce few hours we have on this giant hunk of space rock then, by all means, flit between things. Flit away. Keep flitting. This is hedonism, which I think gets a bad wrap and has a lot less to do with Roman orgies that you\u2019d think.

\n

However, if you only ever get a few steps down a road, or you only do something when it is interesting or enjoyable - we miss out on something.

\n

Vasari, the first art historian and also debut biographer of Leonardo, wrote in reference to the famous renaissance artist, architect, natural scientist, and polymath: \u201cif he had not been so variable and unstable, for he set himself to learn many things, and then, after having begun them, abandoned them\u201d. Leonardo was a flitter.

\n

If you\u2019ve got the mental horsepower of Leonardo (which I certainly don\u2019t), then the curiosity does us benefit. Even with his almost mystic mental capacity, and despite working in one of the most productive and talented eras of artistry in European history, Leonardo left behind very few finished paintings. He left behind a lot of notebooks, with questions and observations, and he undoubtedly pushed a thousand tiny journeys forward, but he rarely reached \u201cdone\u201d in his work.

\n

There are no more than eighteen surviving paintings which can be attributed to Leonardo (if you ignore all credible questioning on many of these works). Though to be fair his portfolio includes things like The Last Supper and Mona Lisa, possibly two of the most recognised pieces of western art. This is compared to the literally dozens of paintings by Raphael (who died at 37, a full thirty less life years than Leonardo), or Michelangelo who painted (or supervised) the entire ceiling of the Sistine Chapel\u00a0, which accounts for over 500 squared metres and then also he sculpted David. To be fair, Michelangelo was probably a bit too dedicated, and maybe could have loosened up a bit.

\n

Unfortunately, no one\u2019s really doing anything comparable to painting the Sistine Chapel anymore. I don\u2019t know why, maybe we\u2019re all too remarkable to be remarkable anymore, or maybe we\u2019ve become numb excellence. You\u2019re not sacrificing an era-defining oeuvre so you can go to an introductory macrame class or get three pages into your bullet journal before never opening it ever again. But I do still think we owe it to ourselves to commit a little before abandoning ship. The process of mastery and craft run deep in us, I think.

\n

That\u2019s because new hobbies or side projects are both themselves (i.e. making a clay pot, writing a book), but they are also meta-projects: the process of planning how you will dedicate your time and attention around them. The ability to engage with the terrible, awful imitation you have made and the shining exemplar you were trying to reproduce, and asking yourself \u201chow did I get this so wrong?\u201d. This is another time to mention The Gap by Ira Glass.

\n

If you hang around for long enough, you notice the transition from a project as itself, to a project as a meta-project. I think there\u2019s something inherently valuable in going through that, and I don\u2019t think you can force it.

\n

To give an example from my domain, when I dip into a lot of forums for web developers I see piles of novice engineers asking ill-formed, basic questions which either have a one-line answer (\u201chow do I get data from an API in python?\u201d) or no answer (\u201cwhich JS framework should I learn?\u201d). But a lot of the conversations I see happening between experienced engineers, or at talks from engineers - these are more philosophical or ideal. Broad, cross-technology approaches, team and inter-discipline management or integration. Once you have reached conversational fluency with the details, you can go one level higher. I really enjoyed learning the basics as an engineer but I am really enjoying the work of a journeyman.

\n

Similarly, with writing I deeply enjoy the feeling of having written, I dislike much of the reality of writing consistently. I love having a blog where I\u2019ve written consistently for nearly a year, but I hate the Saturday morning fear that this might be the week I don\u2019t write a blog post about things I have learned. I love organising thoughts after they lay strewn in a text document, having stumbled over each other in a rush to get out of my brain. I love that I nearly always have a conversation starter or something to mention when I\u2019m out at the pub. Or if I was out at the pub and there wasn\u2019t a pandemic.

\n

Some of these things are about the actual act of writing but others are, more broadly, because I write. And I think I have only come to enjoy these things, and to even see them in the first place, because I have committed to a regular writing practice. I don\u2019t think I would have got there if I decided to flit between ideas, or if I had committed to only writing when I feel like it or when something comes up. I do not know if I would even think to write something in the first place if I hadn\u2019t.

\n

Ultimately, it still doesn't matter, obviously. I\u2019ll be dust in a hundred years and no one cares if I do or don\u2019t commit to things, so long as I seem happy. But there is hope among all the fatalism. But I think the things you gain, and the muscles you exercise at the beginning of something are different to what\u2019s necessary when the motivation runs out and you\u2019re looking to improve. If those are the muscles you want to build, stop flitting.All this, of course, if you\u2019re able to healthily bare the cost of getting there.

\n

Sometimes the answer is a resounding and valid \u201cno\u201d, \u201cI really don\u2019t want to\u201d or \u201cI hate this\u201d. If it is, excommunicate the project from your life. Put it deep in that freezer.

", "slug": "2021-04-27-excommunicate-your-ideas"}, "2022-03-02-concentrate-on-concentrated-tests": {"title": "Concentrate on Concentrated Tests", "author": "Thomas Wilson", "date": "2022-03-02T00:00:00", "book_review": false, "preview": "The flavour of a test block lies in the calling of application code, and the assertions on its behaviour. Everything else (set-up, tear down, tidying, and side effects) dilutes a ", "content": "

The flavour of a test block lies in the calling of application code, and the assertions on its behaviour. Everything else (set-up, tear down, tidying, and side effects) dilutes a test. Work to prevent tests from being watered down.

\n

It should be as obvious to an incoming engineer exactly what part of the codebase is being tested, and exactly which parts of the testing-infrastructure (stubs, mocks, fixtures) are facilitating that.

\n

By contrast: a diluted test makes it hard to point to the grain of truth or value. Tests which are hard to understand are hard to change. Code which is hard to change won't get changed.

\n

If it's easier for an engineer to add a new test, rather than alter an existing one, they will. If it's unclear that a test already exists for something, that test will be duplicated.

\n

Diluted tests risk making your codebase bloated and brittle (too big and hard to change).

\n

Ask if you can make a test more concentrated by:

\n
    \n
  1. Creating multiple unit tests to test previously-grouped functionality
    2. \n
  2. Removing tests which make no unique assertions on your application code
    3. \n
  3. Herding your testing infrastructure out of individual test files to isolate repeated patterns or necessary magic
    4. \n
", "slug": "2022-03-02-concentrate-on-concentrated-tests"}, "2020-12-20-how-are-we-going-to-write-about-2020": {"title": "How are we going to write about 2020 from 2022 onwards?", "author": "Thomas Wilson", "date": "2020-12-20T00:00:00", "book_review": false, "preview": "2020 has been a terrible year in so, so many ways for so, so many people. At the very least, the Covid-19 pandemic has stolen a year from us all. I would say most of us have gone t", "content": "

2020 has been a terrible year in so, so many ways for so, so many people. At the very least, the Covid-19 pandemic has stolen a year from us all. I would say most of us have gone through a personal and collective trauma this year.

\n

I do not believe this year will be a turning point for us as a society. I don't think this will be the moment people stopped flying transatlantic for a 2pm lunch meeting in LA. In 2025 people in offices are going to be just as much a victim of presenteeism as they are now. We're not going to value our independent artists or our local pubs any more, we're going to frequent franchises and chains. We're not going to pay healthcare staff more and politicians less. We're not going to have a meritocracy in government and purely data-led policy. We're not going to learn all the lessons we need to learn to stop anything like this from ever happening again - because our collective memory is short, and because our minds are excellent at rationalising our actions to ourselves.

\n

I do believe that this is going to be a cornerstone in the life of everyone over the age of 14. This will be a comparison point for every freedom of movement we make, even if it's a fleeting memory as we board a plane or check into a hotel in 2050. We will remember the impact of distance in our relationships, and recognise the luxury of being inattentive to them. We will justify ordering aperitifs and dessert at restaurants. We will remember not being able to leave the house before we bid on a house with barely a fist full of dirt, or which is distant form our loved ones. We will consider it as we walk home, head-fizzy-drunk, from a friend's dinner party. The muscle memory in our hands and fingers will surface countless washings after getting home from any shop.

\n

As individuals we are going to remember this year, and a culture we are going to try and move on from it.

\n

How are we going to write about, and talk about this year in 2022?

\n

Other than the inevitable trend of clinical and popular postmortems and retrospectives; of memoir from political and healthcare staff; in coded language from press-releases (due to the global health situation) - how do we relay what this year is and has been? Are we going to want to pretend it never happened, or will it crop up in books, plays, music, movies, or series? Will it be examined, blamed or credited, or will it become kind of harmless shorthand which takes the sting out of the year?

\n

What are the analogies and comparisons you can draw on to explain this year? I have never experienced anything so physically and mentally stifling. There is no analogy for the drawn out uncertainty, the frustration, and the limited personal freedom, the conjuring of temporary hope and imagined futures almost solely to get us through a now which extends certainly backwards and hazily forwards.

\n

I think I'm leaving the year stronger than I came into it, but there was a real dip in the middle there where things could have gone either way. Despite being better off, there is space left in my life from the friends and family I haven't seen in a year, by the art I haven't witnessed, the meals I haven't eaten, the texts I haven't artfully crafted or \"accidentally\" ignored, the wine I haven't drunk, the music I haven't heard crammed into tiny spaces with bustling strangers and distorted speakers, the sunsets I haven't seen, the taxis I didn't take, the impulse purchases I didn't make, the hands I didn't shake and the embraces I missed.

\n

If you're lucky, the horrific scenes of crammed hospitals, overflowing wards, and people dying alone were fed to us through the screen or told to us by others. If we are not, we have lived them, or love someone who has lived them.

\n

I have lost no one I know and I have managed to find and maintain fulfilling employment. I have been lucky, but I mourn the passing of this year from my life in a way that I don't know how to vocalise. I do not think I have regressed as a whole, but parts of my life have.

\n

Doesn't every mental struggle feel like this, though? As though it could not be pinned down and showcased in words? In my experience, the feeling of being in a storm and then describing it afterwards are two very different skills. Once you're far enough way from something you can see the shape of it, its limits and reaches, with more clarity.

\n

I can't do that for 2020 yet. I can't write a eulogy for this year which I desperately want buried and refunded. I am too close, and the loss feels too fresh and not yet finished - it is December 2020 as I write this and I know more will be taken from me, and more still demanded.

\n

How long will it take for us to feel finally, firmly, like we can judge our vantage point far away enough to have some kind of valid, or at least semi-unused, criticism? Something other than a reaction.

\n

I feel as though maybe in the last two or three weeks we have broken the back of the Covid pandemic. With three vaccines approaching, or already reaching, approval.

\n

But perhaps the thing I have had to learn, and have seen us all trying to learn, over and again from this year is how little we can grasp time, or how poor we are at understanding and processing problems of this scale. That's not to speak of the people who make no allowance for the collective good, only for hedonistic and short-term impulses.

\n

How often we have been six weeks away form this all being over? How the creation, approval, distribution, administration of a vaccine will solve anything - when in truth each is a herculean effort of knowledge, logistics, and finances. The world is going to have to produce billions of doses of vaccines. Billions. Each of which as to get into a person's bloodstream, and administered during a pandemic.

\n

This year has felt entirely like waiting just that little bit longer. Like hanging on until the daily deaths and cases get below a set limit. Like things aren't good now, but we'll accept it because they will be.

\n

How are we going to write about that feeling and that uncertainty? How can words do justice to successive realisations that both the problem and the solutions are so much more complicated than anyone was saying - because nobody wanted to be the one to say them, to reduce the substance of our hopes.

\n

This has been a year of loss and trauma. We don't understand the full limit of either of those things, and how are we going to talk about it afterwards? Because there will be an afterwards.

\n

How long will it take for these things to seep into our cultural and personal narratives? And how will we, in the future, draw from them? Will they become like war poems we read once a year, and become synonymous with charities and remembrance services? Or will they become briefly loved and adopted as a way for us to make sense, or something good, from all this?

\n

I am very interested in how future us will write about this once it's passed.

", "slug": "2020-12-20-how-are-we-going-to-write-about-2020"}, "2020-09-04-things-i-learned-4": {"title": "Things I learned this week #4", "author": "Thomas Wilson", "date": "2020-09-04T00:00:00", "book_review": false, "preview": "- **This world**: The Word _Kipple_ is a word invented by SciFi writer Phillip K. Dick, to mean the kind of rubbish/trash that accumulates if humans don't intervene. [source](https", "content": "\n

Cool articles

\n\n
\n

I never think of stories as made things; I think of them as found things. As if you pull them out of the ground, and you just pick them up. Someone once told me that that was me low-balling my own creativity. That might or might not be the case. But still, on the story I am working on now, I do have some unresolved problem. It doesn\u2019t keep me awake at nights. I feel like when it comes down, it will be there...

\n
\n

What I've had on Rotation

\n", "slug": "2020-09-04-things-i-learned-4"}, "2022-09-13-wainwrights": {"title": "Listing all the Wainwrights", "author": "Thomas Wilson", "date": "2022-09-13T00:00:00", "book_review": false, "preview": "On a recent holiday in The Lake District I wasn't able to find a complete list of the [Wainwright fells](https://en.wikipedia.org/wiki/List_of_Wainwrights) online, in a concise way", "content": "

On a recent holiday in The Lake District I wasn't able to find a complete list of the Wainwright fells online, in a concise way that I could use to track the height and location of the hills.

\n

A few hours in the morning later and I've compiled a list here on GitHub. It gives you all 214 fells with their

\n\n

enjoy !

", "slug": "2022-09-13-wainwrights"}, "2021-01-09-things-i-learned-22": {"title": "Things I learned this week #22", "author": "Thomas Wilson", "date": "2021-01-09T00:00:00", "book_review": false, "preview": "This week the UK Government has brought us _Lockdown The Third_, a threequel in the franchise after the straight-to-TV movie that was the November lockdown. Cases, deaths, and hosp", "content": "

This week the UK Government has brought us Lockdown The Third, a threequel in the franchise after the straight-to-TV movie that was the November lockdown. Cases, deaths, and hospital admissions are at an all-time high in our country at the moment, with London in particular looking pretty scary. It might be the \"the last push\" like this (boy, I really hope it is the last push), but that doesn't help the healthcare workers being forced forward/backwards/downwards by this whole situation. So for goodness sake, just stay inside. Call out people who are making selfish choices. We're all making decisions for everyone else around us, it really is that simple. Arrange FaceTime calls, yoga sessions, happy hours, online games, book clubs, Netflix watch parties, and craft dates with people. Life isn't going to be normal for a while, but we're going to get through this together and then one day get irresponsibly drunk as we sit in or outside a pub until closing time with the people we love, and think about what life looks like now. Until then just... learn to crochet or cook or something.

\n\n

What I've had on Rotation

\n\n

Cool Articles

\n", "slug": "2021-01-09-things-i-learned-22"}, "2020-10-02-things-i-learned-8": {"title": "Things I learned this week #8", "author": "Thomas Wilson", "date": "2020-10-02T00:00:00", "book_review": false, "preview": "This week's _Things I learned_ is a little shorter than usual because I've been moving house. I hate every part of moving house. Anyway, enough excuses, here are some of the things", "content": "

This week's Things I learned is a little shorter than usual because I've been moving house. I hate every part of moving house. Anyway, enough excuses, here are some of the things I learned this week:

\n\n

Cool Articles

\n\n

What I've had on rotation

\n", "slug": "2020-10-02-things-i-learned-8"}, "2020-10-10-five-useful-questions-new-job": {"title": "Five (and a bit) useful questions to answer in your first week at a new job", "author": "Thomas Wilson", "date": "2020-10-10T00:00:00", "book_review": false, "preview": "I've just had my first week at a new job (I'm now a frontend software engineer at [Oxwash](https://www.oxwash)), which is cool. I find first weeks intense because I have to balance", "content": "

I've just had my first week at a new job (I'm now a frontend software engineer at Oxwash), which is cool. I find first weeks intense because I have to balance a) the immediacy of being introduced to everything and everyone in \"real life\", i.e. not an interview setting, for the first time, and b) trying to convey your long-term personal and professional ambitions to your new bosses without sounding like a career lunatic or emotionless psychopath.

\n

Managing long and short term goals is hard for humans to do, but worthwhile and rewarding when you get it right. Long term goals are rarely immediately relevant or present, it's not always easy to go from \"I would maybe like to be an engineering manager\" to an actionable thing. It's even harder to consider long term goals in chaotic situations, like when you're being introduced to new people, places, processes, technologies, terminology, and expectations. Plus the added complexity of trying to present yourself as someone who can totally stay afloat and cognisant during all the above.

\n

But if I don't have a long-term idea of who I want to be, even if it's subject to change, I worry that I'll be nudged into doing entirely what's best for the immediate concerns of others or the company. I would rather that my personal and professional development come from a dialog between what others need me to do, and what I think I want to be doing.

\n

For that reason, I came into the first week at a new job with a couple of personal and career-focused questions to help me understand myself and others. These questions ended up being really helpful to me, even if the answer to the questions is was a (polite) \"can we come back to this later?\".

\n

These are the questions I arrived at when I thought about all these things. They could be riffed on to help find something useful to you, or taken verbatim. I don't think their usefulness is limited to the first week at a new job, nor do I think they necessarily need to be asked to anyone other than yourself. The act of answering your own questions is a good little meditation (and it's at least 50% of the reason I try to write so much).

\n

So yeah, here are the five questions I came up with:

\n

Imagine 12 months has passed - what could I do that would bring the quality of my work from 'Good' to 'Excellent'?

\n

There are a couple of dangerous implications with this question, especially in a first week: it implies that you are capable of doing excellent work. You may well be, but it definitely sounds like you could be over promising.

\n

Despite that, I found this a useful question because it shows you how people understand, see, and value the kind of work you'll be doing. As an engineer, you'll get a different response to this question from people in management, product, operations, strategy, and tech. This is great - it shows you how the current tech team and offering are seen by the company at large, and how each person/team would define success.

\n

Another little life hack for you is that people rarely have a well defined, concise response to this question. You're probably not going to get told \"a 7.5% decline in response times over the next 12 months\" (obviously great if you do). Take a note of these points, of what people want, and use them when you're talking about, planning, and polishing tech internally.

\n

What does the company look like in 12 months, five years, and ten years?

\n

By default, your onboarding will give you a good idea about what you'll be doing immediately, maybe in the next 1-3 months. I found asking this question a great way to prepare me mentally for what I might be doing in the future.

\n

Asking this question to anybody senior in product or strategy (even in C-Suite, if you can) will help you understand what you'll be working on if you stay at the company for a longer (in startup years) amount of time.

\n

As before, this knowledge can help when planning and building software or roadmaps. Things will always change, and your software will always be somehow inflexible or caught off guard, but hopefully this question will help you minimise that.

\n

This question is most valuable in early stage companies, because of the difference between present and planned situation is probably quite large. I have intentionally joined an early stage company, and while they're definitely no longer struggling for product-market fit (if that's even a thing anymore?), the chance that they have already streamlined and perfected everything by now is pretty close to 0%. This is great - you can use your knowledge you're gaining in answering these questions to help get them closer to that goal.

\n

The caveat to this is that the uncertainty and unpredictability could mean that the longer-term projections or ideas are just words. Customers, economies, investors, management, talent, and global pandemics are all winds that will guide your ship. Don't get tied to these ideas, and keep a pulse on it - things can change fast and you'll have to learn when to stick to what you've learned and when you need to learn new lessons.

\n

When, and how, is my performance going to be evaluated?

\n

This is probably the most boring of the questions, because it is self-serving. However it is important to know how you're going to be assessed, because you want little to no concern about losing your job, failing your probation, or what not. At the end of the day, any good company is going to be equally critical and supportive in examining your work, and feed back to you. This is naturally uncomfortable enough, and so the least you can do is make sure it's not happening against \u2753mystery criteria\u2753.

\n

The answer to this question won't be relevant until you start digging in to actual work. I would still recommend making a note of it. It might encourage you to keep a better log of work you've done, problems you've faced, ways you've improved, or whatever. It might let you know about the company's culture around sharing, feedback, and openness.

\n

If I'm struggling or have problems, where do I go?

\n

This is the kind of thing you want to know before you need to know it. It might be your direct manager 95% of the time, but it's always good to have an idea about where to go if you were to have a problem with your manager.

\n

Get a sense for which people are best for which problems: management questions, tricky technical work, variable mental health, and ongoing family problems will at some point affect your work. Understanding who needs to be told what, and what kind of support can be offered (internally or externally) is a good thing to suss out.

\n

What are your immediate team's backgrounds and interests?

\n

Get to know your team, as much as this is painfully obvious, it's surprisingly easy to forget in the chaos of starting a new position. Allow these conversations to happen naturally during your first couple of days working alongside your new team. Don't come in with forced or canned one-liners with your team, this is your first week not a corporate retreat.

\n

I found it useful to get a broad idea about who my team is and what they find interesting. This goes for personal as well as professional interests. We're all complex, complete humans and you'll find something to bond about, even if it's just the weather, crowding on the underground, or the best kind of milk to have in coffee.

\n

Knowing what people do/not know, or where they are/not confident could help you phrase future feedback or explanations in a slightly different way. I'm not always great at asking for explanations of basic terms when someone explains something at a million miles an hour, and I know some people feel similarly. Likewise, when you need feedback or clarity on something, it's good to know where to go in order to get it.

\n

Bonus Question: Does anybody have any dietary requirements or allergies?

\n

If you're a cook or a baker you might want to bring in some sweet treats now, or in the future. It's always a good idea to know if anyone's going to be excluded, or mortally threatened, if you bring in a particular kind of baked good.

", "slug": "2020-10-10-five-useful-questions-new-job"}, "2021-01-23-things-i-learned-24": {"title": "Things I learned this week #24", "author": "Thomas Wilson", "date": "2021-01-23T00:00:00", "book_review": false, "preview": "- **This fitness research**: I've long been a fan of interval training to help improve my running and cycling speed. High intensity interval training (HIIT) is a method of training", "content": "\n

What I've Had on Rotation

\n\n

Cool Articles

\n", "slug": "2021-01-23-things-i-learned-24"}, "2020-12-27-things-i-learned-20": {"title": "Things I learned this week #20", "author": "Thomas Wilson", "date": "2020-12-27T00:00:00", "book_review": false, "preview": "This week's post comes a little lighter, on account of it being Christmas and all. I didn't want to break a streak, but also I want to get back to eating far too much and doing far", "content": "

This week's post comes a little lighter, on account of it being Christmas and all. I didn't want to break a streak, but also I want to get back to eating far too much and doing far too little. So let's get on with it:

\n", "slug": "2020-12-27-things-i-learned-20"}, "2021-05-05-customer-centric-like-a-robot": {"title": "[LinkedIn Post] Being so customer-centric your customers think you\u2019re a robot", "author": "Thomas Wilson", "date": "2021-05-05T00:00:00", "book_review": false, "preview": "(This is a cross-post of [a short article I wrote on LinkedIn](https://www.linkedin.com/pulse/being-so-customer-centric-your-customers-think-youre-robot-wilson))\n\nStop me if you\u2019ve", "content": "

(This is a cross-post of a short article I wrote on LinkedIn)

\n

Stop me if you\u2019ve heard any of these: \u201cyour call is valuable to us\u201d\u2026 \u201con a scale of 1-10 how would you rate our\u2026\u201d, \u201dat {companyName} we care deeply about our customer experience\u2026\u201d

\n

Have you literally ever believed anybody when you\u2019ve heard or read these things? I have not. Not even once.

\n

But we should care. I know Oxwash does. We care a lot that people send us their wedding dresses, bedding, favourite band Ts and home team jerseys. It\u2019s one of the top three reasons I decided to work at Oxwash - everyone genuinely cares \ud83d\udc99 I\u2019m a front-end engineer, I make software that real customers use every day, and I care that they have a good experience. At very least I care that we should know if our software is confusing our new customers.

\n

\ud83d\udc47 The good news is, it\u2019s actually really easy to stand out. Literally all you have to do is act like you\u2019re a human being who cares. So I\u2019m bringing four tips on how to talk with your customers like you\u2019re a human who actually cares about them

\n
    \n
  1. \ud83d\udd75\ufe0f\u200d\u2642\ufe0f Focus on who you want to talk to: You\u2019re not going to be able to talk to everybody all of the time. You have other things to do. I started talking to first-time Oxwash customers. It\u2019s enough that I\u2019m fielding e-mails every day, but they\u2019re not banging down my door. I think it\u2019s really important your software is understandable to first-time users. If they don\u2019t stick around long enough to learn the\u2026quirks of your system then there\u2019s a problem. You might care about your longest customers, or those in a certain age range or who work in a certain sector. Start small, you can always go bigger.
    2. \n
  2. \ud83e\udd16 Automate (but not too much): How many e-mails in your inbox were hand-crafted and delivered by artisanal humans? Probably less than half. Use automation services to send-off e-mails based on database and software events. Use snippets (shoutout to TextExpander and SuperHuman) so that certain thing (like instructions on how to update your version of the app in the App Store) aren\u2019t hand typed every\u2026 single\u2026 time. But always, always put something hand-crafted into a reply, especially when someone\u2019s taken the time to send you useful feedback.
    3. \n
  3. \ud83c\udf81 Share your findings: We now run monthly reviews with product, strategic, and technical staff. Every single bit of feedback (critical and complementary), every suggestion, every point of contention is brought up and discussed with real humans so that we can do something with that information.
    4. \n
  4. \u23f3 Respect people\u2019s time: Every e-mail I send asking for feedback always gives people the chance to reply with \u201c1\u201d, \u201c2\u201d, or \u201c3\u201d (which stand for \u201cgood\u201d, \u201cbad\u201d, \u201cI\u2019m too busy at the moment\u201d). I\u2019d love a considered and detailed response from every customer, but I\u2019ll settle for more data overall, if it means sacrificing a bit of depth. Trust me, people love telling you what could be improved, but rarely care to gush about your software to you.
    5. \n
", "slug": "2021-05-05-customer-centric-like-a-robot"}, "2020-03-22-why-i-chose-react-native-for-app-in-2020": {"title": "Why I chose React Native to build a new app in 2020", "author": "Thomas Wilson", "date": "2020-03-22T00:00:00", "book_review": false, "preview": "I am currently in the process of building herabouts - an app that\u2019s like a tour guide, only cooler. Most of my previous engineering work has been web-based (react and vue) because ", "content": "

I am currently in the process of building herabouts - an app that\u2019s like a tour guide, only cooler. Most of my previous engineering work has been web-based (react and vue) because the internet is an accessible and very capable system for building modern applications. However hereabouts needed certain native functionality - like location, reliable offline data access, battery status, and access to the camera. Yes some of these things are possible on the web, but they\u2019re much more native functionality.

\n

I\u2019ve made the decision to write the app in React Native - a library for creating applications for native platforms (like iOS and Android) using React and JavaScript.

\n

I wanted to share the reasons I made this decision because despite having worked with React Native for clients in the past, I was cautious about adopting it for a personal project. AirBNB famously abandoned React Native in 2018 citing a couple of pretty damning reasons: long initialisation and first-render times; lack of code-sharing between platforms; mixed developer experience.

\n

In the same post, however, they say that most (80%) of their devs found the experience at least slightly \u2018positive\u2019 (subjective as that is), and acknowledged that a lot of their problems may relate to the the size and complexity of their team and product, alongside the early nature of React Native at the time. In the years since that was published, React Native and the surrounding ecosystem (like expo) have made the development experience of making a native app a lot better. Big tech companies, like Shopify, have also adopted React Native.

\n

It\u2019s never a clear choice what tech to use, and it\u2019s especially difficult when you\u2019re starting something new and have no constraints. So I wanted to make sure I was making an informed decision, and this article outlines that process.

\n

Why not native-native?

\n

I initially started working on hereabouts as a native iOS application, written in Swift. At present (March 2020) Apple are transitioning the way UIs are written in Swift to use SwiftUI. The API for SwiftUI is still in beta (currently beta 4) and still has a few quirks (e.g. see this Reddit post) that made the process of building an app cumbersome and awkward. I was unsure of the relationship and split of responsibilities between the existing UIKit, storyboard, and SwiftUI. Given how SwiftUI is largely seen as the future of iOS development (and its declarative philosophy shared by react), I didn\u2019t want to tie myself to supporting an app written without it, nor did I like the possibility of having to maintain a hybrid UIKit/SwiftUI app where the roles and responsibilities of both parts were changing regularly.

\n

This opened up the possibility of creating my app using a cross-platform library - not because I wanted a cross-platform app, but because I wasn\u2019t happy with the native tooling. This just happened to open up the Android market. Previously I made the decision to focus on iOS over Android because a) I am personally all in on the Apple ecosystem, and b) more money is spent in Apple\u2019s App Store and in the Google Play store. Although I\u2019m not making hereabouts to get rich, I\u2019d certainly like some gin money.

\n

Reason #0: I already know React

\n

The simplest reason for me choosing React Native, over say NativeScript or Flutter, is that I already know React. I\u2019ve got experience writing production and personal static websites and enterprise apps in it. The declarative and data-bound nature of writing React, especially with TypeScript, comes quite naturally to me now.

\n

NativeScript supports Angular and Vue as first class citizens, which I simply don\u2019t use as much as React. I started off my Frontend Engineering career writing apps in Angular, and I\u2019ve written a couple of fast and easy websites in Vue. They\u2019re good frameworks, but right now I think React has a large (if not consistently good) community. I know how to handle complexity in React, and I have opinions about styling and architecture that React doesn\u2019t fight.

\n

Additionally, Google has a reputation for sunsetting projects with little notice, which makes me a little apprehensive about Flutter.

\n

Reason #1: React Native isn\u2019t a hybrid WebView app

\n

Many people\u2019s gut reaction to creating a cross-platform app is to think of something laggy, and distinctly un-native. One of the simple and earliest approaches to adopting cross-platform mobile development was to use web technologies, which are famously cross-platform and system agonistic, and have the native app render the web app (in its own HTML, CSS, JS) through a WebView. This is how platforms like Ionic and Cordova work - and they\u2019re great for very simple apps, but they\u2019re notoriously not very performant.

\n

Native apps are better than, and distinguished from, websites by how \u201csnappy\u201d they feel - how responsive the app is to a button being pressed, giving haptic feedback, and then navigating somewhere. It\u2019s hardly noticeable when done right, but when there\u2019s a 400ms delay between pressing a button and seeing something happen - you will notice.

\n

However, React Native works differently: you write your views using JSX, and these are then bridged to native code for iOS and Android - meaning, at some point, it becomes native, and is not just a DOM.

\n

Let\u2019s just take a second to clarify some of these words: first JSX is an extension to JavaScript (or to give it its full title: ECMAScript) that introduces XML-like syntax for creating structured data. It looks an awful lot like HTML, but with a few syntactic differences, and the ability to include data in the structure:

\n

```\nimport React from \u2018react\u2019

\n

const Message = () => {\n return (\n

\n

Hello!

\n

Welcome, friend

\n
\n )\n}

\n

export default Message\n```

\n

JSX is syntactic sugar - its goal is to makes the code easier to write and parse by the humans who have to read and write it. It\u2019s also a separate library from React and React Native, but is used by both libraries by default as a way to construct a virtual representation of view elements, like HTML Elements or DOM Nodes. It compiles down to something different, and instructs React to do React-y things like createElement() but we\u2019re not talking about that here.

\n

The second term I want to bring out and talk about is bridging. For an application to run natively, it has to be able to talk to the system in a language and API it understands: e.g. UIKit and Objective-C/Swift for iOS, and android.View with Java/Kotlin for Android. This is a distinguishing factor between cross platform apps (like those in React Native) and the hybrid WebView Apps - we can use a cross platform application to communicate with native APIs, like maps or device orientation.

\n

The part of the architecture that lets a JS thread, where a React Native application runs, talk to the native Threads, is called the Bridge. The details of how this works are covered for both iOS and Android in the React Native docs and aren\u2019t really relevant for this discussion - just know they happen.

\n

This article isn\u2019t an explainer about JSX (but JSX is a interesting idea, regardless of what you think about React itself) or Bridges - but they\u2019re two big technological differences between React Native and other libraries that let you use web technologies to write apps.

\n

Reason #3: The performance and benchmarking discussions are nuanced

\n

One of my core beliefs (read: something I work very hard at, but am not necessarily always good at) is only releasing/selling products that I would be happy for someone to pay for. Above all other things, I want hereabouts to have a native feel - to be responsive and feel intuitive to use. It needs to hit that magical 60fps bar, and feel like a first class citizen on a mobile phone because that is what I would expect from an app that I paid for.

\n

I\u2019ve seen a couple of blog posts that (like this one from inVerita, and this one from Thoughtbot) about the performance of React Native that had me worried that I\u2019d be fighting an uphill battle to get performance two where I wanted it.

\n

Fundamentally, though, good performance in React Native is possible. It requires a thoughtful consideration around what you\u2019re doing, and building with the tools that let you investigate and profile your app to let you know when there\u2019s a problem.

\n

It\u2019s much easier to read an article and see how React Native (or any tech) \u201chas bad performance\u201d but this depends too much on what you\u2019re doing and how you\u2019re doing it. It\u2019s a nuanced discussion and it also gets at the whole \u201csoftware engineering is a skilled profession\u201d thing. The research I did in this area was enough to assure me that I can code myself into a bad situation, but I can code my way (at least mostly) out of it.

\n

So I\u2019m not overly concerned about poor performance in hereabouts just because it\u2019s written in React Native. Of course I am concerned about it, but I don\u2019t think this is a problem unique to the platform.

", "slug": "2020-03-22-why-i-chose-react-native-for-app-in-2020"}, "2020-10-24-writing-for-recipe-cards": {"title": "Tiny thought: Writing for recipe cards", "author": "Thomas Wilson", "date": "2020-10-24T00:00:00", "book_review": false, "preview": "_Tiny Thoughts_ are little (500 word) essays. They're concise.\n\nI've spent the past three months consciously trying to write and read more. I want to improve my ability to refine a", "content": "

Tiny Thoughts are little (500 word) essays. They're concise.

\n

I've spent the past three months consciously trying to write and read more. I want to improve my ability to refine and communicate thought, and doing it in public helps motivate me to produce work.

\n

One of the hardest problems I find myself addressing frequently is my desire to over-explain or provide too much information. I have read many times that good writing is about being concise. Being direct and undistracted help you get your point across. You're not tiring the reader, and you're not brining in unnecessary information. Being concise is good.

\n

A few weeks ago I was listening to the JS Party podcast, a show I subscribe to but often skip. I picked up this episode because its title, Content is Queen, seemed relevant. I don't see my writing as content, but I know other people view theirs that way - and so I listened it.

\n

Something that came from that episode, which I really liked, was the idea that you should write like you're creating a small recipe card. It's a good analogy, and it implies the following things to think about when you're writing:

\n
    \n
  1. Realise sometimes you're trying to get to a point or a result, you're not trying to be witty or identifiable in your writing style.
    2. \n
  2. Identify and sign-post the most important steps in a process, or points in an argument.
    3. \n
  3. Figure out how to your points reproducible, undeniably clear, and re-usable.
    4. \n
  4. Condense your points down to as small a number as possible, you're writing for a small recipe card.
    5. \n
\n

I don't know how well these items hold for longer pieces, or opinion pieces. Sometimes you want to let your personality shine through in your writing, and sometimes you can let yourself wander. That said, I've been working a lot harder on deleting sentences, rather than adding them in, for the past month or so. I think that's, at least in part, because of this little realisation.

\n

You can see the full transcript for the episode on the episode page, but the original quote comes from Stephanie Morillo that sent me on this thought is:

\n
\n

You know the recipes you get with a Blue Apron or a Sun Basket subscription? They fit on a card, right? And they\u2019re not superfluous and they\u2019re not using all these great words. Every word there is there for a reason, and they\u2019re not gonna give you the back-story and all that fun stuff. They are \u201cYou've gotta do this, you've gotta do this, you've gotta do this.\u201d But the great thing is that as a result, you pretty much don\u2019t mess up the recipe.

\n
", "slug": "2020-10-24-writing-for-recipe-cards"}, "2022-06-18-why-add-complexity": {"title": "If simple is good, why do we add complexity?", "author": "Thomas Wilson", "date": "2022-06-18T00:00:00", "book_review": false, "preview": "Five years ago when I was writing software I was working around the question \"what should go in this file?\". Now it's more often \"what _thing_ am I making, and where does it fit w", "content": "

Five years ago when I was writing software I was working around the question \"what should go in this file?\". Now it's more often \"what thing am I making, and where does it fit with the other things?\".

\n

As a more experienced engineer, my decisions about what things we have, and where they live, start sticking around. Sometimes people do what I do because they're good ideas (my fave), sometimes because they're the better ideas (not ideal, but fine), and sometimes because they're my ideas (worst, do not do).

\n

I'm describing software architecture. The code garden ecosystem grows, from the helpful-est little utility functions to the scariest (wobbliest) experimental orchestrators. Software architecture is about naming and grouping things, acknowledging complexity and putting it in the right (least worse, most obvious) place, and making sure all the beautiful creatures play nicely and the earth-worms don't over-aerate the soil or whatever.

\n

I learned to do this by writing code with very thoughtful people, and reading books written by very thoughtful people. Do both. Do not do one without the other.

\n

Still, I make a lot of choices based on intuition, or smell. Some approaches smell right, others feel wrong and make me feel nervous. When a less experienced member of the team asks for an explanation when I raise these feelings, that's often all I can say: \"this feels better\".

\n

The most useful conversations happen when I say something like \"I don't like the alternative\".

\n

\"The alternative\", a lot of the time, is something more complex. Some layer of abstraction (what if we had a Currency class that could format this string?) or indirection (what if this Uploader service called an S3 service which called the logging service, and we handled progress monitoring there?).

\n

Simple architecture is better. If it's easier to explain to someone, it speeds up onboarding. If it's easier to keep in your head when you're writing code, it speeds up the individual/pair. If it's easier to spot a broken or misplaced thing, it speeds up debugging. If it's clearer where new code should be added, or existing code modified, work is faster.

\n

We have two phrases for when we forget that simple is better: Speculative Complexity and Premature Optimisation.

\n

Do whatever you can to recognise and prevent speculative complexity and premature optimisation. If you do not, you are committing your future self to more hours, and probably more suffering. You are increasing the amount of future work.

\n

Yet, when I arrive at an architectural points for discussion with a less experienced engineer, their gut reactions are often towards adding complexity. I'd put good money on it being at least 60/40 bad-good, with a higher frequency of bad choices when code is farthest from a feature.

\n

If simple systems are better, why are they something we have to learn? Why aren't they self evident, like weak coffee or bad paintings?

\n

I've had enough of these conversations now to recognise patterns. Knowing these patterns helps me guide conversations towards a resolution.

\n
    \n
  1. It makes us feel clever.. Honestly, who doesn't love a really gnarly, technical solution to a problem. This is prime form-over-function, or a belief that our job as engineers is to write code (not solve problems). Resolution: build a shared understanding of \"good\" as something which solves the problem, and is readable and comprehensible to other engineers.
    2. \n
  2. Understanding the problem is hard.. If you're writing software to solve a problem, it's probably a non-trivial problem. Even worse, long-lived systems quickly become Edge Case Central (what happens when the user is an admin using the same email address as a non-admin user where the non-admin user signed up first?). Resolution: fingers off the keyboard immediately. Do whatever it takes for both engineers to internalise the problem, its cause, and its effects. Whiteboard, write a document, build a glossary, whatever you need to do. Once you've done that, fingers can approach the keyboard.
    3. \n
  3. \"It will help us in the future\". This is the premature optimisation/speculative complexity case. It's easy when we're in the weeds to think \"well this works now, but what happens when we have 100x the concurrent users?\", and then build for that. The problem is: that world isn't the one we're in, and we don't know how fast we'll get there. Resolution: get data on the current state of play, e.g. how many concurrent users do we have now? Look at how (un)likely your supposed growth is, talking to a non-engineer if you need to. I've never had this conversation and realised \"oh shit, we do actually need to buff this of 100x growth in the next two days\".
    4. \n
  4. It's easier to write than modify.. Reading someone else's (old, probably imperfect) code is hard. It is easier to add than it is to subtract or modify. Worse, engineers mistake imperfections and best-efforts as best-practices which can't be touched. Resolution: dig into the code around the current feature work from start to end (soup to nuts). Do not write anything except missing tests around existing functionality until you have done this. When you publish code you know is imperfect and early-draft, leave a comment and communicate to your team.
    5. \n
", "slug": "2022-06-18-why-add-complexity"}, "2021-04-12-dash-cycle-01-reorganising": {"title": "Dash Cycle #01: (re)organising", "author": "Thomas Wilson", "date": "2021-04-12T00:00:00", "book_review": false, "preview": "I'm building DashDot: a privacy-focused interval training app that doesn't suck. The second cycle of development lasted March 15 - April 12. Let's look at where we are.\n\n## Goals\n\n", "content": "

I'm building DashDot: a privacy-focused interval training app that doesn't suck. The second cycle of development lasted March 15 - April 12. Let's look at where we are.

\n

Goals

\n

Here are the things I wanted to achieve in this cycle:

\n
    \n
  1. \u2705 Finalise the code architecture and restore tests
    2. \n
  2. \u2705 Allow someone to complete a (timed) timer
    3. \n
  3. \u2705 Focus on the persistence of timers and workouts. Make sure that relationships between these entities are persisted.
    4. \n
  4. \u2705 Buy domain names (for app and company)
    5. \n
  5. \u2705 Decide on ticketing / management software and method. JIRA vs. Linear
    6. \n
  6. \u270d\ufe0f Solidify and scale-back the UI design
    7. \n
  7. \ud83d\ude45 Make the UI nice
    8. \n
  8. \ud83d\ude45 Continue with TDD and high test coverage
    9. \n
\n

Designing Code Architecture

\n

This cycle I started running into the limitations and assumptions of my previous software architecture. Four weeks ago I did not have any strong opinions or experience on architecture for a SwiftUI app, but now I do. I wrote about my experience with this pretty extensively elsewhere. In summary, I've taken a very Rails-esque approach to the design: splitting my software into models, views, view models, and interfaces. Dividing by function rather than domain model will make some people mad, but it's actually really helped keep everything clear in my head.

\n

I ended up doing a pretty major refactoring of the architecture, which mean that a lot of my previously-written tests were no longer useful, and had to be deleted. I was only attached to them via the sunk-cost fallacy, so away they went.

\n

I also got to draw some pretty gnarly, sprawling UML-style diagrams in this process to help me really flesh out my thinking. That was cool.

\n

I've still not reached the same level of test coverage as I had before, but I do have a much more readable and consistent code architecture so I think the pros outweigh the cons.

\n

Allow someone to complete a timer

\n

Creating a timer and doing a workout are the two core workflows in DashDot. This cycle I focused on that user journey: letting someone select a timer they wanted to complete and then start doing it.

\n

There are a couple of complications here (obviously) but this workflow now functions. In DashDot you can now select a pre-existing timer, and start doing it. The app will persist your progress and process as you go, and progress you through the intervals, etc.

\n

So far you can only complete timed intervals (not distance). That'll be one of two focus points for Cycle#02.

\n

Persistence and relationships

\n

I spent a good few days really getting into CoreData, managed object contexts, and the ORM-like way of managing relationships between entities.

\n

DashDot now persists records of your activities, your workouts, and your timers - all without any fuss. This is an essential feature and I'm glad it's done

\n

I have created an Active Record-like pattern for my business entities, as I didn't like the idea of manually modifying the generated classes from CoreData. This allows me to have some helper methods on my models to access related data, and to treat what's in the persisted CoreData layer as DTOs. This is definitely my web influence coming through: treating the data persistence as dumb and largely stateless objects. I'm not sure if this is the best, or most Swifty, way of doing things - but it's the way that lets me move faster.

\n

Purchase domain names

\n

I needed domain names for both the app and for the company I'd be publishing it under. I've purchased both of those and I'll share when there's actually something on them.

\n

Project management: JIRA & Linear

\n

I had previously been using JIRA to manage my tickets and things to do. I discovered Linear (I think because someone on Under The Radar mentioned it).

\n

I've completely switched to Linear for managing my tasks. I like it because:

\n
    \n
  1. It has a native app, even if it's just an Electron wrapper, it feels surprisingly native
    2. \n
  2. It's free (for me a one-person team)
    3. \n
  3. Phenomenal keyboard shortcuts that let you move between tasks and screens, update and create tickets, and do all sorts.
    4. \n
  4. Their idea of \"cycles\" fits almost perfectly with how I want to think about software development. They're essentially four-week sprint-like phases. You pick a four week period, acknowledge what you can/not get done during that, and make sure things stay in scope.
    5. \n
  5. Nice integration with GitHub - generating branch names for tickets and tracking their progress through PR to merge status. Even working as a one-person team, this helps me focus on \"one things at a time\".
    6. \n
\n

Using Linear comes with a lot less friction than JIRA.

\n

Scale-back the UI

\n

I had a bloody massive Figma file with a whole bunch of screen prototypes and idea exploration. By the time I had spent four weeks doing more code-heavy tasks I had lost track of what was where, what I liked and didn't like. There was too much in the Figma file and things were too hard to find.

\n

So I copy-pasted everything into an \"archive\" tab in the file, and largely started from scratch. I used a more simple and iOS-like design. It's a lot more boring, yes - but it's also a lot more achievable.

\n

Every now and then I go back to the archive and look to see if I had any interesting UI ideas, bits of data, or conventions that I'd like. In general however I am trying to stick to a very simple and limited UI. No fiddly bits or tricky bits, I want to get something out there.

\n

I have started this process of redesign, and it'll continue into Cycle#02. The UI I have in the app at the moment is... not good or consistent, but it is functional for testing. So I need to improve it.

\n

I've become a lot more involved and aware of the iOS-specific design scene. Reading a lot of app reviews and listening to podcasts so I can get a better sense of \"what makes a well-designed app\".

\n

Make the UI Nice

\n

I wanted to have a fully redesigned and implemented UI by the end of this cycle. That did not happen, I had other things to do. I'm working on it though.

\n

Continue TDD

\n

I wanted to continue to develop with tests are the forefront, however the severe refactoring and reorganisation I've done have left a lot of my old tests useless, and I decided to move with greater speed by not having as many tests before I commit code.

\n

This decision will come back to bite me, I'm sure, but I want to focus on producing something usable and interactable. The code is not the message, the code is the vehicle.

", "slug": "2021-04-12-dash-cycle-01-reorganising"}, "2022-02-22-atomic-habits-is-a-really-good-book": {"title": "\ud83d\udcd6 Atomic Habits is a really good book", "author": "Thomas Wilson", "date": "2022-02-22T00:00:00", "book_review": false, "preview": "I spoke to thirty founders, and they all do these three things before breakfast.\n\nMy nine journaling prompts for other CEOs and founders\n\nOne rule for flawless interviews.\n\n[and so", "content": "

I spoke to thirty founders, and they all do these three things before breakfast.

\n

My nine journaling prompts for other CEOs and founders

\n

One rule for flawless interviews.

\n

[and so on]

\n

Habit hacks are catnip to a certain kind of self-improvement/business-guru people. I actually got pretty involved in these kinds of articles earlier in my career, so it'd be wrong for me to judge.

\n

I think these kind of articles (or titles for articles) work because i) they make people feel smarter than other people, and ii) they promise great results with low input.

\n

Maybe three weeks ago I'd get snarky about how better results isn't a knowledge problem. I don't think knowing more equates simply to more and better work. \"Keep running\" won't unconditionally get anybody to the end of a marathon.

\n

After reading Atomic Habits (by James Clear), I was reminded of the best of these articles. Clear helped me remember the generous interpretation for why these articles get written, read, and perform so well on social media: little decisions, stacked and reliably repeated, make big changes about who we are and what we can achieve.

\n

The platonic ideal of good habits are tools that help us become the version of ourself we want to be, and produce the highest quality work we can.

\n

But still, the problem isn't knowing what three things to do before breakfast, it's programming yourself to do the activities over and over again.

\n

We all want that. And Clear dedicates a whole book to giving us the tools to get there. I want to surface the parts of Atomic Habits that resonated with me:

\n
    \n
  1. The rules for forging and breaking a habit.
    2. \n
  2. Call out your automatic actions / lazy behaviours.
    3. \n
  3. Decide what kind of person you want to be.
    4. \n
  4. Monkey brain makes decisions but is easy to trick.
    5. \n
\n

1. The Rules

\n

Clear gives us four rules for making and breaking a habit. To make a habit we must:

\n
    \n
  1. Make it obvious
    2. \n
  2. Make it desirable
    3. \n
  3. Make it easy
    4. \n
  4. Make it satisfying
    5. \n
\n

And to break, we invert:

\n
    \n
  1. Make it invisible
    2. \n
  2. Make it undesirable
    3. \n
  3. Make it difficult
    4. \n
  4. Make it unsatisfying.
    5. \n
\n

The what and why of each of these rules is the whole point of the book. Read the book, you'll find helpful stuff in there.

\n

2. Call out your automatic or lazy behaviours

\n

Our laziness (and the purposefully crafted and endlessly revised systems devised by social media and engagement-driven advertising that take advantage of that laziness) mean that we do a lot of things without really thinking. Without even realising.

\n

Come home, sit on sofa, reach for the remote, and turn on the TV. Open a new tab, type faceb and have your browser take you to Facebook. Open your phone and check twitter. Walk into the kitchen, fill up the kettle for another pot of tea.

\n

Clear introduces the Pointing and Calling method. A process where you literally point at something and say what it is.

\n

You might point at your kettle and say \"I am turning this on because it is the morning and I drink coffee in the morning\".

\n

\"I am eating leftovers because they are on the side\"

\n

\"I am checking Hacker News because I don't want to start my next task\"

\n

A lot of the time we're witnesses to our actions, rather than the conductor. I like Pointing and Calling because it can be done from the passenger seat, as a way to move you into the driving seat. \"I have let YouTube autoplay into another vide\" I say to myself, as my brain beckons in the firehose of intriguing titles and thumbnails.

\n

I've also been Pointing and Calling before I start doing something intentionally. \"I am about to have a meeting with my colleague, I need their help because Y\" I say to myself, out loud, alone, in my office, like an insane person. Or \"We are talking about putting some more text on the UI because we think our software is confusing our customers\", I explain to a colleague, as though they are a non-technical colleague and not, in fact, a skilled engineer.

\n

Hilarity aside: Pointing and Calling sets the scene. Unspoken mismatch of understanding is a staple for a sitcom, but also the reason for a lot of wasted time. State the problem, do the smallest amount of work to solve it, and move on to the next problem.

\n

3. Decide what kind of person you want to be

\n

This point is the least actionable, so probably least worthy of discussion.

\n

No amount of daily journalling, meditation, calendar apps, or dopamine detoxes is going to make you the person you want to be. Chances are that they're rain dances.

\n

You have finite energy and time, in which you can make finite choices. So make a decision about the direction you want to change in.

\n

Think about it and why you want it.

\n

The kind of person I want to be is someone more deeply engaged in thoughtful problems. The happiest periods of my life are when I've been like that. What are the kind of things people like that do?

\n\n

What don't they do?

\n\n

4. Monkey brain is tricky

\n

Our brains are dumb, or at very least don't want the best for use. Very smart people are building enticing platforms that wholly rely on having your attention. Our poor brains are easily persuaded by others, and very persuasive to us - so that makes them a high value target.

\n

It's become weirdly normal to be distracted or give your attention to other things. Our brains rely on sight for information processing. We see a lot of attention-grabbing things every day, and we have to do active work against that.

\n

Understanding this is necessary for a) breaking habits around modern media consumption, and b) making habits that use the freed time and space that creates.

\n

Clear gave me three very useful reminders in this book:

\n
    \n
  1. If you want your brain to forget about something, just hide it. Put your phone in the other room, remove the app from your home screen.
    2. \n
  2. Friction and perceived effort aren't proportional: adding a tiny bit of friction can make your brain think something is way harder than it actually is
    3. \n
  3. Make something tangible: a lot of difficult or important things don't have immediate tangible satisfaction. Cross something off, or write it down. Move lego bricks from one jar to another. Tear off a calendar page. Let your brain see or touch something.
    4. \n
", "slug": "2022-02-22-atomic-habits-is-a-really-good-book"}, "2020-02-24-hereabouts-devblog-1": {"title": "Hereabouts devblog #1", "author": "Thomas Wilson", "date": "2020-02-24T00:00:00", "book_review": false, "preview": "Hi, my name\u2019s Thomas Wilson but I often go by my just my surname. I\u2019m 28 years old, currently based in London, England, and I design and build software for a living through my smal", "content": "

Hi, my name\u2019s Thomas Wilson but I often go by my just my surname. I\u2019m 28 years old, currently based in London, England, and I design and build software for a living through my small independent studio tinyfox studio. At the beginning of 2020 I quit my job to do this independently, and now I\u2019m building hereabouts - an app that provides self-paced walks, tours, hunts, and races for travel adventurers\nIn this devblog series I want to record to the process of building something modern and beautiful from the ground up.

\n

My problem/frustration

\n

I love being in places. I love walking around the streets of London, and especially love how London feels like 30-40 little villages that you can find yourself in at any moment. I love learning things about the people who lived and made this place what it is today. It\u2019s my favourite part about travelling solo - is that I can walk around a new city at my own pace.

\n

The Pre-Raphaelites had studios in Bloomsbury, Virginia Woolf lived and wrote some of her work just south of King\u2019s Cross, Sherlock Holmes got coked up just east of Regent\u2019s Park. You could maybe walk between all of these locations in 60 minutes, and comfortably within an afternoon. Maybe you\u2019d notice something things if you read the blue plaques but really what\u2019s a sentence to describe a life\u2019s work?

\n

When someone visits London from somewhere else, or when they move here, or even if they just need a good idea for a fourth date - I want them to feel connected to the place and idea of London. Not caught up in frustration at the man who get on the tube before letting other people off, or the blind panic when you misjudge the timing of the turnstiles coming into the tube station. But these are both very real experiences of London, everyone who visits should have them. But there\u2019s so much more in a place.

\n

Hereabouts: self-paced walks, tours, hunts, and races for travel adventurers

\n

Hereabouts is the name of the app I am building to address this problem. I want to create an app that lets people explore a new or old city by giving them guided tours, stories, puzzles, and races.\nI want to reach adventurous travellers and sate their appetite to learn more about what makes a place beautiful.

\n

I don\u2019t know what exactly it will look like or do. That\u2019s part of the development process.

\n

What I want to achieve

\n

By building this idea out there are two things I want to achieve, neither of which are overtly technical:

\n
    \n
  1. I want people to experience joy and connection form the place they\u2019re in or connected to
    2. \n
  2. I want to provide high quality story telling and information resources
    3. \n
\n

For a while I\u2019ve wanted to build an app that helps people discover a place by being in it. I want to help people discover the same feeling I have when I\u2019m somewhere and I learn something about it. I want people to have fun in the real world, in real spaces without being tied to their screen, or a paper guide, or part of a pack of tourists.

\n

I love storytelling, and humans keep re-inventing how the do it. Oral stories, pictures, words, theatre, tv, movies, podcasts. Storytelling is probably the least talked about oldest profession. So I want to share the stories of the people who frequented, built, ruined, or just passed the streets.

\n

I hate that when I go to learn about a certain place, or person, or idea - the information is scattered and made distant. It is made boring - because it is hard work, very skilled and professional work to weave together narratives of people, places, movements, and ideas. But you create value by providing high quality, unique resources that appeal to humans (not users.)

\n

Why build an app?

\n

Something I keep re-learning about myself is that I have this drive to build and create things for me any myself. I first learned this about myself during my Ph.D. where I taught myself software development so I could make a web app for my education research. In the three years since I finished that, I have worked for a large company and a growth-stage VC-backed startup. I happily sacrificed a lot of myself into these jobs because I learned a lot from other people. Being self-taught is a good start but it\u2019s a terrible middle.

\n

And to be honest, I think the things I want to achieve can only be done on modern handheld technology (i.e. phones) because I want to bring multimedia (picture, audio, text) to someone based on the place they\u2019re in. I think it could be done by being walked/shown around by a professional. However that\u2019s not an idea that excited me, and I also think it\u2019s too much like forced fun. Part of being an explorer or adventurer is being able to go down side streets, get surprise ice cream, or spend twice as long somewhere you find interesting. There should be guidelines, not fences/rails.

\n

This is also overlooking the fact that I am a software developer by trade/craft. It influences to way I see the world, solve problems, and build solutions. I enjoy designing and building software, and I\u2019m sure that\u2019s affecting my decisions.

\n

I also want to call out a couple of very influential sources to me when thinking about if this is something that I can or should even be doing:

\n", "slug": "2020-02-24-hereabouts-devblog-1"}, "2020-09-20-interviewing-experience-2020": {"title": "My experience finding a new job as a software engineer in summer of 2020", "author": "Thomas Wilson", "date": "2020-09-20T00:00:00", "book_review": false, "preview": "In late summer of 2020 I moved from freelance software engineer to a full-time position. I want to outline this process for literally anybody who's interested because I've found it", "content": "

In late summer of 2020 I moved from freelance software engineer to a full-time position. I want to outline this process for literally anybody who's interested because I've found it useful when other people have done the same - like this post about interviewing at Google, this front-end, and this more generic post.

\n

Web development is a joyfully open community. There's a lot of sharing, most often we share code, but we also share details about the wider context of our field. Navigating a career is hard, and that's not made easier when people don't talk about their experience of moving (up, down, sideways) within and between companies.

\n

It can be hard to talk about these things with your current colleagues without sounding like you're planning on leaving. It's also just a weird industry, where applying for jobs can take a long time, require a lot of standardised hoop-jumping and box ticking, and just generally feels pretty daunting. Not to mention the global pandemic and economic down-turn that hit us in 2020.

\n

Anyway, I've managed to find a new job that I'll be starting in October 2020. I'm (secretly) very excited and hopeful for it, and I want to share what it was like interviewing for a frontend / fullstack software engineering role in the summer of 2020.

\n

A note on honesty:

\n

I want to be as honest as possible here, and not skip over mistakes or hurtful events (like being rejected). I still have to be purposefully vague in some places. Honestly, the specifics don't really affect the trends and takeaways as a whole.

\n

I'm also not going to go into detail about my salary here. I would (and do) discuss salary in person with trusted peers because people and companies have (and do) get away with discriminatory (e.g. by gender) pay for people in similar positions. But this is the internet, yo - I'm not going to talk about this right now.

\n

If no one around you is willing or able to talk about salary, it's fairly easy to find average data for your city and job position. For example, the average salary for an engineer (which is a broad definition) in London in 2020 is about \u00a350-60k:

\n\n

Being open to opportunities

\n

I am a software engineer with 3-5 years[^1] of front-end and full-stack experience. I have worked in academia, in large (>500 person), scaling (50-150 people), and small (~5 people) companies. I spent 2.5 years in companies, and about 8 months freelance.

\n

I signalled myself as open to new opportunities for related positions around July-August of 2020. Around the middle of September I accepted a full-time position as a front-end engineer. In all, it took me ~10 weeks from first thinking \"I should see what's out there\" to signing a contract.

\n

Much of my job hunting was through \"passive\" platforms, where recruiters and companies would come to me with information about positions. I used LinkedIn, hired.com, and talent.io[^2]. On the latter two platforms, you have the ability to set salary expectations and create a list of technology stack/work environment preferences.

\n

[^1]: Depending on if you count my PhD as \"professional\" experience or not.\n[^2]: Each of those links are referrer links, we both get a rewarded if you find a job with that platform. If you feel weird about using a referral link it's very easy to get started on both platforms without them.

\n

I also used various job boards, notable hacker new's monthly \"Who's Hiring\" (which are consolidated here) post, to look for jobs maybe once a week. There's a lot of nonsense, unclear, non-applicable job postings out there, and it's easy to spend too much time searching the noise for signal.

\n

I want to be in my next position for ideally 3+ years so I was very selective about the companies I wanted to work with. I did not need a new job, and so I could be afforded this luxury.

\n

In that time I had introductory phone calls with 10-15 companies, and interviewed with seven (i.e. arranged a follow-up from the introduction call). I ended up accepting an offer from one, was rejected by one, ghosted by two others, and declined three at the point where they asked me to complete some kind of code challenge.

\n

The interview process

\n

The interview process for all companies who I spoke with (more than the seven mentioned here) looked surprisingly similar:

\n
    \n
  1. A pre-interview interview. Have a 30-45 minute one-to-one chat with a recruiter or product-person. The point of this chat is for both parties to get a sense for each other. I am good enough at faking extroversion to actually enjoy these, to chat with interesting people about interesting problems. If you're roughly qualified in the technologies, and find yourself actually engaging with the problems the startup are facing, then you'll normally be screened through these calls an invited to the next stage.
    2. \n
  2. A technical chat. If you make it through the introduction call, a few days later you'll probably have a more focused conversation with somebody, or somebodies, more technical. These chats are about drilling down on the kind of work you've done recently, and examples of your character. Be prepared to have a few case studies for specific projects you've worked on, things which have made you proud, and things which you have done wrong. Smaller companies tend to have more free-form interviews but larger/scaling companies will have a more formalised process with more set criteria. Try to stick to your time, don't ramble (but don't be too short), be honest, and be kind to yourself, your colleagues, and the industry as a whole. If the company think you're as qualified as you say you are, and you're a good \u2728cultural fit\u2728 then you'll make it through this stage.
    3. \n
  3. A code-based test. At some point they're going to want to see you write code, and you're going to want to show off how able to write code you are. The format of these varied, and I'm really happy to see a move away from take-home tests as the only thing they ask you to do. Methods I either experienced, or would have experienced, include:
    4. \n
  4. Walking someone through a codebase I had written, or was familiar with.
    5. \n
  5. Taking a look at the company's codebase, and running a think-aloud style interview where I explain what I'm seeing and what I think about both syntax and architecture.
    6. \n
  6. A time-boxed take-home problem, i.e. being given a specific coding challenge but with an explicit deadline or limit on time (in the order of days, not hours). The company would tell you ahead of time if you needed to set anything up in particular (e.g. libraries, virtual environments, software).
    7. \n
  7. The classic homework take-home problem, i.e. being given a problem and asked to submit a solution when it's ready.
    8. \n
  8. An on-site interview. If you can write the code, and the company like how you write code - then you'll probably be invited to an on-site interview. All companies I spoke to (which weren't 100% remote) had an on-site part of their interview, and all made concessions given the COVID-19 pandemic (only meeting a certain number of people, social distancing measures, etc.)
    9. \n
\n

The companies

\n

In all, over the summer (6-8 week period) I interviewed with seven companies. I've grouped them by outcome, the order other than that is completely random.

\n

Sustainable Laundry company

\n

\ud83c\udf8a Accepted an Offer

\n

What do they do? They wash clothes, I guess, with the USP of being zero carbon.

\n

What happened: one-on-one intro chat with head of tech, two-on-one chat with CEO and head of tech, then an on-site with the wider team. Offer made the following day and accepted two days after that.

\n

Hospitality/Services adjacent company

\n

\ud83d\ude4f Declined before code-test

\n

What do they do? They work with companies in the hospitality and services industry to increase efficiency.

\n

What happened? After a productive chat with someone product-focused I had another productive chat with someone in the tech team. I was offered a take-home code test which I declined because I accepted the other job. I was offered contract work at a later date, and would have accepted it if I had the time, they were genuinely a good bunch of people.

\n

Civil Infrastructure company

\n

\ud83d\ude4f Declined before code-test

\n

What do they do? The company use novel software to reduce losses and increase efficiency on civic infrastructure (think roads, water, sewage, power lines).

\n

What happened? A successful introduction call with a product person, then a one-on-one with a C-level person. I declined the take-home coding test as I accepted the above offer, additionally their tech stack was far outside my current area of expertise.

\n

Productivity software company

\n

\ud83d\ude4f Declined after first interview

\n

What do they do? A very early stage (almost-finished internal MVP worked on by small team) team building a real-time, collaboration-focused, web productivity tool for teams.

\n

What happened? I declined a code-based assessment because I did not believe in the company's mission, especially in a crowded marketplace - they couldn't verbalise a strong, coherent USP or value proposition in a busy marketplace.

\n

Logistics company

\n

\ud83d\ude45 Rejected

\n

What do they do? A growth-stage startup with a vibrant and varied tech team who handle global-level logistic chains.

\n

What happened? I was rejected after a personal fit interview with a number of employees. I received specific and targeted feedback.

\n

HR company

\n

\ud83d\udc7b (Almost) Ghosted

\n

What do they do? They're working in the talent acquisition space to help recruiters find talent and streamline the process from applicant and recruiter side.

\n

What happened? After ~4 weeks I got an e-mail back saying the position had been filled, but was offered short-term contract work with the team.

\n

Data Privacy Company

\n

\ud83d\udc7b Ghosted

\n

What do they do? An international data-privacy company who were looking for frontend engineers to improve the UI of their products.

\n

What happened? I saw the job advertised online and reached out to the contact e-mail address given (who was the CEO). The CEO asked for a CV and a cover letter which I sent in and never received an acknowledgement or reply.

", "slug": "2020-09-20-interviewing-experience-2020"}, "2020-04-02-hereabouts-devblog-2": {"title": "Hereabouts devblog #2 - March 2020", "author": "Thomas Wilson", "date": "2020-04-01T00:00:00", "book_review": false, "preview": "Hi, I\u2019m Thomas Wilson, I\u2019m a web and mobile engineer building [Hereabouts](https://www.hereabouts.app) - an app that\u2019s like a tour guide if the tour guide was like [Roman Mars](htt", "content": "

Hi, I\u2019m Thomas Wilson, I\u2019m a web and mobile engineer building Hereabouts - an app that\u2019s like a tour guide if the tour guide was like Roman Mars after three beers. This is a devblog where I talk about my progress building that app. Also I\u2019m very sorry, Roman, you\u2019re one of a handful of people who I genuinely aspire to be like please don\u2019t take me seriously.

\n
\n

Well March 2020 has certainly turned out to be quite the introduction to working on a side project. It\u2019s the month that the UK (and Europe, North America, etc.) started nationwide lockdowns to prevent and slow the spread of Covid-19. Social distancing, self isolation, and quarantine are all in full swing.

\n

Imagine starting a side project based almost entirely on being able to travel somewhere new, or even just go outside and walk around. It\u2019s a strange time, but everyone\u2019s talking about it being a strange time, and honestly we\u2019re all just trying to find a new temporary normal. So with that in mind, here\u2019s an inconsequential update on Hereabouts.

\n

I\u2019m still pretty undecided on the format of a devblog, which makes this one a brain dump, but definitely the kind of brain dump that you should read.

\n

Notable things

\n\n

What an Emotional Rollercoaster, feat. The Covid-19 Pandemic

\n

This past month has been one of the most varied emotional months I\u2019ve had in a long time. I my emotions to be strong in number and force at the best of times, but imagine quitting your job to go freelance in what is possibly the worst time in 30 years.

\n

I am not a stranger to self-doubt. I often think I am about to get fired, when in reality I have never been fired, or come close to being fired. Maybe I have and I\u2019ve just instinctively played the \u201cyou can\u2019t fire me I quit\u201d card.

\n

The big situation here is the SARS-COV-19 pandemic that\u2019s needling through the globe right now, causing unnecessary loss of life and bringing an economic recession and a wake of social crises. What a time to be alive.

\n

Can you imagine finally deciding on a side project you want to carry through to production/publication, and then a global pandemic breaks out. Not great for the global community or economy, or for an app specifically built around the idea of being outside. This comes at at time where most of the advice from European governments is to stay inside, with increasing policing and enforcement.

\n

I\u2019ve had to seriously think if building this app remains a good idea, and I think it is. I really struggle with shiny-things-syndrome, where I flit between and around ideas and never commit fully to something. Hereabouts is the first side project in 3-4 years that I decided to see through seriously and then did something about. It\u2019s the only one that made it past a line in a note on my iPhone. It\u2019s not the only idea I\u2019ve got rolling around in my phone\u2019s notes, and it\u2019s probably not even the best one. But it\u2019s one that excites me: it\u2019s an app I would like to have and use, and it\u2019s something that I think can offer value to people. It\u2019s also going to teach me a lot about launching an app in the real world.

\n

Yes, a pandemic with strong government response is a good mitigating factor - March 2020 has truly been wild, and I don\u2019t think anyone would blame me if I let the idea go to find something more stable. Like a Zoom alternative or remote yoga teaching software. Or just a Zoom alternative without extremely concerning privacy policies. I\u2019m sure video conferencing can\u2019t be that hard, there\u2019s no reason that all the alternatives are terrible to use.

\n

What\u2019s more, the current economic climate has seen travel and leisure industries basically tank out, and it\u2019s looking a lot like many people this year won\u2019t be able to take holidays. Some of those holidays will be honeymoons, or retirement cruises, or long-overdue personal relaxation time. This pandemic is making a lot of us suffer in a lot of ways, but I digress. There\u2019s a global recession threatening and although central economic bodies are all trying to act to mitigate these factors, there\u2019s a chance that people don\u2019t have money to spend.

\n

I am aware that I don\u2019t want to continue under the guise of hustle porn - I don\u2019t want to see this hardship and fight against it just because it\u2019s a struggle and it makes a great narrative. I don\u2019t want to think of myself as a company that was shaped by the COVID-19 quarantine and panic. I don\u2019t really see that as an influential factor in what I\u2019ve decided to do, or how. What\u2019s more, I don\u2019t think end users really care about how or when an app was made, especially as people will (hopefully) start to forget what things were like during these times within months of them ending.

\n

The primary reasons I want to continue development of this idea, at least for now, is how early in development I am and how this remains a side-project. I have other full time work that lets me pay the bills and I don\u2019t need this to take off. I\u2019ve given this project about 6 months, taking it to the end of summer (September-is) which was always going to be just off-peak for summer for tourism. But it looks like we\u2019re not going to get peak tourism anyway on account of the global lockdown. I want Hereabouts to be an app that could be used by someone who already lives in a city, and as a cheap day activity for anyone. I think there remains a market for the app, and the possibility that I learn some interesting things from releasing it to a smaller audience.

\n

In short: I\u2019m going to continue with development. It\u2019s just a weird part of the Hereabouts story - that the worst pandemic in literally 100 years strikes just as I get going with it. What impeccable timing.

\n

Thinking about development cycle and Topic Lock

\n

I disagree with common practice of two-week sprints and an endless backlog as the best way to manage and drive software development. I think it\u2019s short sighted and makes you feel comforted by how busy you are and how much work you have to do. If something\u2019s important, it will keep raising itself as important, and I shouldn\u2019t move on without it. If something feels important but I forget about it quickly, and didn\u2019t latch on and flesh it out - it probably wasn\u2019t actually that important.

\n

This is especially true for right now: creating the idea for a new product, and then putting that into concrete UIs and code. What is Hereabouts, what does it do, and how is it used? These questions are the most rabbit-hole kinds of questions, because there\u2019s a lot of edge-cases and what-ifs that can found or ruin a feature idea.

\n

I want to feel I have the freedom to go down these rabbit holes because they are important and I don\u2019t want to spend time and energy justifying that when I could spend that energy exploring them.

\n

To counteract the (very real) chance that I spend all the time designing or thinking of possibilities, and no time actually building them, I am thinking about how I can integrate the Double Diamond process which is a needlessly buzzword-y way of saying that I am consciously separating out the processes of a) generating as many ideas as I can, and b) paring these ideas down to find the useful or recurring ideas.

\n

Alongside that, I am thinking about Topic Lock. This is something I first heard from CGP Grey said in the Cortex podcast, in regards to his work as an independent content creator. It\u2019s influenced from the way movie studios produce movies, and the Kanban project methodology: have a fixed number of things that are in progress.

\n

I am striving to build a way of working that allows me to create and shape ideas, but also then critically examine the ideas individually and as a collective.

\n

This is getting abstract and I\u2019m only a month in, so I\u2019m going to save this for another time. But look - I\u2019ve been thinking about how to create a process and environment that works well for me, my brain, and the product.

\n

User Journeys, Internal Documentation, and Design Language

\n

This is my party, I\u2019ll do what I want, and I want to start by talking about the tools I used to do this work because I find that more interesting than the work itself. I\u2019m not proud of this part of me, but I love well designed, cool, and hipster apps.

\n

Notion is hard to describe: it\u2019s like a Google Doc meets a database. I actually wrote about why I gave up using Notion back in August so this is a little embarrassing - but I stand by what I said: I cannot use Notion to write long form prose, like this. I am writing this blog post in Bear.

\n

Notion does let me capture my thoughts in a much more organised way, compared to plain text and markdown. I\u2019m not going to go into detail about how I use Notion specifically, but I am using it for:

\n\n

Notion gives me freedom but also constrains me a little more than free form text. This is useful when I just need to get my goals and intentions down, and not spend hours worrying about how it looks. Notion\u2019s got great design by default, kudos.

\n

They\u2019ve also fixed the navigation by Smart Keyboard on the iPad THANK GOODNESS. Not being able to move around in a sensible way without using my slow meaty dumb fingers on the screen was infuriating. I didn\u2019t spend dozens of hours of my life forcing vim\u2019s philosophy into my own world view to have it ruined like this.

\n

User Journeys and Design Language - Another blog post (in Figma and Notion)

\n

I\u2019ve done a lot of work this month doing visual and UX design. The results, and how I manage these parts of my thinking and planning can\u2019t / shouldn\u2019t be described here because this is a devblog. I\u2019ve made a note to write about them in more detail later.

\n

React Native

\n

I wrote a more in-depth post about why I choose React Native, also on my blog. So yeah, I\u2019ll be writing this thing in TypeScript, using React Native, and the Expo platform.

\n

Let\u2019s take a whole paragraph to acknowledge how good a job the Expo team are doing. Honestly, such brilliant tooling.

\n

I started working on this project in Swift: first with SwiftUI then moving to UIKit.As someone\u2019s who\u2019s more fluent in frontend engineering (3 years full-time professionally), having to debug some of the problems and limitations of the new SwiftUI API wasn\u2019t productive. I simply don\u2019t have the frontline experience of using Swift in a production environment that made debugging and interpreting documentation a viable option.

\n

Moving to UIKit very briefly made sense, but SwiftUI is the future of development on Apple platforms so why waste time working through that.

\n

I\u2019d like to come back to SwiftUI in a couple of months/years, when it\u2019s out of beta. I hear good things about it, and it sounds like they\u2019re bringing in an opinionated declarative philosophy. I\u2019m excited to see how this affects the UI development community at large.

", "slug": "2020-04-02-hereabouts-devblog-2"}, "2021-02-13-things-i-learned-27": {"title": "Things I learned this week #27", "author": "Thomas Wilson", "date": "2021-02-13T00:00:00", "book_review": false, "preview": "- **This seventeenth century petition**: In 1674 in England, a pamphlet was made and published, titled _The Women's Petition Against Coffee_. The women (or alleged women, we don't ", "content": "\n

What I've had on rotation

\n", "slug": "2021-02-13-things-i-learned-27"}, "2020-03-15-ugly-but-functional-ux-design": {"title": "Kickstarting UX Design with ugly working documents: Screens, Components, Actions, and State.", "author": "Thomas Wilson", "date": "2020-03-15T00:00:00", "book_review": false, "preview": "UX design resists standardisation or templates. It can\u2019t be a one-size-fits-all approach, and the nature of the product, audience, and production team all mean that something diffe", "content": "

UX design resists standardisation or templates. It can\u2019t be a one-size-fits-all approach, and the nature of the product, audience, and production team all mean that something different is needed each time. Whenever I get past the early stages of UX design (like understanding what a product does, and who it does it for) - I find myself with a different working document and process than I\u2019ve needed before.

\n

I wanted to share the things I do that give me the momentum to get to a place where I can do this more specific kind of document.

\n

I am a very visual person, so this starts with low-fidelity UI mockups: clunky boxes and text, that I can setup and tear down quickly. My process is built around forcing me to move through all the parts of an app quickly. This means I force myself to encounter all the information an app needs,every way that it\u2019s displayed, and everything a user can do with it. Seeing these things within a short time makes repetition and patterns more obvious - and helps me make connections and similarities.

\n

Tl;dr

\n
    \n
  1. You are going to make a list of all the Screens & Components in your app. You\u2019re going to do it in an ugly-ass looking document that you\u2019re never going to share and actively should not spend time to make pretty. Make this document however makes sense for you - Figma, Sketch, Paper, whiteboard, plaintext, WHATEVER I DON\u2019T CARE AND NOR SHOULD YOU - YOU\u2019RE NEVER GOING TO SHARE IT
    2. \n
  2. First, make a list of all the Screens in your app, and lay them out (roughly, don\u2019t fiddle with arrows) in an order that someone could realistically move through your app. I like to group similar screens closely together, and I also look for common screen patterns (e.g. screen with a header and a footer nav).
    3. \n
  3. You\u2019re going to make a note of all the high level Components on the screens. Start by just making a boring old box with really clear terms on it: e.g. \u201cAccount Details\u201d, \u201cSign in form\u201d, \u201cCreate account form\u201d, \u201cRecent transactions\u201d.
    4. \n
  4. Go through these high level components and start making the low level, more abstract/utility ones: \u201cTextField\u201d, \u201cButton\u201d, \u201cIcon\u201d, \u201cLabel\u201d. And begin to compose these together in your higher level components.But do not lay them out nicely.
    5. \n
  5. Take your Screens and Components, and list all the variants in State that you can have: can a TextField be selected or disabled ? Can an event in a calendar be upcoming or passed ? Can the Screen for editing an article be in edit mode or read mode ?
    6. \n
  6. You\u2019re going to look at all the components you have that are Actions - i.e. can I click it, slide it, interact with it in a way that does something: navigates me somewhere, opens a modal, logs me out. Use this as a chance to understand all the ways a user can navigate around the app - going from one screen to another.
    7. \n
  7. Look at all this amazing information you have about your app or product, and how you can organise it to help your team design and build a product in a way that creates the most value most quickly.
    8. \n
\n

Why even do UX?

\n

I mean, honestly, if you don\u2019t think it will serve you, your product, or your team, don\u2019t do it. Don\u2019t invest in work uncritically, if you don\u2019t see how it ultimately makes you more money or a better product. If you think what I\u2019m saying is dumb, don\u2019t listen or read - I think plenty of people have useless opinions, especially on the internet.

\n

For clarity, when I talk about UX design, I am talking broadly at developing an understanding of an app or service from the end-user\u2019s perspective. How will they interpret the thing we put in front of them, and what can a design/engineering team to do make sure that the creative vision is the same as the user\u2019s experience?

\n

It\u2019s like viewing a miniature model of a town: you can see distinct regions, connections between them, and kinds of buildings in each. But you don\u2019t get bogged down in the specifics, like \u201cis that store a pharmacy or a grocery store?\u201d.

\n

More concretely, this understanding is useful in making a product that actually does what you want it to. It\u2019s no good having an app that does something \u201cin theory\u201d - because truly most of your users don\u2019t care about \u201cin theory\u201d. They want to learn a another language, make a claim on their insurance, or get a new beautiful handmade scarf. This is similar to the Jobs to be Done mentality.

\n

From an engineering perspective, as someone who makes apps, doing UX design helps break a \u201csimple\u201d app into exactly how many things need to be built, and what they need to do. It lets me build the necessary things, in a sensible order, and gives me a shared language/understanding that then lets me communicate effectively with a team.

\n

0: Screens & Components, State & Actions

\n

Everything I do in this early UX process is designed to help me understand my app along four heuristics: Screens, Components, State, and Actions. These are the things that I find it useful to break an app into - they might be useless to you and that\u2019s okay. Do read on, and see what sticks.

\n\n

You are creating a low-fidelity working document.

\n

To help identify these things, we\u2019re going to make a visual representation of each. At the early stage on the UX design process I have to remind myself often that I am creating a working document - one that won\u2019t be shared widely (or at all) within my team, let alone outside of it. This is just a way for me to organise my thinking. This isn\u2019t about making any kind of mockup that looks pretty, or crafting meaningful naming conventions.

\n

Your working document will probably be ugly. Mine definitely are. I have intentionally put ugly images / mockups in this article so you can feel better about how bad yours look and how little you want to share them. Anything you create during this process is meant to serve you, not Dribbble or Instagram. Embrace the brutality and Spartan utility of your UX diagrams.

\n

Trying to optimise for visual and semantic consistency at this stage makes you feel busy, without having to address the important questions. So long as I know what a component or screen means, then it doesn\u2019t matter.

\n

I also really encourage you to work with pencil and paper next to you. Even if you\u2019re prototyping on paper - have more paper ready just to jot down questions, sketches, ideas as they arise to your brain. You can\u2019t go chasing down every rabbit hole - it will break your flow, and I really think it\u2019s important to build up a good flow, in this process. This flowcess. But you also don\u2019t want to lose any legitimate ideas or questions you have, they can help you a lot when you\u2019re doing higher-fidelity design.

\n

Oh my plants

\n

In this article I\u2019ll be using the example of an app that helps you keep track of all of your houseplants. I\u2019ve called it \u201call my plants\u201d and I\u2019ve given it a very predictable green theme.

\n

1: Identify Screens

\n

So let\u2019s imagine the following user journey in oh my plants - I want to get to a page that has a whole bunch of details about a specific herb. I can get there by searching for it, by seeing it in a list of plants I\u2019ve said I own, and perhaps by an automatically created list of plants (like what\u2019s in season). This gives us five screens: starting at Home we can end up at Plant Details by going through either of the three possible routes.

\n

\"\"

\n

This kind of layout, with the arrows drawn between them, is useful at some points, but it\u2019s exactly the kind of over-optimisation I just warned against. Because what happens if I need to add in a new screen or remove one? I have to re-structure all of the positions and arrow flow.

\n

Robust software architecture is about fighting rigidity and letting developers change individual parts quickly - because requirements are always changing. Good UX design can learn from this - build a working document is about rapid change - the tool you use should work as close to the speed of your thought process as possible so that one isn\u2019t lagging behind the other.

\n

I\u2019ll end up with something like this: simply a list of screens, in some semblance of order that make sense to me. In Figma I make each of these into its own Component (or Symbol in Sketch) so that when I begin fleshing out user journeys later on (like the pretty arrow diagram above) - we\u2019ll see something less abstract than just white boxes and black text to represent a screen.

\n

\"\"

\n

2: Identify the Components

\n

Once you\u2019ve got all the screens, start going one-level deeper by identifying Components - distinct bits of UI. I find it most useful to start with the high-level components - i.e. Start with high-level components - things driven by their use cases. I name these in very opinionated ways: \u201cUser Owned Plants\u201d is a list of plants the user has said they one, and \u201cIn Season Plants\u201d might be a list of plants that are ripe for planting.

\n

After I\u2019ve done that, I start identifying the lower level components: things which are not so closely tied to specific use cases. Prime examples are Lists and List Items, as well as Buttons or Cards. Use your own discretion and opinions here: is a SearchBar component distinct from a TextField - or should they be the same thing? I would advise leaning towards how you communicate things to the user: do you want them to conceptualise a search bar as the same thing as a field in a form? For me, I would keep them as different components, but I could very easily see it argued either way.

\n

\"\"

\n

3: Identify State

\n

With your new list of screens and components, you\u2019re going to want to go through and make a note of every possible variant based on state.

\n

\"\"

\n

This is when things start to get a little complex/tedious, because it can massively increase the sheer number of screens and components that it looks like you\u2019re going to have to design. It\u2019s also worth paying attention here to the kinds of State - chances are there aren\u2019t that many discrete ones, and they can come in groups and are conceptually related: selected/disabled, read-only/edit, locked/available, active/not-active.

\n

When it comes to the actual design, you\u2019ll be able to share visual metaphors here. In fact I would suggest that kind of consistency can make complex business logic or states feel much more simple than their implementation details. If things are disabled/inactive/locked, for example, the result in very similar to a user: there\u2019s a thing on the screen that I can\u2019t interact with right now.

\n

Wait, why do I need state on my components AND screens?

\n

Yeah, this is a very fine line - and totally is a matter of opinion. This is one of the points that makes product and UX design a skilled profession.

\n

For me, it comes back to what I said at the beginning: UX is about understanding how the user will perceive the product. Even if the information we\u2019re presenting is correct, it\u2019s the way it\u2019s presented that makes the difference between a good and a great experience.

\n

Enough talk, let\u2019s give an example. Imagine oh my plants knows when\u2019s the perfect time to plant each garden herb. It has a PlantList screen - which is a simple list view of PlantListItems.

\n

A PlantListItem represents one individual plant - which is the thing that\u2019s in season. Following that logic, we want to flag each plant as in \u201cin season\u201d.

\n

\"\"

\n

In practice, however, the fact that all the plants are highlighted means that none of the plants are highlighted. It also just looks weird and cluttered and busy. Instead, what if the PlantList was highlighted with some special way of saying that it is in-season?

\n

4: Identify Actions

\n

An action is normally something that changes the state of a component or screen, or that navigates the user around the app.

\n

If you identify actions at this point in the design process, it should be really easy for you. It\u2019s probably anything that uses a component like button or select or switch or tab... you get the idea.

\n

\"\"

\n

Conversely, if you recognise there are actions that are triggered by clicking non-typical components, like undecorated text or header - then maybe these are interaction patterns you need to make discoverable to your users.

\n

What\u2019s considered \u201ctypical\u201d depends on the conventions of the platform, e.g. long-press and double-tap on mobile don\u2019t really have equals on the web.

\n

5: Go forth

\n

Look, you made it all this way, congrats because even I struggled to make it this far down when I was proof-reading. Hopefully at some point along this journey you\u2019ve thought \u201cwait, why am I doing this next bit, surely I should go off and do something else instead\u201d - then good. Go do that other thing, like thinking about adding new features or, even better, removing others, or making clearer visual metaphors or condensing many metaphors into one.

\n

You\u2019ve hopefully got a much more complete and accurate (read: big and scary) picture of your product: all the things it needs to do, what you need to build, and exactly how many designs you\u2019ve got to flesh out and then build. Or throw over the wall to the developers and hear them argue over for the next 2-9 months.

\n

Take this blueprint forward and make something you\u2019re proud of, or ignore my opinions and become successful anyway - I truly do not mind.

", "slug": "2020-03-15-ugly-but-functional-ux-design"}, "2020-08-07-where-i-go-for-ui-inspiration": {"title": "Where I go for UI inspiration", "author": "Thomas Wilson", "date": "2020-08-07T00:00:00", "book_review": false, "preview": "Like anybody who makes interfaces for apps/websites, I spent a lot of time looking at _Design Inspiration_ (read: UIs, real or imaginary, made by other people). This is a really go", "content": "

Like anybody who makes interfaces for apps/websites, I spent a lot of time looking at Design Inspiration (read: UIs, real or imaginary, made by other people). This is a really good way to look at visual conventions that other people made, and have used in their UIs and UX.

\n

If I were to examine the time I spent \u201cdesigning\u201d more closely, and divided it between actually pushing pixels around in Figma, and looking at other people\u2019s work on Dribbble I would be shocked and ashamed.

\n

Allow me to justify this though: unless you are one of two-three social media giants, literally nobody spends the majority of screen time in your app. It would be incredibly arrogant to assume your app is good enough that people are willing to learn a whole new style of interaction, navigation, and visual metaphors for it.\nIn this teeny blog post, I just want to list some of the places I go when I want to find good UI to look at

\n

A quick caveat though. These sites are good in the same way that a buffet is good. But they\u2019re also bad in the way that a buffet is bad. If you\u2019re not consciously selective in how you expand your UIs, it can feel like a collection of disparate widgets. Would you trust a website that could go from crunchy spring role to full-bodied bolognese, just because a designer fancied it? As a designer it is your responsibility to understand the types of data, interactions, and journeys that your app is trying to promote or facilitate. Sometimes \u201cbecause it looks cool\u201d is enough of a reason - but this might not fly so well on a village GP surgery.

\n

Anyway, this post isn\u2019t about that, it\u2019s about some sweet sweet list of cool sites for design inspiration. Well have I got a twist for you, I actually made two lists (Inception Horn).

\n

Here are some sites that put words to visual design patterns:

\n\n

Here are almost endless numbers of mockups from people far more talented than I:

\n\n

And for Colour Palettes:

\n", "slug": "2020-08-07-where-i-go-for-ui-inspiration"}, "2022-04-26-complicated-and-not=-that-useful": {"title": "Complicated and Maybe Not That Useful \u2013 Modern frontend tooling", "author": "Thomas Wilson", "date": "2022-04-26T00:00:00", "book_review": false, "preview": "**Prologue** Hi there, this is \ud83d\udd2e Future Thomas \ud83d\udd2e here. I'm re-reading this post while editing and, my friend, a lot of the first-draft of this post sounded like borderline heresy ", "content": "

Prologue Hi there, this is \ud83d\udd2e Future Thomas \ud83d\udd2e here. I'm re-reading this post while editing and, my friend, a lot of the first-draft of this post sounded like borderline heresy and also like the Remix framework and its team had personally wronged me. It's not and they haven't. I've taken out some of the spicier takes (but left in a few cusses, for flavour) - but a pinch of salt and a generous interpretation would be great on this one.

\n
\n

Nearly ten years ago I was gifted a book called Agile Web Development with Ruby on Rails by a guy called Mark. That book was a gateway drug to an (ongoing) career in software engineering. About five years ago I left the Rails pen (wen off the rails?) in favour of building modern frontend applications, first in Angular and then in React.

\n

Stop me if you've heard this one: but I like Frontend Engineering because it gives me immediate feedback from building products and features. But I learned I just liked building products and features, which usually need a UI.

\n

I have a pretty good knowledge of these UIs. But now, in 2022, I couldn't use this knowledge, in its totality, to throw together a functioning side project of medium complexity in a few months. I'm a product engineer who couldn't build a product. Admittedly I had other things going on, but wow.

\n

I don't think I've been set up for success.

\n

A lot of modern frontend tooling is secretly platform tooling without the grizzled veneer of other platform tooling. Just replace yaml for json or .config.js files. Get Jest, TypeScript, WebPack, Prettier, and ESLint to play nicely together. These are some of the most popular tools in the ecosystem.

\n

As one engineer, very few of the tools I use and build (data fetching, client-side caching, systemic design) help me build and ship something meaningful. They're parts of a platform.

\n

I've never had more tools help me do less.

\n

Nah, software is just hard to build. Nope, I think we made it too complicated. There's more to this than \"man who learns frontend can't do backend\", I promise.

\n

Complexity!

\n

I'm enjoying my time as a Serious FrontEnd Engineer(TM), I've built satisfying things that I am proud of. I've built design systems and product prototypes, I've become very fluent in TypeScript and JavaScript and even up-skilled new and mid-level engineers. I've helped teams think about product and design in a more serious way. I've grappled with Webpack and played spin-the-bottle with Package version bumps, I've set up mono-repos, minifiers, and css modules.

\n

How many of these labours are in service to an end user? And how many are in service of engineering? How much necessary complexity have I introduced but shifted around? How much unnecessary complexity have I introduced?

\n

I'm starting to think that some of the ways I've built software before is complex but not that useful. The UI-Server anti-monolithic architecture might not be the first place to start. It might not even be the second step after that.

\n

When I've seen the attempts to break apart a monolith, it's more often been because of the needs of the company or engineering team making the product - not the user.

\n

The structure of software mimics the structure of the organisation that creates it, that's Conway's Law.

\n

I think it's weird that the solution to product and organisational complexity is to create technical complexity. I think it's weird that I thought you had to start building as though you were a rapidly scaling team.

\n

I think there are more ground-level questions like \"does this feature exclude any of our users?\" or \"how will we know if this feature fails?\". I think we build software in service of our users despite this complexity. We might even be able to build better software without it.

\n

I want to build something

\n

These aren't just five-dollar words. Three months ago I became concerned that the thing that got me into being a software engineer (building cool shit) isn't something I do these days. Especially as one human engineer with a full-time job (doing work I enjoy with people I respect), and having a specialised knowledge of frontend tooling.

\n

The last side project I attempted in earnest was a native iOS app (RIP Dash) in which I learned that native development is not for me (\"SwiftUI is production ready\"). After that, I got a promotion (\ud83c\udf89), and after that I decided I might have the bandwidth to build something else.

\n

Recently I've been trying to improve my French proficiency (la pand\u00e9mie ne m'a encurag\u00e9 pas de tout). So let's build a tool I can use to help me do that. Something to help me track the word's I'm learning and then maybe even use them to test me. Nothing groundbreaking, stuff you do in your notebook. Bread and butter language learning tools.

\n

I figured that to do this I'd need:

\n
    \n
  1. UI/Client Side: A modern-looking UI built using standard(ish) web tools, which can handle moderate complexity (like comboboxes and interactive search)
    2. \n
  2. Server Side: A server to run code which i) is secure, ii) can separate secrets/credentials from the client, iii) doesn't require me to reinvent the wheel for basic API conventions (versioning, routing)
    3. \n
  3. Inevitable Integrations: things like transactional email, authentication stories, and media CDNs will always creep up on you.
    4. \n
  4. Data: Persisted data storage, like a database
    5. \n
  5. Infrastructure & Tests: Simple infrastructure and automated CI/CD, to run tests and automatically deploy. I'm too far gone into TDD-land, I need a good testing story.
    6. \n
\n

So I went looking for the tools or frameworks that could help me do that, while not completely disregarding everything I've learned (and got good at) recently. Surely I'll be more productive if I write software in the language I'm really fluent in?

\n

The problem is that a lot of very clever people and successful companies have demonstrated that divorcing client from server can result in some great tools and experiences. There's a lot of libraries and frameworks that'll do this for you.

\n

Anyway, I looked for a framework. A popular and easy choice for many would be a NextJS. I used Next as a freelancer, and found the whole un-opinionated API route story an unsatisfying answer to a moderately complex server app and also to testing.

\n

After looking around, I found Remix Run:

\n
\n

a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience

\n
\n

I gave Remix the college try. But things didn't work out between us. I've got a thousand-some opinionated words about it (which I might publish after the mind-dust settles).

\n

Tl;dr is that it didn't let me build things the way I wanted, but wasn't great at offering alternatives or forewarnings about what would/wouldn't work. There was a lot of \"try it and see\". Plus maybe having React as the only way to generate a DOM isn't an unconditional advantage.

\n

Back to the Checklist

\n

That technical / component checklist above could read the same for any medium+ complex application with a web-powered GUI.

\n

If you're a team of two or less, and you want to ship medium+ complex products at medium+ speed, then you need a framework to do it. Or a lot of patience. You can't just piecemeal solve each of these problems as they arise by smashing together different libraries. Because now you're building a web framework and a product and you're only a team of two.

\n

Any JS-backed framework invites people to add their favourite card to the house of cards. Which means some complicated build tooling to get 10+ years of JS to place nicely together. But complicated doesn't mean good or useful.

\n

If you want someone to make a decision faster and without regret, give them fewer choices and have them make their decision faster. If you want someone to make a better decision, make it the only decision they have to make and have them make it first. These are psychological truisms that help us design better products (and lives) but apparently we forget them in our own homes (in this metaphor, the codebase is my home).

\n

Diversity and optionality in open source software are so so essential to the ecosystem, but as an individual I have to ignore all but the 0.001% that I'm using to build my tiny thing. Which I have to use to clump together the same functionality everybody else is writing: authentication, routing, logging, etc.

\n

The JS ecosystem gives you so many options. I don't think lack of options is a problem in software in 2022. The problem is deciding what, exactly what, you're going to make 1% better today. If the answer is always something like \"my state management library\" then you should ask who's making things better for the user, because it might not be you.

\n

The energy I put into gluing pieces of the ecosystem together isn't energy I'm putting into building cool shit. It's the exact opposite, it's energy into building really boring shit.

\n

And that's why I've started exploring Rails again.

\n

Because nothing since Rails has made me feel so empowered as one person to build such a complete product. I'm sure people feel similarly about PHP and Laravel, or Python and Django. The opportunity and coolness cost is high, but I think it's worth it. Because it lets me build cool shit.

", "slug": "2022-04-26-complicated-and-not=-that-useful"}, "2021-01-31-frontend-is-fullstack": {"title": "Tiny Thought: Frontend Engineering is a Fullstack Problem", "author": "Thomas Wilson", "date": "2021-01-31T00:00:00", "book_review": false, "preview": "_Tiny Thoughts_ are little (500 word) essays. They're concise.\n\nHypothesis: Frontend engineering cannot exist in isolation from backend technologies.\n\nWhat sparked this: Thinking a", "content": "

Tiny Thoughts are little (500 word) essays. They're concise.

\n

Hypothesis: Frontend engineering cannot exist in isolation from backend technologies.

\n

What sparked this: Thinking about building the next generation of web software at Oxwash.

\n

All software is either...

\n
    \n
  1. Used by a human for a human-scale (i.e. nebulous and larger) task like updating a status on social media, download a bank statement, or send a message.
    2. \n
  2. Used by other software to complete some computer-scale (i.e. smaller and specific) task like upload a file to S3, compress an image, query a database.
    3. \n
\n

Frontend software is, by definition, the bit used by humans. Good frontend software makes the human user aware of what they can(not) do, and what's going on in the system. How many unread messages do I have? What class do I have at 4pm this Thursday?

\n

This information is communicated in the User Interface (UI). UIs are interpreted by humans. The metaphors and language developed during design then used in UI are intended solely to communicate and explain. Humans can bend, abstract, and change concepts or language. So although UIs should be consistent, they can not be. You can present your blog page as a \"recent articles\" page, and as a list view for the posts table in your database. Both are true, but have different ideas about how \"computery\" an app is.

\n

When a human tells the UI that they wish to do something, the UI then has to talk to another bit of software. Software cannot bend, abstract, or change its ideas. A blog post is a row in a database. Software has a pre-specified language of things it can do: the Application Programming Interface (API).

\n

Frontend engineering is about working with both APIs and UIs. The skill of a frontend engineer can be proxied by their ability to design one or both. It's a skill because if you make these languages too similar, you risk a UI which is too technical or an API which is too inflexible.

\n

A lot of engineers write code for engineers. I've seen (and written) \"clean\" code which prematurely optimised and abstracted. This does not guarantee a good Developer Experience (DX) when you actually use the API. Nor does it make the user experience or product quality inherently better.

\n

These are strong code smells if I'm building version 1, or the API only has one consumer.

\n

As a frontend engineers, we have to advocate for users and software, situation depending. We should make better interfaces.

\n

Recognising the need to design singular interfaces (APIs and UIs), and using a shared language is GraphQL's fundamental distinction from REST. GraphQL acknowledges that provider and consumer need to know about each other.

\n

If your product is an API you should think especially hard about clear concepts and language.

", "slug": "2021-01-31-frontend-is-fullstack"}, "2022-04-17-why-is-this-pr-so-big": {"title": "'How did this PR get so big?' \u2013 Advice for separating aesthetic and functional changes in code", "author": "Thomas Wilson", "date": "2022-04-17T00:00:00", "book_review": false, "preview": "A few weeks ago I was working on some change in our codebase. One thing lead to another and the diff I submitted spanned eighty-some files, and over a thousand lines of modified c", "content": "

A few weeks ago I was working on some change in our codebase. One thing lead to another and the diff I submitted spanned eighty-some files, and over a thousand lines of modified code (adds, removes, and modifies).

\n

The first question I was asked in the sync code review was \"how did this PR get so big?\". The short answer is that I mixed functional and aesthetic changes into the codebase:

\n\n

It's a good question, though (\"why is this PR so big?\"). It implies that smaller, more frequent changes to the codebase, and subsequent automated deploys, are the goal (they are) and that the natural enemy of this goal is large, many-file changes (it is). That's mostly because they consume human attention, which is finite and valuable.

\n

PRs (pull requests) represent a change the team wants to make to the codebase. It's common practice that you have someone double-check the changes to the code before the change goes to the main branch (a code review), and less-common, but higher value imo, to have someone double check your workings as you go (pairing / mobbing). I previously thought that PRs represented a feature, but I don't think they do anymore. I think they represent a safe change to the codebase in the direction of a feature.

\n

As a rule of thumb, more regular changes to the codebase is better. Big PRs make regular changes more effort, so probably decrease their frequency. The alternative is less diligent review (easy), or higher reliance on tests (hard).

\n

So just make functional changes, then?

\n

You can't just not do either of these kinds of changes, though. Either your code will never add new features (your product team and users hate you) or your code is horrible to work with and speed of iteration slows down (your engineers and users hate you).

\n

They're both parts of the code rainforest, like bugs and fungus. The problem is that aesthetic changes take quite a bit of human understanding and produce quite a bit of visual noise to a diff. If something's been renamed globally, there could be a lot of files affected. Likewise if you edit the arguments to a function, or move something from one place to another.

\n

In a visual diff (like you get on GitHub or BitBucket) these kinds of changes are given just as much visual weight as adding a function or changing its name. It's up to the human doing the review to recognise this as noise over signal.

\n

Okay, so do them both but separately

\n

I want to work on stricter segregation of functional vs. Aesthetic changes in a PR. Martin Fowler (in his book Refactoring) would encourage us to i) plan the change, ii) refactor to make the change easily, and iii) make the change.

\n

Pragmatically, and I'm sorry, Martin, I find it easier to recognise a lot of the necessary aesthetic changes while I make the functional ones. That's why I code with a notepad in front of me, to write down things I need to change or things which pop up.

\n

This has the added values of:

\n\n

What now?

\n

You can separate out your work via commit or via PR. I'd advise by PR, because you can pick different reviewers for each. That can spread knowledge about your codebase, and about general refactoring principles. This can be really helpful for more junior engineers.

\n

When opening multiple PRs, you will have to address the visceral feeling of shipping a feature to production and leaving your little JIRA card in \"in progress\". I'm sorry. If you've got feature-focused product teams or management, you might also find this a politically difficult move. In which case: open a PR with changes stored by commit. You can encourage reviewers to review a PR by commit, and do a mob review if you want to share the knowledge.

", "slug": "2022-04-17-why-is-this-pr-so-big"}, "2021-04-08-just-enough-software-design": {"title": "How much is just-enough system design for new apps and software?", "author": "Thomas Wilson", "date": "2021-04-08T00:00:00", "book_review": false, "preview": "I wrote this because of a paralysing problem in coding: how much should I design my new app\u2019s architecture before I dive into code if I can only learn about my app\u2019s architecture b", "content": "

I wrote this because of a paralysing problem in coding: how much should I design my new app\u2019s architecture before I dive into code if I can only learn about my app\u2019s architecture by coding it?

\n

I\u2019m building Dash Dot, an interval timer iOS app from scratch, and this is the problem I\u2019ve been facing this month.

\n

The temptation is to answer all possible questions about your app before you start coding it, but you have to resist. It\u2019s good to have an awareness of what parts make up the whole of your system. If you don\u2019t, you\u2019re going to have to refactor and restructure your code frequently, especially at the beginning. But if you wait too long, if you only answer questions, then you\u2019ve got only theoretical answers.

\n

The issue is keeping your code and your design in-step with each other. If your code gets ahead of your design, it\u2019s a mess and you\u2019ve got to refactor and wrangle chaos. If your design gets ahead of your code, you\u2019ve got a monotonous boring slog to just implement (potentially over-engineering, or outdated) solutions to changing problems.

\n

Code is discovery.

\n

Design is discovery.

\n

But they\u2019re different kinds of learning, and you need them both. You can split the things you know about your software into two buckets:

\n\n

As you become a more experienced software engineer and architect, more things are in the Obvious bucket, and less things are in the Emergent.

\n

The problem with Emergent Properties is that they are often Unknown Unknowns. Of course, this is a spectrum too. The more you deal with software architectures, the more you know the kinds of boundaries that become problematic.

\n

Building the code means we learn more, but not knowing enough means the code we write is less useful. There are some lessons we can learn without coding. My advice? Do just enough design so that you can maximise your learning by building. How do you know how much is \u201cjust enough\u201d? That\u2019s the whole problem, mate.

\n

I\u2019ve been working on the meta skill of asking myself \u201cis this enough design to get going?\u201d, and then accurately answering myself. That\u2019s what I want to share and talk about.

\n

The Takeaways

\n

We\u2019re all busy, here\u2019s what I\u2019d recommend:

\n\n

Swinging the pendulum

\n

My thoughts and approaches to building a new codebase have swung quite a bit over the last two months. I have been developing a la

\n
    \n
  1. Test-driven development (TDD): build all code from the ground up with tests first. The satisfying red, green, refactor cycle is very rewarding.
    2. \n
  2. Interpretive movement development: do what feels right in the moment, just validate with the UI, man.
    3. \n
  3. UML-driven development: spent literally hours creating classes, methods, and relationships to understand the system.
    4. \n
\n

TDD

\n

TDD was my first approach. It\u2019s how I learned Rails back in the day (or at least how I was encouraged to). I have often bemoaned a lack of any testing in a lot of the professional projects I\u2019ve worked on and I thought to myself \u201cthis app will have flawless testing. I will be the jealousy of the town\u201d.
\nWhy was I doing TDD? Because I liked the idea of the finished product. I liked having a codebase which I knew worked, it was inarguable. I had green ticks on my CLI, and the knowledge that a particular ticket or branch were complete.

\n

I spent a couple of weeks heavily pursuing this goal. However it fell apart. When you\u2019re building early systems and foundational code it is highlly likely that things will change. In fact, I\u2019d say it\u2019s certain. If you\u2019re writing perfect code on day 1 then bully for you but boy am I not that kind of engineer.

\n

\u201cBut Thomas, write your tests first to help design your API\u201d. Yeah, actually good criticism. I agree - I think having code and tests consume the API of a class forces you to think about abstraction early. It forces you to decouple things. However, you don\u2019t know everywhere your code is going to be consumed, especially on day 1. You don\u2019t know when certain parts of the codebase are going to grow in complexity and size (and reduce in readability) and need to be split out. And now you\u2019ve doubled the work required in a refactor: you can\u2019t quickly and easily move code about, chop it up, rename it, etc.

\n

\u201cBut Thomas, the tests mean that your API surface remains stable so that even when you do that kind of refactoring, the end result still acts as expected\u201d. Right again, in theory. This is great when there is other code in your project which already depends on the stuff you\u2019re refactoring, and you want absolute certainty that what you\u2019re doing won\u2019t break a consumer. But that\u2019s just not what\u2019s happening here. This is the first step of whittling away the wood to let the sculpture emerge, I don\u2019t have to be delicate everywhere. I really wanted TDD to work for me here, and maybe if I was more intelligent and could preemptively know my API it would work. Or, if I was further into the project, it would let me know that I\u2019m doing okay with my refactor.
\nAs a tool for writing the first bits of a new project, TDD just did not work for me.

\n

Interpretive movement design

\n

Talk about a kickback reaction. Freed of the expectations of TDD and of the need to really write atomic and comprehensive tests, I just went about doing the thing every engineer loves to do: write code.\nI created classes, and modules and methods and functions and utilities and it was lovely. I named things in a way that made sense in the moment and things felt right. I wasn\u2019t constrained by anything and could get my ideas onto the screen quickly.

\n

This is a great example of where the \u201csoftware engineering as a craft\u201d argument gains credibility. This was a swing too far away from discipline and rigour, and towards creativity and reactive-ness. There was no structure to wrangle my code into readable, clear ideas.

\n

It didn\u2019t force me to notice similarities in my codebase. It didn\u2019t encourage me to make similar solutions for similar problems, and I ended up writing code which was tightly coupled to its context. Code should be decoupled. The canonical example for this was when I found myself with three Entity classes (the ActiveRecord-like classes which wrapped several persisted entities, like a \u201ctimer\u201d) and three drastically different approaches to similar behaviours. I had different APIs and implementations for how I validated, persisted, updated/deleted my data - I stored different bits of information about them and under different names.

\n

This was a bad approach - I had let myself get too excited with the joy of writing code, and hadn\u2019t taken a step back. \u201cBut Thomas, couldn\u2019t you have exercised a little bit of self-restraint?\u201d. Look. Yes. I have known for a very long time that I, as a person and professional, would much rather learn and discover while and through doing, rather than plan and prepare beforehand. It\u2019s mixed-blessing. Self-knowledge isn\u2019t about trying to change these things but rather putting myself in positions where this isn\u2019t a problem (wisdom to know the difference, and all that).

\n

The interpretive-movement style of development was useful. It helped patterns emerged and it also helped me do a lot more than I did with TDD. The result was always on the output: I want to see this data on the screen, I want to be able to have these kinds of interaction. Unlike TDD I was thinking a lot more as a real-life human user of my software, not like a software user of my software. But it needed to be paired with a little more forethought, and something which would help me anticipate similarities before they occurred.

\n

UML-driven development:

\n

Does anything feel quite so engineer-y as drawing bloody giant UML diagrams. You know the ones, with the boxes and class names and methods and arrows. They\u2019re great. I started drawing these when I came to the next logical part of my app (i.e. how do I, as a user of the app, do a timer).
\nI sat down with the fantastic (and free) [diagrams.net] (formerly draw.io) tool to draft up the parts of my system, what they would be called, how they would communicate, what was similar and unifying, and what were the distinct parts.

\n

I immediately made the decision to use this diagram as a sketch or an outline. I didn\u2019t want to specify every method, every relationship, every movement. It was about the high-level system design, and not about the specifics. UML diagrams may feel productive, but at the end of the day they\u2019re not code.

\n

For me, facing myself to write this broad-outline UML diagrams was just enough design to make the code I was writing feel productive. It guided the direction and structure of the work I was doing, but it was vague enough that I could split things our and change implementation details. For example in a couple of places, I leaned heavily into the Dependency Inversion or Inversion of Control but these didn\u2019t need to be specified in the diagram before hand

\n

I knew this approach was just-enough design because before I started writing code I noticed when too much responsibility was being put in one place, and when similarities between components started arising. Just like the frustration of UI/UX design - it was impossible to design a good system by focusing wholly on the components. Components should serve the system and architecture as a whole.

", "slug": "2021-04-08-just-enough-software-design"}, "2022-07-06-vibe-check-5": {"title": "Vibe Check #5", "author": "Thomas Wilson", "date": "2022-07-06T00:00:00", "book_review": false, "preview": "# Vibe Check #5\n\nWe're over half way through the year. Which is good. The second half of the year is definitely my favourite half, with late summer, autumn, and Christmas ahead.\n", "content": "

Vibe Check #5

\n

We're over half way through the year. Which is good. The second half of the year is definitely my favourite half, with late summer, autumn, and Christmas ahead.

\n

I'm gearing up for my personal summer out-of-office. During which I will be mostly in-office, but using all my my free time to enjoy the balmy but brief British summer breeze. Just like life, summer is too short to spend unintentionally, and with the days already getting shorter I'm on a timer here.

\n

Anyway, June 2022 has been a terrifying and exhausting month. It started with taking my partner to A&E, which moved quickly to some emergency surgery. This, followed by a (frustratingly) slow recovery, has taken near all of my mental energy and attention. Luckily they're really into their recovery now, and I'm walking out the last of the wobbles on myself.

\n

It's amazing how things like this can eat into you and narrow your vision. It's been good to get through some of these days.

\n

Other days have been less dramatic. And I've managed to find a pretty cool moments, like:

\n", "slug": "2022-07-06-vibe-check-5"}, "2021-02-12-website-design-2-0-changelog": {"title": "Website Design 2.0 Changelog", "author": "Thomas Wilson", "date": "2021-02-12T00:00:00", "book_review": false, "preview": "I've redesigned the blog. This post just covers the technical whats and hows of it all.\n\n## What's changed ?\n\n- **New Dark theme colours**: Look around. Look at this dark purply-gr", "content": "

I've redesigned the blog. This post just covers the technical whats and hows of it all.

\n

What's changed ?

\n\n

Yeah but how?

\n

I bloody love talking about workflows and processes. By brevity here is a mercy and a kindness:

\n", "slug": "2021-02-12-website-design-2-0-changelog"}, "2021-05-21-productivity-is-a-daily-ritual": {"title": "The Weekly #41: Productivity is a daily ritual", "author": "Thomas Wilson", "date": "2021-05-21T00:00:00", "book_review": false, "preview": "The Weekly is a 1000-word-or-less essay on something I\u2019ve been thinking this week. Let\u2019s talk about how productivity is (basically) a scam and how daily and weekly rituals are the ", "content": "

The Weekly is a 1000-word-or-less essay on something I\u2019ve been thinking this week. Let\u2019s talk about how productivity is (basically) a scam and how daily and weekly rituals are the backbone of any sane person's productivity.

\n

I once had the goal to move to Paris. I didn\u2019t achieve it (there was a pandemic). I had a goal to learn Italian (laziness). We\u2019ve all got visions of our future where we\u2019re cleverer, skinnier, more intelligent, or in my case simply the same person but somewhere else.

\n

But we don\u2019t do visions. We reach them. But actually we don\u2019t reach them because the Hedonic Treadmill keeps us all both in motion and stationary at the same time.

\n

I\u2019m going to put the tinfoil hat on properly in about 500 words, but I genuinely don\u2019t think productivity people want us to be productive, and \u201cproductivity\u201d isn\u2019t a thing. It\u2019s a thing only because businesses and organisations need way to quantify the impact they\u2019re having.

\n

You are not a business. You are an individual. You do not have to justify yourself economically to anyone. You are whole, you are complete, you are enough.

\n

But we all want to be just a little bit\u2026more.

\n

The secret to doing that little bit extra is in ritual. Every day you\u2019ve got to wake up and do the hard work of redefining what \u201cbeing productive\u201d looks like. One day it will be writing a eulogy for a family member, the next it might be six hours of visual design work, or a board meeting. Can you compare these things? Maybe, but what a waste of mental effort you could have spent doing things you actually wanted to do.

\n

I\u2019m going to share what that actually looks like.

\n

My ritual

\n

There are two ways I store my productivity system: in my physical notebook (the Leuchtturm 1917 Hardcover A5 with Dotted Paper) and a digital Second Brain (Obsidian).

\n

I use these to do two things:

\n
    \n
  1. Weekly Note \u2014 Every Sunday I dedicate a double-spread on my physical notebook to a list of things I want to do that week. They\u2019re grouped roughly by work (\u2018ship feature x\u2019), personal (\u20182 x Runs\u2019), side-project (\u2018refactor below-the-fold section of landing page\u2019).
    2. \n
  2. Daily Notes \u2014 Every day I have a double spread in my notebook and a daily file in Obsidian. One side of my paper has a list of high-level tasks (\u2018go for run\u2019), and the other has a list of things I might have thought about (\u2018luck is about increasing your surface area\u2019). The digital daily note is infinitely editable. I use it as a scratch pad for writings, or sub-tasks, or links to things I\u2019ve done that day.
    3. \n
\n

Every week, before I create the next-weekly note, I review my previous week. I look at what I did during the days, I look at what I wanted to get done, and I index things: thoughts that came up, projects which might be important for long-term use.

\n

The entire process is vague and not-specific. But if I go into any more detail it\u2019s not going to be useful to literally anyone else. How many other people are working in a small laundry startup, building language-learning tools, and taking nerdy notes on a small subset of podcasts because one day maybe something will stick and I\u2019ll be able to sound insightful in a conversation. There are none.

\n

/Puts on the tinfoil hat/

\n

Despite not making it to an apartment in Paris (yet), I like to think that I am a productive person. I got a PhD and once knew a lot of French. A lot of people would like to think they\u2019re productive. Globally, the personal development market is valued at around \\$38b. There\u2019s a lot of money to be made by helping people be more productive.

\n

A pessimist would say there\u2019s a lot of money in making people feel unproductive, and that you can make them productive.

\n

People will try and sell you a framework, app, or system that will solve all your personal productivity problems. For a long time I was very committed to time-chunking, task managers, and efficient email. I don\u2019t religiously adhere to these anymore.

\n

Or worse, there are the Vaynerchuck-esque \u201chacks\u201d which promise, as Pilta Clark writes in the FT puts it, \u201cto transform useless, Solitaire-addicted sloths into hard-charging models of efficiency\u201d.

\n

Learning the click-baity 14 Must Know Tricks For Productivity From A Wall Street Manager isn\u2019t going to help you.

\n

That\u2019s because knowledge isn\u2019t the problem. We don\u2019t have a knowledge deficit. We have abundance. An overwhelming abundance, things we want to do, or should do, or feel like we should want to do. If only we had the time to achieve them.

\n

When there\u2019s \\$39b dollars at stake, and you want to keep it there, there are two things you can do:

\n
    \n
  1. Keep everyone feeling unproductive \u2014 make everyone feel like they\u2019re underperforming and need to keep up. Tell them they are unproductive and that your book or consultation or software are the only way to change that.
    2. \n
  2. Keep giving people new goals \u2014 as soon as you\u2019ve achieved one goal, move immediately to the next. Or why even achieve it, just drop it and move on.
    3. \n
\n

Most worthwhile goals require sustained effort. Fat comes back, muscles decay, French words disparaissent , and your fingers will forget a G-minor scale very quickly.

\n

The modern personal productivity industry is selling you a solution to a problem it created to benefit itself. People started making money off that. Loss aversion keeps that idea alive.

\n

Productivity is a daily ritual.

", "slug": "2021-05-21-productivity-is-a-daily-ritual"}, "2021-01-29-things-i-learned-25": {"title": "Things I learned this week #25", "author": "Thomas Wilson", "date": "2021-01-29T00:00:00", "book_review": false, "preview": "- **This etymology**: The word \"peculiar\" has come to mean odd or unique, so obviously its Latin root word (_\u200cpeculium_) means somebody's cattle. Cows were pretty valuable assets b", "content": "\n

What I've had on Rotation

\n\n

Cool Articles

\n", "slug": "2021-01-29-things-i-learned-25"}, "2021-02-27-github-actions-xcode-tests": {"title": "How to run Xcode tests for a SwiftUI iOS codebase with GitHub Actions", "author": "Thomas Wilson", "date": "2021-02-27T00:00:00", "book_review": false, "preview": "Tl;dr\n\n1. Make sure you've got a repo on GitHub.\n2. Make sure you've got at least one set of tests in your Xcode codebase.\n3. Create the file below in `yourproject/.github/workflow", "content": "

Tl;dr

\n
    \n
  1. Make sure you've got a repo on GitHub.
    2. \n
  2. Make sure you've got at least one set of tests in your Xcode codebase.
    3. \n
  3. Create the file below in yourproject/.github/workflows/main.yml:
    4. \n
  4. Replace the yourprojects and YourProjects with your file name
    5. \n
  5. git add .github/workflows/main.yml && git commit -m \"Add test GitHub action\" && git push
    6. \n
\n

```yml

\n

Run My App's tests whenever someone pushes to main or creates a PR into main

\n

name: CI

\n

on:\n # Triggers the workflow on push or pull request events but only for the main branch.\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]

\n

We're only going to have one job, test but you can add this

\n

jobs:\n test:\n runs-on: macOS-latest\n steps:\n # Checkout the code to the working directory\n - uses: actions/checkout@v2\n # Install xcbeautify so the logs are human-friendly\n - name: install xcbeautify\n run: brew install xcbeautify\n # Run the tests\n - name: Run the xcode tests\n run: xcodebuild clean test -project YourProject.xcodeproj -scheme YourProject -destination \"platform=iOS Simulator,name=iPhone 12\" | xcbeautify

\n

```

\n

What are Github Actions

\n

They're bits of code you write which are executed whenever something happens on your GitHub repo. These bits of code can do whatever (they're just functions that run on a container), like:

\n
    \n
  1. Run the tests in your repo (what we'll be doing today)
    2. \n
  2. Build an artefact from source code then publish that to a directory
    3. \n
  3. Send out an e-mail or hit a web-hook whenever something happens
    4. \n
  4. Build your static site and upload it to S3, GitHub pages, or wherever.
    5. \n
\n

If you've used other tools, GitHub actions are like TeamCity, CircleCI, Jenkins, or any other CI/CD pipeline tool, but built right into GitHub. If you've not heard of, or used those tools, I explain a bit more about it below.

\n

The working parts

\n

We don't actually write \"actions\", we write workflows, which contain one or more jobs, which contain one or more steps.

\n

The details for a single workflow is written in yaml, as common plaintext format used by a lot of DevOps tools.

\n

We put the yaml file in yourproject/.github/workflows/workflow-name.yml where yourproject is the root directory of your project and workflow-name is the name you wish to give the workflow.

\n

There are three root-level yaml properties we're going to set:

\n
    \n
  1. name Is the human-readable name for the entire workflow. Call this \"CI\" or \"Run all tests\" or \"Send e-mail\".
    2. \n
  2. on configures what exactly needs to happen for this workflow to run. By default, every job and step will run on every event.
    3. \n
  3. jobs Is a list of the jobs we'll be doing. In this example there's just one: running the tests
    4. \n
\n

yaml\nname: CI\non:\n # Triggers the workflow on push or pull request events but only for the main branch.\n push:\n branches: [main]\n pull_request:\n branches: [main]\njobs:\ntest:\nruns-on: macOS-latest

\n

Not how we're telling the test job that we're going to run on macOS-latest. Github gets us a container running that environment, which is cool.

\n

Checking out the code so we can access it in our tests

\n

By default, a job in a GitHub action just gives us an empty container, so we need to tell it to copy the code into our current working directory.

\n

There's an easy way to do that: the checkout action is a third-party GitHub action that checks out our current working branch to the current working directory. Here are the Checkout docs.

\n

By adding the following we make sure we have access to our code:

\n

yaml\njobs:\n test:\n runs-on: macOS-latest\n steps:\n # Checkout the code to the working directory\n - uses: actions/checkout@v2

\n

Installing xcbeautify

\n

The default Xcode logs are horrible: they're verbose and unintelligible. Xcbeautify is a CLI tool that formats them to give us more readable useful information.

\n

Luckily the macOS-latest platform comes with homebrew, the MacOS package manager, already installed, so we just need to tell our test job to install it:

\n

yaml\njobs:\n test:\n runs-on: macOS-latest\n steps:\n # Checkout the code to the working directory\n - uses: actions/checkout@v2\n - name: Install xcbeautify\n run: brew install xcbeautify

\n

This step in our job has two things:

\n
    \n
  1. name is a human-readable name, useful for us and the UI in GitHub
    2. \n
  2. run is the thing you want to type onto the CLI. When that's done, the job will move on to the next step
    3. \n
\n

Run the Test

\n

The last step in the job is to run the tests using the xcodebuild CLI tool. This is actually pretty easy and simple, just make sure you clean-up the names and details in the script below.

\n

Node how we're piping (i.e. the | character) the results from xcodebuild through the xcbeautiful command. That's a unix-ism, it's pretty powerful (or so I'm told, I'm just a frontend engineer here).

\n

yaml\njobs:\n test:\n runs-on: macOS-latest\n steps:\n # Checkout the code to the working directory\n - uses: actions/checkout@v2\n # Install xcbeautify so the logs are human-friendly\n - name: install xcbeautify\n run: brew install xcbeautify\n # Run the tests\n - name: Run the xcode tests\n run: xcodebuild clean test -project YourProject.xcodeproj -scheme YourProject -destination \"platform=iOS Simulator,name=iPhone 12\" | xcbeautify

\n

Commit, baby

\n

You're good to go, let's add the file we made to our git repo, make a single commit and push it up git add .github/workflows/main.yml && git commit -m \"Add test GitHub action\" && git push

\n

(We're assuming the main.yml file is the one you made, if you called it something different, change that).

\n

Go check GitHub

\n

Go to your GitHub repo, click the \"Actions\" tab, and watch with glee.

\n

Why can't I just run these things locally?

\n\n

You can. If you already know why, you can skip this section.

\n

I come from a frontend engineering background, where having test coverage has typically been difficult or different to the backend world. So answering this question is as much about learning facts/words as it is about understanding that the software design, development, and deploy process can be different. I know. I'm sure some engineers are tutting or shaking their heads at me. TUT AWAY, FRIENDS I'm standing in my truth here.

\n

GitHub's actions are part of a broader practice of CI/CD (continuous integration and delivery) in software. The idea of CI/CD is to commit code frequently, and have automated processes in place to detect the introduction of errors to the codebase.

\n

CI/CD can also automate any other previously manual processes, like building, deploying, or publishing software. The roles of CI/CD and automation can grow and expand as your team or product become more complicated. In this example we're just using it to run tests because well written tests give you confidence that your code does what you think it does.

\n

As teams grow, having actions run automatically means that institutional and team policies (like having all tests pass before anything goes into main, formatting code, running a smoke-test before publish) are adhered to without manual intervention. This reduces the barrier to actually publishing code.

\n

Integrating the CI/CD pipeline right where your code is hosted is different to having a third-party service watch your git repo. It's first-party and also probably cheaper (maybe).

\n

GitHub actions are versatile \"something\" that triggers these bits of code to run can be:

\n
    \n
  1. Someone pushes to your main branch
    2. \n
  2. Someone opens, closes, or comments on an issue
    3. \n
  3. Someone creates a PR from any branch to any branch
    4. \n
\n

For a full list, see Github's full list of events that can trigger a workflow.

", "slug": "2021-02-27-github-actions-xcode-tests"}, "culture-i-devoured-autumn-2019": {"title": "Culture I devoured in Autumn 2019", "author": "Thomas Wilson", "date": "2019-10-30T00:00:00", "book_review": false, "preview": "This season turned out to be surprisingly busy with culture. I started the month by talking at two tech events in London, meaning I arrived into the full body of the month having p", "content": "

This season turned out to be surprisingly busy with culture. I started the month by talking at two tech events in London, meaning I arrived into the full body of the month having produced some very technical, thoughtful output. I needed some really well-considered and curated culture to put everything back in the right places. Kind of like an internal tidy-up after I\u2019d rummaged through all of my draws to produce someone who was definitely more knowledgeable than I am, and probably a lot funnier and more extroverted.

\n

Historic Centre of Florence

\n

Italy, UNESCO World Heritage Site

\n

Hard as it is to believe now, a stonking four weeks later, but I started off this month in the centre of Florence, Italy. It\u2019s a city I\u2019ve visited every year since 2014, sometimes alone, sometimes with romantic partners, other times with friends. It is a place unlike anywhere else I have been on earth. The city is old and sprawling, the centuries-old city wall no longer even resembles an outer limit. It is one of the centres of the European renaissance, a hub of craftspeople, artisans, religion, philosophy, and hot blooded commitment to creating something beautiful. I don\u2019t care that it\u2019s full of tourists (myself included). I don\u2019t care that I was only there for three full days, and that my Italian really has plummeted. I don\u2019t care that it\u2019s a romanticised ideal that I\u2019ve created of a city in a country with some very real economic and political problems, and a culture which I don\u2019t think would fit me very well at all. The city reminds me of the wonder and joy of travelling to new places, and to the higher ideals of art and craftspersonship which I value, but can be pulled away from by the urgency of the day-to-day. It is a city which speaks volumes to me, in a quiet, old language that I have to be very still and quiet to hear. The historic centre is a UNESCO World Heritage site, and I make the rules so I say it counts as culture, and boy am I glad to have had the chance to visit to visit there again.

\n

House of MinaLima

\n

Soho, London

\n

MinaLima are a design studio founded in 2002 to create the entire visual language and style of the Harry Potter universe as it was being brought from page to screen. They contributed hugely to the visual props in the franchise. If you\u2019ve seen the films, you have seen their work: The Daily Prophet (the wizarding newspaper), the most-wanted posters for Sirius Black and Bellatrix Lestrange, the Black family tree tapestry, the penmanship in Molly Weasley\u2019s howler that she sends to Ron after he flies a Ford Anglier into a magical tree. The whole thing is situated across four floors in a historic london terrace, with charmingly wonky floors, windows, and ceilings. The walls are full of all of the attention to detail that you could so easily miss by \u201cjust\u201d watching the films. I grew up with Harry Potter, the books and the films, and that house felt so wholesome and warm - it is a really wonderful example of an intersection between visual design and world-building. If you are in north-ish London and want to kill 20-40 minutes, go and take a look. It\u2019s most wonderful.

\n

Faith Hope and Charity

\n

The National Theatre, London

\n

This piece makes up the final in a trilogy of new work by Alexander Zeldin. I haven\u2019t seen either of the previous pieces, though I rather wish I had. Faith Hope and Charity takes place in a community centre in London across a couple of months, seeing a host of believably-guarded and warey characters, as they come for a free lunch and choir practice. While I was watching it, I felt the pacing to be unbearably slow at times - but on reflection, the whole thing was staged and timed exactly as it needed to be. You were never force-fed any ideas, and the eight-or-so principle characters tore you between a number of simultaneous plots or points of interest. Certain people and events became more of a centre-piece later on, but for most of it I got such a real sense of London: disjointed conversations hindered by people not wanting to share or give too much - because they either don\u2019t know things about themselves or are scared to let other people see them as weak or frightened. Of people deflecting questions and awkwards conversations by busying themselves, or talking about anything (the biscuits, the leaky ceiling, anything) other than the things which very much needed to be talked about. Susan Lynch, one of the actresses put it perfectly when she said that the piece is \u201cabout moments between people, and it\u2019s about small acts of human kindness\u2026 the audience is as vulnerable as the players\u201d. It\u2019s also the second time I\u2019ve seen Cecilia Noble on stage, and the second time I\u2019ve watched her command my attention - the woman is fantastic to watch.

\n

Akram Khan\u2019s Giselle

\n

Sadlers Wells, London

\n

I feel lucky that I got a chance to see this piece. Based on the classical ballet, in its characters and broad plot points, but has been adapted into contemporary movement and narrative by Khan\u2019s choreography and vision. There is always a risk when you see contemporary movement given to classically trained dancers. They could hold back from the rawer moments or the unclean lines. Ballet dancers like to look good, it\u2019s understandable. For the most part, if you weren\u2019t looking at them thinking about this - I don\u2019t think you would worry so much about it. Tamara Rojo\u2019s performance as Giselle was, appropriately, otherworldly. From innocence and smitten to fear-driven anger, she mixed vulnerability and strength in a way which I can\u2019t imagine ever being able to replicate. The first act was bullish, raucous, misplaced energy. Some wonderful folk dancing, animalistic movement, and very physical violence. The second act, all forty minutes of it, were heartbreaking, and I was furious when the curtain came down without letting me know what I need to do with these new emotions. It was wonderful to see the piece reimagined in this way, and set to a powerfully composed original score and soundscape, which pleased the contemporary dancer in me to no end.

", "slug": "culture-i-devoured-autumn-2019"}, "2022-05-22-mcc": {"title": "Meeting Cost Calculator", "author": "Thomas Wilson", "date": "2022-05-22T00:00:00", "book_review": false, "preview": "On a recent train from Oxford to London (and back again), I built a litte widget to help calculate the cost of a meeting. Or at least, the simple cost of the salary of people atte", "content": "

On a recent train from Oxford to London (and back again), I built a litte widget to help calculate the cost of a meeting. Or at least, the simple cost of the salary of people attending a meeting.

\n

You can find it here on my personal site.

", "slug": "2022-05-22-mcc"}, "2021-04-02-things-i-learned-34": {"title": "Things I learned this week #34", "author": "Thomas Wilson", "date": "2021-04-02T00:00:00", "book_review": false, "preview": "# Things I Learned #34\n\nWe\u2019ve made it to the Easter weekend. Spring has arrived here in London, which is to say it was 20 degrees C earlier this week and this morning it was 0, win", "content": "

Things I Learned #34

\n

We\u2019ve made it to the Easter weekend. Spring has arrived here in London, which is to say it was 20 degrees C earlier this week and this morning it was 0, windy, and overcast. This time a year ago, my mental state was dominated by COVID-19 (something I barely even think about now), but that also lead me to notice the beauty of spring for the first time. I\u2019m normally more of an autumn person. My wildflower seeds have started to come up, my tomatoes have been sown, and I made an asparagus risotto this week (largely so I could drink white wine while cooking, al la my middle-aged housewife dream).

\n\n

What I've had on rotation

\n

-Something New Justice by Justin Bieber (pop, 2021). After 2020\u2019s frankly insulting Changes, this new album from Bieber is a breath of humanity and honesty. The album doesn\u2019t rush but it\u2019s poppy, it\u2019s perhaps a bit laboured in its expression of love and gratitude for his wife but it\u2019s a good album. (links) -Something Old Ocean Avenue by Yellowcard (pop punk, 2003). I went back this week to try and find some good grunge and rock from the \u201890s but ended up getting stuck on this album. I\u2019m not regretful, and Nirvana can wait for me. Probably related to my We The Kings re-listen that I mentioned last week. I\u2019m not even really sorry, early \u201800s emo music is in my bones. (links)

\n

Cool articles

\n", "slug": "2021-04-02-things-i-learned-34"}, "2021-07-08-out-of-office": {"title": "Out of office: summer 2021", "author": "Thomas Wilson", "date": "2021-07-08T00:00:00", "book_review": false, "preview": "Summer has always been a time for _doing_ and living. It doesn't feel right to force at least one piece of writing out of my brain every week. Discipline and routine are useful t", "content": "

Summer has always been a time for doing and living. It doesn't feel right to force at least one piece of writing out of my brain every week. Discipline and routine are useful tools for living, but so is taking a summer break. I'm going out of office for the next couple of months, so I can focus on the latter. I want long cycles, solitary train rides, food eaten outdoors, and adventure. This is what summer is for.

\n

So there will be less writing in public, and more living in private for a little while. It's been a weird 18 months with a pandemic, but this year I feel I can have a more \"normal\" summer. So I'm going to do that. Shame that I won't be going to Florence, though.

\n

Take care and stay safe, I'll be back when the days start drawing in \u270c\ufe0f

", "slug": "2021-07-08-out-of-office"}, "loss-and-ed-2017": {"title": "Loss and my ED\u200a (\u200aED awareness week\u00a02017)", "author": "Thomas Wilson", "date": "2017-03-03T00:00:00", "book_review": false, "preview": "