Although my first post on this topic stated that a mindset shift was the key to a successful transition, it also takes some time to achieve. It is a longer term goal that I am working towards, but I don’t expect to make it happen in a couple of weeks. So, while there may be a post about approach and progress in that category relatively soon, it needs some time to bake.

Hence, in this post I am instead going to talk about some of the more technical aspects to making the switch from being a manager to being an engineer. There is also a timeliness aspect to what I am about to discuss - if I am successful this should change quite quickly, so capturing and documenting the experience now while it is ongoing is important. As I write this, I am one day away from starting my new role, and have taken a week off in between roles, so I have had some (quarantined) free time to adjust.

Brain Fog

The first thing I want to talk about is what I think of as “Brain Fog” - this is basically how it feels for me now when I try to tackle a complex problem. Although I am likely viewing the past with rose tinted glasses, when I was regularly solving such problems tackling them was more execution than exploration. I knew large parts (sometimes all) of a solution going in, and barring red herrings or similar it was a matter of time, effort and fine tuning to get to done.

Now, as I step back into that way of working and thinking, there is an almost visceral resistance, like a fog that prevents me from seeing the optimal solutions as quickly. I take longer to figure out how to start, I am far more likely to rabbit hole on a poor choice, or forget about some simple thing as I explore a solution than I was in the past. It’s very similar to picking up a game you were once proficient at, but have not played for some time - you need to relearn those things that were once instinctive and automatic.

This is not the first time I have hit this particular resistance, and I know what I have to do to improve it over time. It sounds really obvious, but I have to actually do some engineering and solve some actual problems. The more real, challenging, and interesting these are, the better. You might think that my new role is the perfect place to look for such work, and eventually that will be the case, but it is also very hit-and-miss at the start - you have a lot to learn, a lot to absorb and quite a bit of it is going to be completely unfamiliar.

Personal Backlog to the Rescue

Thankfully, I have an alternative source for work, which has the benefit of having some familiarity to it, and the added bonus of being completely voluntary. I can pick it up and put it down at will, and the only person that I might end up creating tech debt for as I experiment and mess up is myself.

When I call it a “personal backlog”, that lends it false credibility. It is not a nice orderly list of well described, prioritised tasks, stories, and goals. Rather it is a vague list that mostly lives in my head. It consists of tech projects (some physical rather than code based) that I want to get done eventually but timelines are definitely loose..

Here is an incomplete sample of that internal list, as it existed 3 weeks or so ago:

• Configure new Windows install as development environment

• Configure pi-hole on home LAN test for performance issues

  • Alternatively, make Pi a games emulator

• Upgrade firmware on wireless router to stable, fix up old DHCP/MAC entries

• Get old Firewire-800 Drobo back on network

• Move files off Dropbox (cancel Dropbox) before subscription renews

• Mount monitors on new gas powered arms/bracket

• Cat 6 cabling runs up to attic routed/fished

• Re-cap Amiga 600/1200 boards, get 1200 tower to fully functional

• Trial some whiteboard/drawing apps with Huion tablet, especially for screen sharing

• Try out Pulumi for infra as code (golang)

• Get 2 x GigE interfaces connected and bonded in fileserver, migrate IP to new MAC

• Use Terraform to manage personal infrastructure (domains, website, blog)

  • Involves moving some pieces to AWS, fixing up existing AWS config

  • Puts config fully under SCM (content already done)

• Migrate expiring domains from GoDaddy to Route53

• Move old PC motherboard into Linux host, re-home all SATA drives to 5.25” cage

  • Drill bottom of case to allow mounting of existing 120mm Corsair AIO

• Replace Gaming PC case fans with Noctua low RPM

That is genuinely just a sample off the top of my head, there is more for sure, but you get the idea. Some of those things are done as I write this, others are in progress, new items have been added since, and some have been on that list a very, very long time. The two bolded points are the ones to focus on though, they are the most relevant to what I was going to be doing in Vela once I started.

They also synergise pretty well - I can use the Windows development environment to do the work on my personal infrastructure. Previously I would definitely have used Mac for this purpose, and that is one of the things I need to adapt to as I move to Vela. The familiarity here is that this is my own site, content etc. and it (mostly) works now, it’s just all manually handcrafted.

How to Windows

First up is the Windows environment. It seems odd to be so clueless given that I have continuously used Windows since ~1996 and for a considerable amount of time it was my only professional environment. That all ended around 15 years ago though, when I switched to systems engineering and to Mac OS and Linux as my primary environments. I have had a Windows laptop for the last year or so as a manager, but really it could have been any OS with a web browser and a VPN client. My use of Windows has been recreational (i.e. games) for a decade and a half, and now that had to change.

I had some information about the likely required tooling in Vela, and as it happened the recent recommendation of using VS code (Windows or not) lined up with that nicely. I also knew that I was going to need a Linux environment to work from on Windows, and that things had moved on significantly since I last did that (with Virtualbox and vagrant IIRC). I decided to give WSL2 a try and given the timing Ubuntu 20.04 seemed like a perfect option as an OS to learn. So I set out to configure:

• Windows Insider (to get to a WSL2 compatible build)

• New Windows Terminal (heard good things)

• VS Code

• Terraform (0.12)

• Chocolatey

• Ubuntu 20.04 (based on WSL2 backend)

• Docker (based on WSL2 also)

I have to say, the VS Code IDE is very nice (Terraform 0.12 foibles aside, which are being officially fixed now too), and I am especially happy with the way that the terminal integrates inside the IDE. I can start the Ubuntu shell, using Windows Terminal, navigate to wherever I want and then type “code .” and it fires up, no fuss with an integrated terminal ready to go. I have also been pleasantly surprised from a performance perspective, I had my doubts when I read it was Electron based, but Microsoft are doing a stellar job. I also have to give them props for their documentation - it is top notch. The fact that the Windows Terminal supports solarized themes out of the box is just icing on the cake. So impressed with Microsoft right now - Windows has come a long way as a dev environment.

At the moment I am actually finding the environment pleasant to use. There are very few barriers to using it, the integration so far is top notch and my confidence in the tooling is high. I am actually looking forward to tweaking and improving it, and that is not what I expected, at all.

Known Environment = Shortcut to Productivity?

The fact that I know what my target environment is, and I have used it in anger for a while should give me a head start once I start in my new role, at least in theory. Rather than spending weeks doing this on the job and getting frustrated every time I spend 20 minutes figuring out how to do something rather than just getting it done, I can (in theory) start with a somewhat known quantity and remove some unknowns and variables from the equation. How well this serves me remains to be seen, but I think it has been time well spent so far - going into a new role with some enthusiasm is certainly better than approaching an unfamiliar environment with dread.

Personal Infra as Code - Brushing off the Rust

My personal infrastructure (including this very blog) is much closer to fully automated. I have brought hand crafted instances and DNS zones under the control of Terraform, which exists in a private repo in git. I have used modules (which didn’t really exist the last time I used TF properly) to configure my VPC rather than using the AWS default. I’ve gotten used to (most of) the syntax changes that 0.12 introduced. I got email working for a domain (all out of code) that had been broken for a couple of years. My dev environment now sports shiny SSL certs thanks to Let’s Encrypt.

All of this got me to use intellectual muscles that had been dormant for quite some time, in a relatively low pressure and consequence free way. Every time I solved a problem, fixed a dumb typo or realised I had forgotten a piece of config, or even realised I misunderstood how something worked I could feel that “Brain Fog” lifting.

I didn’t get to everything I wanted to finish - for example I wanted to have Jenkins jobs to automatically deploy to staging, test and then only if passing would the deploy push to prod. Jenkins is running, and I have the deploy down to a one liner, but I haven’t hooked it all up yet. That’s OK though, because I feel like I am now in a much better place as I head into my first day at Vela. That first day starts in less than 10 hours, so I will wrap this post up here.