This week has been intense. I feel like I’ve progressed a lot of work, but against the backdrop of world events, it all feels quite small. I think the trick is to focus on the small as a reflection of the large. I can help some people here, as much as I can, in the ways that I can. It’s not enough, but maybe it’s a start.
I’ve moved a couple of things forward this week. I’m doing some work on recruitment, because that’s an area where we’re all struggling at the moment. Hiring software engineers is generally difficult, and hiring in my organisation is generally difficult, so hiring software engineers into my organisation is difficult squared. One thing I’m hoping to bring in is a process of rolling recruitment, whereby we get into a process of running a competition every two weeks. At the same time, looking at the value chain for this work unveils a fascinating root-ball of other dependencies and things that need to be fixed first. That means it’s time to strap on my strategic thinking cap and work out which line to untangle first.
Underneath it – or tied up with it – are fundamental questions about how the organisation as whole is structured and funded. Who pays for people? Alright, now who pays to get those people in? Who pays for their learning and development?
There’s no good model, as far as I can see. Fully autonomous teams results in a fragmented landscape where everyone’s doing hiring slightly differently, and you don’t have an organisation but a federation of warring tribes all trying to do something none of them do well. Teams that are fully funded to do their own hiring, learning and development, and so on don’t benefit from economies of scale. Some elements of this process benefit from being commoditised, or at least productionised.
At the other end of the scale, I think there are some capabilities that are custom. C# has the idea of an
Interface, which is specific to strongly-typed languages like C#. You probably do need to know what one of those is to work effectively in a C# codebase – but how quickly? How long would it take one to learn
Interfaces, and other foibles of strongly-typed languages, if you were coming from a duck-typed language like ruby or Python?
This is an area of significant tension for me. Folks who already know everything about a team’s particular stack and can hit the ground running are great. They are also rare. Everyone takes time to get up to speed. Everyone needs support to understand the particular intricacies of the codebase/the documentation/the process, which I guarantee is unique to your team.
So there’s custom-to-the-language, which anyone can pick up if they know a bit about code already, and there’s custom-to-your-team, which is probably going to take 3 months or so to pick up. I don’t believe there’s anyone who really can ‘hit the ground running’, unless they’ve done months of prep and read all your code.
What am I saying? I think I’m saying that perfection is definitely the enemy of good when it comes to hiring, and that I’m going to keep hiring for general capabilities rather than specific knowledge about implementation details. If you know how to convince people on the front line to sacrifice speed for longevity, please let me know.
I’m trying to pick up Scala (again), in part because a friend of mine is doing a data science masters and asks for my help every so often. I really love trying to get to grips with new languages, but it’s tricky: and the course I’m following really throws you in at the deep end. It’s tough, really tough, but I think I’m making progress. The first assignment is incredibly complicated, but there are tests already written so at the very least you can feel like you’re making progress. It’s so much fun that I’ve stumped up £58 of my own British pounds to try to force me to see it through to the end. We shall see.
And hey, we’ll also see how long it takes someone to pick up a strongly-typed language coming from a duck-typed language! That’ll be fun!
If you’ve got some spare pennies, now would be a great time to donate to the Red Cross.