This week: I found out I didn’t get the senior role I applied for, I found out I probably passed my first two MSc modules, and I probably found out a third thing that I’ve forgotten. The universe should obey the rule of threes, otherwise it’s just a chaotic mess, and we can’t have that. No. I remain optimistic.

The job

Let’s start here, because goodness knows I have Feelings about this. Mostly those Feelings are “Damn, at last they have discovered I am an imposter.” This is because I am a self-taught software developer, and I secretly suspect that I am something of a fraud. This is in contrast to my writing and comedy, where I am also self-taught – but in those fields so is everyone else.

I am also fighting a little bit with a reflection of privilege, which is: why do I especially deserve this job? Presumably the successful candidate was closer to what the panel was looking for. And this is interesting to me, because in at least two other interviews (where I turned down jobs, oh foolish fool!) I was exactly what the panel was looking for. Sometimes this interviewing malarkey is a science and sometimes it is painfully similar to dating, except I really enjoy dating. Perhaps if dating was how I made my money I’d feel different about it.

I think I’ve also fallen victim to doing a lot of glue work. I’m currently running a procurement. I care about documentation and testing. I mentor people. I write the team’s weeknotes. I think on average I only spend about 50% of time writing code – and so, when it comes to interview time, I have much less to talk about when it comes to the crunchy technical stuff. I’m in an odd situation where I could ace a Lead interview but struggle with a Senior. I don’t know what to do about that: if I don’t do these things, they won’t get done – but it also means I’m losing out on work to devs who just…dev.

Which is a shame, because a) I dev good and b) the glue stuff is what’s making my other job work.

My other job

Further requirements came this week as we turned our gaze towards secondments, a unique characteristic in one of the schemes we look after. It’s run into some immediate problems, but thanks to the magic of logging a lot of data (I am learning the purpose of tools built to look through logs, because my good gracious it’s boring) I have identified the business problem that I need to work on to solve it.

Something interesting has happened with the programme that I’m supporting here, which is: because – and I think this is instinctive – folks recognised that this was a difficult problem, there’s all sorts of local hacks that different players have been using. Every single one of them doesn’t fully understand the system, but through trial and error they’ve hacked together an approach that works for them. And this is to be expected! In a complex domain like this the only rational approach is to probe, test, and repeat. Unfortunately that best practice never gets shared amongst the players – in part because there is a competition for resources at the heart of it – and so we have a lot of strategies and tactics around a phenomenally complex problem. It’s amazing. It’s the feeling I get whenever I look at a human body and all the local strategies that are at odds, even with other parts of the anatomy.

Anyway. We’ve got some big numbers to unpick and fix. All of it seems fixable though, and I feel immensely proud that I’ve continued pushing through. It is fundamentally solvable – but we have to pick apart the local solutions that people have poured time and energy into, and I know that’s going to be difficult. Still. Onwards!

Code things

This is mostly for me. Don’t worry if your eyes glaze over. It’s natural.

This week in development, I learned:

• Django has a handy decorator for overriding settings, which is a neat way to test an upload process that normally requires two steps but can be set to one in the settings. Find it in Django.test.override_settings.
• If you are testing a form in Django, you can test it very simply: Client().post(url, {"field_name": some_data, "other_field_name": more_data}). If you do take this approach, make sure you spell the field names correctly. If you don’t, it’ll fail with no obvious reason. Ask me how I know.
• In Python, class resolution is right-to-left, and not left-to-right (the way English readers read). So put mixins on the left (because they generally have no __init__method), and the base class on the right.