Just one topic this week. I need to talk about this, and it’s difficult for a few reasons, so I’ve not got energy for anything else. I am coming up against the first real professional failure of my career, and it’s hitting me really hard. Worse than that, I’m trying to work out how to talk about it without causing hurt. Please forgive me if, despite my best intentions, you’re hurt anyway.Continue reading
But first, the news.Continue reading
The world turns, and what was dead is come alive, and the seawater in our blood sings a siren song
February is upon us, my loves, and spring lurks around the corner like a clown. What shall we talk about this week?
I’ve kicked off a piece of work with a crack team of colleagues to sort out another business case. I have two simmering away at the moment, and both are on generally the same theme: we need a big thing funded. The thing is big and and its value is therefore diffuse. Who then should pay for it? End users, or the people who pay for the end users, are reluctant to pay for it because they don’t really see the benefits.
But maybe the value of a big thing is sometimes that it’s a big thing. Sometimes a flag is more than a piece of cloth. Sometimes a glance is more than a chance of eye contact. Sometimes a nation is more than a shape traced on a map.
It’s a real struggle, so if anyone’s knows some exciting new ways of calculating value for business cases that’s not solely based on pennies spent or unspent but human connections made and problems averted – wave at me.
More small steps, this time in the direction of the service I’m building for the CS LGBT+ network. There have been quite significant changes since the last time I wrote to you, though none of them are obvious from the interface. This is – god, I know I say this every time, but that’s the joy of getting older and learning from the brilliant people around you, it’s always true – this is the best work I’ve ever done. It’s still not perfect. There are plenty of things I need to improve. Nonetheless I know what I’m doing, and what needs to be done next.
For example, here’s a tiny little feature, laid out sensibly with an approach. It’s not a giant plan with deadlines and so on, but it’s evidence that I can look at a feature and break it down and then engage with each step. Which is tiny stuff compared to my day job, but also the best way I can find of maintaining my enthusiasm and prove I’m still okay at writing code. Setting aside software to get into management is approximately as hard as giving up heroin, and it’s much harder on your pocket. With the same reasoning I’ve broken up a workout plan into two sessions a week and put them on our kanban at home. Small tasks that are easily achieved, or sometimes sweating like a warm cheese, gives me an enormous sense of wellbeing. Parklife.
In two weeks time I will be halfway through my loan. I’ve been applying to things again, to get a sense of what’s out there and also to get some feedback on where my experience pitches me. So far I’ve had:
- a final interview for a role with an org that I’m dying to get, so I’m doing my best not to glance too hard at that particular hope in case it crumbles under the weight of my hopes
- an approach from Palantir, which was flattering but also deeply disturbing, like your worst enemy telling you they admire you or your schoolmates declaring you most like to be a successful serial killer
- An approach from various recruiters to do contracting, which – now that I’ve seen what we pay contractors – frankly looks deeply appealing
- three applications which fell at the first hurdle. They were for the same grade as the first in the list, and with each rejection the weight of my expectations on that interview further threaten to overwhelm it
- a good interview with a smart, forward-looking application where I’d be happy and stretched but nonetheless maybe not…fulfilled? More theraputic work needed there, I think.
That’s all for today friends. Take care, especially if you’ve got Covid
This is gonna get geekyContinue reading
Last week I wrote about how I was going to pick up the work I was doing with the Civil Service LGBTQ+ network. This week I’ve spent many hours reviewing and fixing minor bugs because I didn’t write enough documentation.
I also wasted an hour of a colleague’s time because I wrote an email hastily and left out important context, which meant she did a bunch of work for me that I didn’t need and so was wasted.
So this week’s theme is how writing is important, and how a lack of documentation is actually better than bad documentation.
The way that I write is more or less. That is to say I write poetry or I write emails. Poetry is a delight, because one can write outlandish, abstract phrases like
I was doorless when I met you and someone you quite fancy will find you unbelievably sexy and they can make up their own meaning, which means you can never be wrong, unless you’ve written something tremendously awful.
Abstraction and poetry are less well-suited to emails, where one must simply say
I don't have a door and I would like you to install one, which admittedly may make someone who is already fond of you more attracted to you but is unlikely to spur advances from a handyman. Even if you accidentally put a
xx on the end because you’re absent-minded and texting your mother at the same time.
Documenting code, particularly code that you suspect deep down will only ever be read by you, is therefore a weird place to be. There’s no feedback loop and the only person you can impact is yourself, and so frequently I don’t write enough documentation. Sooner or later this means I abandon the project, because at a certain size it’s too big to start writing documentation and it’s incomprehensible. Not this time. At the very least I know this is something someone relies on, so I’m going to do my utmost to make it better.
It also needs some kind of frontend/graphical user interface, which has not been my strength so far. So plenty of documentation there ensure I can come back to it without wanting to burn it all down and start again.
If you run a mentoring scheme, and you’re technical enough to know your way around the command line, please do try this out and let me know how you get on.
I got support this week from my senior people to run an experiment with a team in my department and GitHub Codespaces. It’s kind of new and kind of old as technology goes. GitHub offers you a virtual computer, hosted in the cloud, that’s charged by the minute. They can offer significantly more computing power than I can afford to buy, so it’s a no-brainer – why not have devs charged by the minute for an awesomely powerful computer?
The reason I say it’s kid of old is because it sort of reminds me of mainframe computing and time-sharing. Which is kind of cool – it means time is cyclical but progress is upward, so we’re all in a beautiful helix of progress.
Not a spiral. I have strong feelings about how spiral has completely taken over the meaning of its more accurate cousin helical.
In any case, with funding sorted, quantitative and qualitative data surveys standing by and the team fairly frothing at the mouth to get started, I’m really excited to kick off my first human experiment.
Of course you do.
As traditional this first week is when, if you sent “Let’s pick this up in the new year!” emails, you receive “Picking this up in the new year!” emails. It is a tradition as old as the hills, as long as they are very new hills and, if one looks closely, artificial.
This week I closed off some caretaking I was doing on a small service I was made responsible for. It got me thinking about how best to actually organise this stuff in the department, so I’m now on a mission to come up with some standard ways of organising people into teams, controlling access to the stuff they work on, and then managing how that changes over time. Because it will absolutely change over time, and a system perfectly etched in glass is no use to anyone.
This feeds into some strategic thinking I’m doing around the future of my profession in my department. At the moment I’m thinking about recruitment, retention, software, hardware, and standards. Does that sound about right? What else should I be thinking of when considering the next five years of software development? Thoughts on a postcard/email/Twitter message/by pigeon (you may not get your pigeon back).
As ever the strategic work is not just thinking about the thing, but thinking about how to sell the thing to everyone else in the organisation. If I think we should go in a direction, it’s no good me storming off in that direction because for plenty of folks that’s not a direction they much care about. As a naif I expected the brilliance of my idea to stagger people. It’s good for me to come to the realisation – again – I must do it at least once every six months or so – that I am not the main character in anyone’s story but my own.
My partner and I settled on some goals for this year. My current promotion is only temporary, but I’m enjoying it so much I want to keep working at this level for the foreseeable, so by the end of this year I’d like to have secured a permanent role at my current grade.
We’d also really like to move house: either further into Eine, or somewhere else entirely. Either way we need somewhere bigger: we have a wardrobe that groans with cloaks, knitting needles, board games and the other accoutrements of the modern yuppie lifestyle. We need space for at least two wardrobes. Perhaps even three.
Finally, I want to finish off the work I started with the Civil Service LGBT+ network. I’ve built a script to improve the mentor matching process, but I want to do something with it to make it useful to folks who aren’t as technical as me.
This week I wrote some HTML, updated some tests in Ruby, and started a business case.
This is not the balance I expected from my role, but it’s been exciting.
I also applied for a job that I don’t think I’m going to get, but that I couldn’t not apply to: it was just too perfect an opportunity.
Oh, and it’s Christmas. Merry Christmas!
I’ve been writing small commits as I update content on a site for educators to get support when they’re educating remotely. It’s not the most complex service I’ve worked on, and I honestly think I could further reduce what little complexity it has at the moment. But it is really nice to own something again, and to make the world a very small bit easier for citizens.
It’s also really nice to work closely with the policy person who owns this. I’ve set up the application so that content gets hot-reloaded, so she can see in real time how it will look. It’s more time intensive for both of us, but I think we get better outcomes.
I’m also writing a business case for some digital tools for the wider community. This is a totally different mindset, with long feedback loops and unclear requirements. You can’t do test-driven development with a business case. Instead, you’ve just got to write your most compelling argument and cross your fingers.
I really am so lucky to be able to do both in this job, even if it breaks my brain sometimes. Which brings me to the job I applied to: one where I get to do this permanently, for a department that uses my preferred language Python. I really don’t think I’ve got enough experience doing the job. In an ideal world that wouldn’t be a barrier, because people would look at my previous experience and hopefully recognise my potential – but here in the real world being able to do the job on day 1 and not painfully fuck it up is preferred. And that’s pragmatic and understandable, even if it’s a bit frustrating.
But given that this is the kind of role I want to do, and keep doing, I’m really hopeful that I’ll get an interview. That way I can identify areas I need to grow and be better placed to reapply in the future.
That’s it for this week. I’m enjoying my work, I’d love to do more of it, and I’m not doing it at all for the next four days. See you soon.
- Advent of Code got really difficult, although at least partly because I’m forcing it to be difficult
- Work started to slow down, just as I started to get to grips with it
- I got some honest feedback that was the brutal reminder I needed to be more considerate
In reverse order:
I am really frustrated with myself that someone had to give me this feedback, because I’ve banged on about this endlessly myself. Senior people, I have written crossly on these very pages, should really think before they speak. They should remember that they’re senior people before they remember that they’re experts.
As with sex and food, good intentions are simply not enough. I fell a long way short of my intentions, stepping into someone else’s domain without proper consideration for the time they’d spent working on a problem. I jumped in already assuming that I knew more than they did, and with a pinch of wanting to prove that I could be valuable. I’m going to cut that out.
On the plus side, I’m so lucky that someone felt comfortable giving me that feedback. It shouldn’t be necessary, but at least I’ve had it, and now I can correct myself. So that’s good.
Work is starting to slow down for everyone, I think, because of the impending festivities. So emails are starting to bounce back from polite but firm out of offices (outs of office?). So out of a desire to write a little code, and to be useful, I’m covering a little information service. So far I’m not writing any backend code, but I am re-familiarising myself with GitHub Actions and the language we use to describe how we deploy code into a production environment. The language is called YAML, which stands for YAML Aint Markup Language. The first YAML stands for YAML Aint Markup Language. The first…
You get the picture. It’s recursive, which is a topic I covered last week and will likely cover again. In fact, it’s come up as I’ve been writing Python in a functional style. The other thing we insist on in functional programming is immutability: that things can’t change or be changed. You can create a copy, but that copy too can’t be changed. It forces you to think about things quite differently.
I’m finding myself applying that thought process to deploying code. The binary package that we deploy should ideally be immutable: nobody, even me as the developer, should be able to poke around inside it. If there’s a problem with it, we should fix the code once at source and then redeploy the binary. This is at odds with the traditional approach, which is caring for servers like they’re pets and jumping into them every so often to mess about with the environment or similar.
“Redeploy” is a weasel word here that actually covers a lot of work. The binary has to be properly tested, and once it’s tested, we want to promote it into a testing environment so people on our team can try their best to break it. From there, we want to promote exactly the same artefact into production. The slower we do this loop, the longer it takes to get changes into the hands of users.
This is why people like me obsess over small changes and automating tests as much as possible. This is what I’ll be working on over Christmas, I think.
Advent of Code got impossible this weekend, and it really killed my enthusiasm. I’m also finding I have less time? less desire? in these very dark evenings. Instead I’m just getting cosy with m’buddy Salem and drinking a lot of tea.
Maybe in January, eh.
As I said last week, I’m trying out the functional programming paradigm for this year’s advent of code. It’s a really enjoyable whole-brain workout, and I feel like I’m finally properly gripping recursion, iterators, and even decorators. I am becoming more and more confident as a Python dev every day.
This is not supposed to be happeningContinue reading
This is the end of week 3 in my new role. I’m still not feeling like I’ve fully grasped everything I need to, but I’ve met more people and figured out more of the space I’m working in. I know I should be content with that, but I’m not. It doesn’t feel like I’m working hard enough.
But I have written a bunch of code, so at least I’ve got some serotonin this week.Continue reading