So as you’ve probably noticed, my NaBloPoWriMo posting has tailed off in the last couple of weeks. This is partly because I’ve been busy, and partly because my copy of Pokemon Shield arrived a fortnight ago. When I’ve had some downtime, the last thing I want to think or write about is a technical topic. I want to escape to a sunny field full of cute sheep and NPCs telling me I’m doing a great job and to follow my dreams of becoming the Galar region champion.
Work-life balance is important to me. In general, I don’t write code in my spare time. I enjoy writing code of course (otherwise I’d probably look for another job!) but I think I’d enjoy it much less if I spent my every waking hour doing it.
I would hope that the stereotype of a ninja rockstar coder who eats, sleeps and breathes code is now generally accepted as less than ideal. Certainly when I am CV sifting, I will look at the what the candidate has been doing for their actual job first, and only bother looking at anything extra-curricular if they have little professional coding experience. I want to know what the candidate will do at work, not at home!
I know from talking to other developers (especially less experienced ones) that there’s a pressure to ‘learn’ things in one’s spare time. There’s so much out there to learn, it can be overwhelming! In my opinion, any employer who wants to retain an employee should give them time and resources for learning and development during their working hours. I realise this isn’t always possible, however I feel like it’s hard to truly learn professional developer skills at home or even in a classroom. It’s one thing to spend half an hour reading a blog post, or a weekend trying out a trendy new language. It’s another to spend a few sprints trying to build a new thing on a new technology stack with your team.
Anecdote time. In a previous job I was sent on a one-day ‘Introduction to Kubernetes’ course. It was held at the Google offices and it all felt very trendy (with bonus trendy points for it being about Kubernetes, of course). Our company did not use Kubernetes at the time, but we were considering it as an option. These were the main things I learned that day:
- Google HQ has a huge Pikachu made of post-it notes on one of their meeting room windows
- If you are used to navigating an AWS console, you won’t have much trouble navigating a Google Cloud Platform console (caveat: this was 3 years ago so this may no longer be the case)
- Our small start-up absolutely did not need to use Kubernetes in any way, shape or form
Would I say I ‘learned’ Kubernetes at that course? Yes and no. I’ve never used Kubernetes in a production environment, and I wouldn’t know what to do if it went wrong. I definitely wouldn’t bother putting it on my CV. But on the other hand, I know when we definitely don’t need it! I know the kind of situations in which I might need to learn more about it, and I know where I’d look for that information.
So the course wasn’t completely pointless. But it was a structured, paid-for training course, during working hours, with a practical element, and I still don’t feel like I ‘know’ the topic. I would know even less if I’d just been messing around with it at home, with Hollyoaks on in the background. I might as well switch off my brain, and rest up for the next day.