Writing This Blog - Part 1

Created: 2024-01-03

Welcome to the first post on this my new blog. As seems semi-traditional for a new blog, I talk about:

• Why I decided to build a blog,
• What kind of content might you see on here,
• And why you might be intereted in the content here.

For those interested, the codebase for this site can be found as a read-only copy at https://github.com/strottos/strottos.dev-public. This contains all the code except the GitHub actions CI has been redacted on that repository for security reasons, but the remainder of the codebase should be in tact.

Feedback very welcome by contacting me through the methods below (see the footer links) or even better, raising issues in this GitHub repository.

Why this Blog?

There are essentially the following reasons this blog exists:

1. I like sharing knowledge and I believe I have a lot to share that is useful.
2. A large part of my job is spent training engineers and I'd like to be able to deliver some of the content that in a more streamlined way and to multiple people (and I guess even when I'm sleeping now).
3. Teaching is the best way to know if you understand something.
4. It's a showcase of my talents/ability.
5. It was a chance for me to finally learn frontend development.

I'll expand on each of these points briefly now.

Knowledge Sharing

Firstly I think I've a lot to give, I doubt I'll ever write everything that's currently in my head to post here, let alone the things that might occur to me in the future, but one article is better than no articles.

In my time I've learned a lot about coding generally, about using both UNIX and now Windows systems to be productive, about deploying things to production and various good practices around all these and more. Some of this learning journey has been bumpy: smoothing it out for others feels like a good use of my time.

I have well over 10 years experience in some kind of IT engineering as well as a PhD in Pure Mathematics and two Masters degree's in some form of Maths and Physics.

Experienced Teacher/Trainer

One thing I've learned over the past few years is that I'm quite good at explaining things. I generally get a lot of good feedback from engineers I've helped train and I really love doing it.

I've been fortunate enough to spend one-on-one time with a lot of my engineers and whilst this is clearly highly productive, the downside is that it takes a lot of my time. I want to maximise this face-to-face time with supplementary learning, documentation, guidance and advice. This way I can focus on the core issues that require training and support.

To be brutally honest, it also gives me extra time to play with my cats and it gives whomever I’m working with the freedom to read at their own pace and refer back to anything they might want to. Win/win.

I think one insights I've been lucky enough to gain in the past few years is what some people struggle with when they're learning something. This is another real tangible benefit of one-on-one training, people don't have to sit at the back and pretend they understand, they can really tell you what they don't understand.

I was really fortunate when I started in this field to have been surrounded by really good people who knew a lot and they taught a lot of it to me. Plus I genuinely think there was less to learn when I first started in 2006 and I got away with Google to a large extent. These days I think there's so much that knowing what to Google is a bit challenge. I'm hoping this can help engineers with that vital skill.

Lastly I'm well aware of what it's like to sit and not understand something thanks to the multitude of seminars I've sat in as a Maths PhD student. Whilst I'm sure they were very good, I probably wasn't as good a mathematician as some and got left behind at times (probably one of the reasons I became a software engineer really). I've seen the same thing happen a lot in IT too where the curse of knowledge cognitive bias becomes highly non-productive. I think I'm reasonably good at not falling under this bias, though I'm keenly aware I'm still affected by it as we all are.I’m deliberately styling these articles to be accessible and easy to follow; how well I do that is, of course, up to the audience. I’ll definitely be clear when I’m writing about topics that are new to me, or that I don’t have much experience in. Kind of like this article!

Training Myself

I think we've all been there when we think we understand something but then realise we don't. I've often found when I teach something is when I truly learn how something works. Sometimes when explaining something I realise I don't know exactly how something works (or at least can't remember) and I have to go back to the drawing board a little bit. This is a really good thing for me and something that I suspect people in most disciplines should strive for.

Branding

This is my least favourite reason for doing this but it's factually correct. I'm sure that if everyone is honest this is at least part of the reason for doing something like this and whilst I might be a bit embarrassed it's true, I won't apologise for it but I truly hope this isn't the only thing to come out of this.

Teaching Myself Frontend Development

To the last point, my background is largely as a Software Engineer (backend focussed) and a Platform Engineer (or SRE or DevOps Engineer or Cloud Engineer or whatever you want to call it) but not really as a frontend developer. I've certainly done my share of frontend, and I like to think of myself as reasonably full-stack, but the fact is frontend is my weakest point and I wanted to improve my skills here. Now I've no doubt experts in frontend will look at some things I've done and say to themselves "that's not great" as I have known myself do when I look at things others have done when I "know better". Regardless, this was the best job I could do at the time of writing and I'm really proud of how it turned out.

Contents

As for the contents of this blog, here's a rough list of my interests that you may see some articles on in time:

• How to successfully build software in IT.
• All things DevOps/Cloud/Platform Engineering/IaC/CI/CD/etc.
• Rust has been a love affair of mine for the past few years, I even managed to get a small PR merged for the Rust compiler at one point.
• Scripting, all things Python/NodeJS/Bash/PowerShell/etc.
• Other languages like GoLang, C, Java, C#, etc.
• All things operating systems, Linux, Mac and yes, even Windows.
• Productivity in Software Engineering, so Vim, Terminals, etc..
• Open Source Software.
• Virtualisation.
• Mathematics and Science.

If there's anything of particular interest in the above I'd love to hear from you and find out more about what I should focus my attention. Please feel free to email me at the link in the footer or raise issues in this repository (here)[https://github.com/strottos/strottos.dev-public].

For those interested in the follow up post about technology choices, my experiences writing it, etc etc, read on here.