So I saw this video...

Death Stranding, along with its sequel, is my absolute favourite video game ever, and probably one of my favourite pieces of fiction ever too; I've watched and read a lot about the game (not to mention I've played both releases a ton too). A good few months back I was watching a video about the making of the first game and during the video, around the 27:20 mark, the narrator says the phrase:

the game's core values of solidarity, empathy, and patience

This stood out to me. There was something about that phrase and what it meant given my experiences in Death Stranding and Death Stranding 2; it spoke to me enough that I jotted it down and kept coming back to it and thinking about it. It was a phrase I couldn't get out of my head.

Around the same time I was also doing a lot of thinking about, and note-writing about, code reviews. Although I've been working in software development¹ for a few decades now (I started in July 1989), I was quite late to the whole process of code review -- at least in the way we talk about it today. This mostly comes down to the fact that for a lot of my time I either worked in very small companies or I was the only developer around.

Given this, thinking about my own approach to reviews is something I've only really been doing for the past few years. I've made personal notes about it, read posts and articles about it, I've had conversations about it; my thoughts and feelings about it have drifted a little but seem to have settled.

The idea of that phrase from the Death Stranding video crept into this thought process, as I felt it nicely summed up what a good code review would look and feel like. Weirdly I also realised that, perhaps, the things I like and value about Death Stranding are also the things I like, value, and want to embody when it comes to code reviews.

One of the big selling points for me, with Death Stranding, is the asynchronous multiplayer aspect of it; the reason Kojima calls it a "Strand type game". I have my game, I have my goal, but other people can indirectly affect it, either doing work in their game that leaks into mine in a beneficial way, or by leaking into mine in a way that I have to clean up. There's something really satisfying about this asynchronous collaboration. That feels similar to the collective effort of working in a single repository, each person working on their own branch or PR, sometimes in tandem, sometimes in series, sometimes to the benefit of each other and sometimes in ways that block each other.

But that's not the point here. There's a similarity if I think about it, but I don't want to get too carried away on that line of thought. It's the phrase from the video I care about; it's the approach of involving solidarity, empathy and patience I want to think about more.

Solidarity

This, for me, is all about where you position yourself when you approach reviewing code. I sense things only work well if you view the codebase as something with common ownership. I've worked on and with a codebase where the original author invited others in to collaborate, but where they constantly acted as a gatekeeper, and often as a gatekeeper who was resistant to their own contributions being reviewed, and it was an exhausting experience.

I believe the key here is to work against a "your code" vs "my standard" approach, instead concentrating on an "our repository" view. That's not to say that there shouldn't be standards and that they shouldn't be maintained -- there should be and they should be -- but more to say that they should be agreed upon, mutually understood to be worthwhile, and that any callout of a standard not being applied is seen as a good and helpful thing.

The driving force here should be the shared intent, and how the different degrees of knowledge and experience can come together to express that intent. If a reviewer can see issues with a submission, with a proposed change or addition to the codebase, the ideal approach is to highlight them in such a way as to make it feel like we discovered them, not that I discovered them and you should sort it out. Depending on the degree of proposed change, this might actually be expressed by (if you're using GitHub, for example) using the "Suggested Change" feature to directly feed back into the PR, or perhaps for something a little more complex, or the offer to pair up to work on the solution.

Empathy

As someone who has written a lot of code, and so written a lot of bugs and made a lot of bad design choices, I feel empathy is the easiest of the three words to get behind and understand, but possibly the hardest one to actually put into practice.

When you look at a PR, it's easy to see code, to see those design choices, and to approach the reading as if you were the one who had written it, assessing it through that lens. In my own experience, this is where I find myself writing and re-writing my comments during a review. As much as possible I try and ask the author why they've taken a particular approach. It could be, perhaps, that I've simply missed a different perspective they have. If that's the case I'll learn something about the code (and about them); if that isn't the case I've invited them to have a second read of their contribution. It seems to me that this benefits everyone.

I feel that where I land with this is the idea of striving to act less like a critic and more like a collaborator, and in doing so aiming to add to an atmosphere of psychological safety. Nobody should feel like there's a penalty to getting something "wrong" in a contribution; they should ideally feel like they've learnt a new "gotcha" to be mindful of in the future (both as an author and a reviewer). Done right the whole team, and the work, benefits.

Patience

The patience aspect of this view of reviews, for me, covers a few things. There's the patience that should be applied when reading over the code; there's the patience that should be applied when walking someone through feedback and suggestions; and there's the patience needed by the whole team to not treat code reviews as a speed bump on the road to getting work over the line. While patience applies to other facets of a review too, I think these are the most important parts.

In a work environment I think it's the last point -- that of the team's collective patience -- that is the most difficult to embody and protect. Often we'll find ourselves in a wider environment that employs a myopic view of progress and getting things done, where the burn-down chart for the sprint is all that matters. In that sort of environment a code review can often be seen, by some, as a frustrating hurdle to moving that little card across that board. Cards over quality. Cards over sustainability.

It's my belief that this is one of those times where the phrase "slow down to speed up" really does apply. For me, review time is where the team gets to grow, to own the project, to own the code, to really apply the development and engineering principles they want to embody. Time spent on a review now will, in my experience, collectively save a lot more time later on, as the team becomes more cohesive and increasingly employs a shared intuition for what's right for the project.

This is not (entirely) a post about code reviews

The thing with code reviews, or any other team activities, is they don't exist in a vacuum. They take on the taste and smell of the culture in which they operate. It's my experience that it doesn't matter how much solidarity, empathy or patience you display during your day-to-day, if it's counter to the culture in which you work it's always going to be exhausting, it's always going to feel like a slog.

If leadership in technology, in software engineering, were to show more of these three basic qualities, they'd start to appear like they realise that they're working with actual humans, not producers of code; and I think we need more of that now than at any time in the history of coding.

Since I first saw that video, and heard that phrase, and had it run around my head, I've come to feel that it's not just a good mantra for code reviews; I think it's a simple blueprint for what good tech leadership should look like. If there was more "Strand-type" leadership in my chosen industry I feel it would be more open, more accessible, would offer more psychological safety and ultimately would result in teams, and projects, that thrive.

It's been a wee while since I wrote anything here (been about a month) so I thought I'd make mention of what's going on.

The main news is that I'm employed again!

Once the news about the Textual layoffs hit I, of course, started the job hunting process. This lasted for a wee while (and I have a couple of stories about that -- perhaps I'll write them up one day). I officially became "unemployed" on April the 1st (yeah, I know), and by the 23rd I had an offer for a new position, which I accepted.

As of the time of writing I've been in that position for a touch over 3 weeks and it's going really well. Right at this moment I'm doing zero Python work (that will change, I strongly suspect) and, actually, for the first time ever, I'm writing some TypeScript (it's tempting me to dive into that some more).

The team I'm working in are great and I'm also really impressed so far by the practices they have in place relating to getting stuff done. It's actually a refreshing change to work in a bigger organisation and actually find it not massively frustrating!

I'm also back to working from home full time. This isn't that big a deal for me as I spent around 22 years doing so up until 2018, and of course it isn't that big of a deal to many folk these days anyway thanks to the 2020- period. This prompted me to finally clear out the spare room (I've only been in here a touch under 5 years so of course there were a lot of "I'll sort those soon" boxes and stuff in there), buy a second desk, and make a work-coding area that is away from totally separate from my for-fun-coding area.

This has turned out to be a really good decision. I love my main hacking space in the living room, and have done a lot of work there, but that was always on the odd days here and there when I'd work at home. Now that working at home is a full-time role it felt important to make the distinction.

Weirdly though, all of this means that I'm spending less time working on personal stuff. When I was working at Textualize, most days, I'd be spending the best part of 3 hours in the day getting to and from the office. I thought that perhaps getting that time back would translate into having more time to tinker with my own stuff. Actually what I'm finding I'm doing is I'm spending the time on more general self-care and domestic things. This is a good thing.

Doubtless once things really settle down and I form my new routine I'll dive back into FOSS coding more again, and perhaps get back to streaming while I code.

Meanwhile though you can find me steaming many late evenings, mucking about on my PS5. Right at this moment I'm finally playing all the way through Just Cause 4 (a game I bought back in 2019 and never finished). In fact last night I finished the main story.

Expect a lot more PS5-based streaming nonsense over the next few months.

One other change I have made is to my VR video publishing schedule. For the longest time I had the time and was playing so much that I published a video every day. This wasn't a schedule I set myself, this was more a case of I was playing so much that to publish less frequently would mean there would be a huge backlog. These days I'm back to working 5 days a week (previously I was working 4 days) so I have to cram a little more into my weekends, and also I want to try and do other things during weekends too. So recently I changed to an every-other-day schedule.

And, really, that's about it. For now expect to see a bit less Python-based content on here, and also quite a bit less Textual-based stuff too. Currently my focus is elsewhere and it also seems that Textual is a bit of a moving target recently, throwing in some fun new bugs and breaking changes which are tricky to keep on top of. That said, you will still find me in the repo, lending a hand when I can, and of course in the Textual Discord too; just don't expect to see me quite so omnipresent there, especially during the work day.

While I have been on the receiving end of redundancy once before, that was after 21 years of service at a company that, while it was in part about software development, I would never have called it a "tech" company.

So, as of today, I can finally say that the "tech layoffs" came for me and I'm one of 67% of employees being let go from a tech startup.

Achievement unlocked, I guess?

To be clear: I'm not annoyed about this, I'm not even shocked about this; I planned for this from the off and realised and recognised the gamble I was taking back in 2022.

I am disappointed about this. Not in a "I'm disappointed in you" kind of way, but disappointed for all involved and what it says about how FOSS projects are funded and maintained.

It's been an interesting journey, and it's been a privilege to do something I've been wanting to do since the 1990s, when I first read the GNU Manifesto and subsequently watched the free software and open source movements develop and grow: work on FOSS for a living. In doing this I've developed my thoughts about the feasibility of such an endeavour, I've refined how I feel about working in very small teams, I've learnt a lot of useful lessons I'm going to draw on in the future (keeping a journal of my experience has been a great move; I have a lot of notes and thoughts written down that I'll be reviewing and distilling for myself over the coming weeks).

Most of all: it's been an absolute blast working on something that people are actually using to build cool things, and to provide help and guidance to those people when they've needed it.

So... what happens now? Well, of course, right now, I'm looking for a new position. If you're reading this and you are looking for someone who's kinda handy with Python and a bunch of other languages and who loves learning new stuff, or if you know someone who is looking for such a person, do drop me a line!

As for what happens with Textual, and my involvement with it...

Well, what happens with Textual is Will's call, of course. As for my involvement with it: I care about FOSS and I care about Textual; I also care about the folk who have been kind enough to use their time to explore it, test it, build with it, commit to it and make neat stuff with it. My intention, as long as free time allows, is to carry on being involved, both on GitHub and in the Discord server.

It's my sincere hope that, as a community of FOSS-friendly developers, we see Textual over the 1.0 line and beyond.

But all that starts next week. It's a bank holiday weekend and I think I might have deserved a run, a bit of mucking about in VR, a beer, and just a wee bit of down time.

This week, on Monday gone in fact, we moved office. We've now got a bigger space and, as part of that, bigger desks. Somewhat (but not entirely) coincidentally the work desk will also convert into a standing desk¹. Also also... I inherited a second screen for the desk too. Ever since the days of CRTs and video cards that supported it, I've been a fan of having at least a couple of screens in front of me, and now at my work desk I've got 3 (two external displays and the display of the MacBook Pro itself).

This caused a slight problem though: horizontally there's quite the spread of things to look at. This is fine, mostly I'm looking at the screen that's in front of me; the MacBook is to the left and the "second" screen is to the right, both with "other" stuff on them. In front of me is Emacs and my browser, which I flip between lots.

The problem is this: the MacBook needs to go to the left (because of physical layout), which means that despite me setting the screen in front of me as the "main" screen, the Cmd-Tab display (you know the thing: when you hit Cmd-Tab you see the icons of all your active applications) appears on the left-most display, which is the MacBook.

Not great. If I'm looking at the right-most display, and want to switch using the keyboard, I've got to look over to the left, as a worst case. That makes for a lot of unnecessary head-swivelling.

One quick Google later and Today I Learnt that the following pretty much solves the problem:

$ defaults write com.apple.Dock appswitcher-all-displays -bool true
$ killall Dock

As the name of the setting would suggest: once done, the switcher appears on all displays.

That's perfect.

Just over five years ago I got a message from my then employer to say I was going to be made redundant after 21 years working for them. After the 3 month notice period the final day came. Meanwhile, I found something new that looked terrifying but interesting. In the end it was less terrifying and way more interesting than I imagined it would be. It was fun too.

But... (there's always a but isn't there?)

In the four and change years I've been there the company got bought out, and then the result of that got bought up. As I've mentioned before I'm generally not a "big company" kind of person; in all my years I've found that I'm happier working in a smaller place. After a couple of buyouts my employer had gone from being 10s of people in size to 100s of people in size (and technically 10s of 1,000s of people in size depending on how you look at it).

This change in ownership and size meant the culture became... well, let's just say not as friendly as you tend to enjoy when it's a smaller group of folk. On top of that I was starting to notice that my efforts were making less of an impact as things got bigger, and I started to feel like my contributions weren't really relevant any more. There were some problematic things happening too: undermining of efforts, removal of responsibilities without consultation or communication, that sort of thing. Plus worse. There's little point in going into the detail, but it's fair to say that work wasn't as fun as it used to be.

That felt like a good time to start to look around. If work makes you feel unhappy and you can look around... look around.

Thing is, I wasn't sure what to look for. I was in the comfortable position of, unlike last time, not needing to find something, so I could take my time at least. Over the course of the last year I've spoken to many different companies and organisations, some big (yes, I know, I said I don't like big places -- sometimes what's on offer deserves a fair hearing), some small, but none of them quite said "this feels like me". In some cases the whole thing didn't have the right vibe, in others the industry either didn't interest me, or felt uncomfortable given my personal values. In one particular case a place looked interesting until I checked the CTO's socials and OMG NO NO NO AVOID AVOID (that was a fun one).

Then I saw Will McGugan saying he was hiring to expand Textualize. This caught my interest right away for two good reasons.

I can't remember how long I've been following Will on Twitter; I likely stumbled on him as I got back into Python in 2018 and I also remember noting that he was a Python hacker just up the road from me. We'd vaguely chatted on Twitter, briefly, in that "Twitter acquaintance" way we all often do (I remember one brief exchange about fungus on The Meadows), and he'd seemed like a good sort. A small company run by a "good sort" kinda person felt like a damn good reason.

The second reason was Textual itself. I'd been watching Will develop it, in open, with great interest. I had (and still have) a plan to write a brand new CHUI-based (okay fine TUI-based as the kids like to say these days!) Norton Guide reader, all in Python, and Textual looked like the perfect framework to do the UI in. The chance to be involved with it sounded awesome.

Now, I said two reasons, but there's also a third I guess: Will's pitch for applying to Textualize felt so damn accessible! I'm on the older end of the age range of this industry; for much of my working life as a developer I've worked in isolation from other developers; while I first touched Python in the 90s, I've only been using it in anger since 2018 and still feel like I've got a lot to learn. Despite all these things, and more, saying "aye Dave this is beyond you" I felt comfortable dropping Will a line.

Which resulted in a chat.

Which resulted in some code tinkering and chatting.

Which resulted in...

Something new.

So, yeah, as of 2022-10-10 I'm on yet another new adventure. Time for me to really work on my Python coding as I work with Will and the rest of the team as part of Textualize.

Or, as I put it on Twitter a few days ago: I'm going to be a Python impostor syndrome speedrunner!

Today is a fairly significant day for me. For the past 21 (and a bit) years I've worked for the same company. I know that, for lots of people in my industry, that's a hell of a long time to be in one position. It was a setup that served me pretty well; the company was small (I'm not much of a big company person), I generally got to dictate the development tools and direction, and I also got to work from home.

The working from home part was especially helpful as other life events involved me and happened around me. The job I've been in has seen a marriage come and go, and a move from Hampshire to Lincolnshire, and then from Lincolnshire to Midlothian. There's been a few adventures along the way.

But, three months ago, I got a call to say that I was to be made redundant. This sucked, obviously. It also appeared pretty stupid on the part of my employer: a company that is based around software had decided it no longer wanted an in-house software developer. A bold, and I think unwise, choice. From this point on they've decided to only go with contract developers and only contract developers from overseas (or so the story goes).

As it goes, things have turned out okay. Today is my last day with my old employer and, as I'm sat here typing this out while having some lunch, I'm actually glad that it's coming to a close and that I can get to move on.

I have a new employer, and will be starting in my new position during the first week of January. It'll be very different. It'll all be different. Not only will I be back working in an office (one where jeans and t-shirts are the norm, thankfully!), I'm also going to be working in an industry (as a developer still, of course) that I have no background in and no real knowledge of. It's going to be a seriously exciting challenge.

Over the next couple of weeks I've got a fair amount of background reading (and video watching) to be doing. This isn't so much that I can get on with the job of development (although there will be a good bit of that to do too -- who doesn't want to be trying to understand new options for development?), it's more about understanding the language of the industry I'll be in and so that I can understand the needs of my users.

Goodbye fashion retail and all related things. Hello genetics and... well, I don't know, I'm going to find out. :)