Well, the short answer would probably be that we don’t. However, in the era of LLM-slop (you know those uncanny articles that look vaguely helpful but somehow says nothing), it’s sometimes nice to get the perspective from an actual person. I hope I can provide interesting, useful – and occasionally funny – posts about the challenges I face and the solutions I find to solve them. This can hopefully help you with whatever you are struggling with, present you something worth considering or perhaps just give you a brief smile on your face as I wade through yet another ‘great’ (read: frustrating) experience with a Microsoft product wink wink.
Before you expect life-changing productivity tips
First of all I want to say that I don’t believe those even exist. The life-changing productivity tips that is. To truly become good at anything even being productive you just need to work hard at it – that might sound boring, but to me it’s very rewarding working towards something to eventually get to the place you want to be. Whether it’s a video game, an academic or physical accomplishments, learning new programming tools or something completely different, the reward for working at something just feels amazing.
And this blog will definitely not be your “10 productivity tips to boost your performance” kind of place. It’ll be messy, opinionated, and honest — the way programming tends to be. I might write a guide once in a while, but mostly to be able to reproduce something for myself in the future — in case I forget. But hey, if it can help you as well that’d also be a very nice bonus.
Anyway, enough about what this blog isn’t – let me tell you why I decided to start it.
So really, why?
I actually have several reasons for starting this blog. I’ve been thinking about it for a while, and what finally pushed me to do it was an event about a month ago – when I had to deal with managed certificates for Azure App Services. I already know what you are thinking: who in their right mind would work with Azure? Honestly, I have no idea - but that’s where life has taken me for now.
Anyway, one of my co-workers and I made a proof of concept in Bicep - some infrastructure as code that would automatically create a DNS record in a predefined DNS zone, and then request a Microsoft-managed certificate for that address. It actually went very smoothly. Everything seemed to work perfectly, I was able to get a certificate for each of our environments for the application we were testing with, and in case we manually removed the certificate in the portal, we could just run our IaC and it would be fixed.
Great, we thought. So I started rolling it out to all our applications on a Friday (I know - offensive to some people). And then suddenly, my pipeline failed with some obtuse error that I can’t quite remember, but it was something along the lines of
{
"code": "ResourceDeploymentFailure",
"details": [
{
"code": "BadRequest",
"message": "Pending managed certificate failed: Pending certificate expired. Please try again. Refer to the documentation for more info ..."
}
]
}However, the certificate resource just kept spinning in the Azure portal for hours before finally failing to be created there. Weird.
Meanwhile when trying to stop the deployment and create the certificate through the az CLI, we got an entirely
different error about the certificate already existing. Alright I thought, if there is a conflict I might be able to
fetch it or delete it through the CLI. Once again I was left disappointed with a ‘Not found’ error.
# Real parameters anonymized
az webapp config ssl create --hostname sub.webapp-host.com -n webapp-name -g webapp-resource-group
# Operation returned an invalid status 'Conflict'
az webapp config ssl show -g webapp-resource-group --certificate-name sub.webapp-host.com
# Operation returned an invalid status 'Not found'We spent hours trying to figure out if we’d hit some undocumented limit, or if there were outages at Azure or DigiCert - the entity that provides the certificates. Nothing. In desperation, we even asked an LLM for help - only to have it confidently hallucinate a completely imaginary limit of custom domain certificates for app services (we knew it was imaginary because we can count – and we’d already exceeded that limit).
Eventually, we gave up for the day. Luckily it wasn’t critical and could easily wait until Monday. Of course, I couldn’t wait. I ran the pipeline a few times Friday night, a few more on Saturday, and finally – on Sunday morning – I saw the green bliss of a pipeline that hadn’t failed. Our solution worked, the one we also thought worked a few days earlier. Our cloud provider and a chatbot had just successfully convinced us that we were the problem. That whole ordeal wasted a significant amount of time – and caused more than a little frustration.
The episode also made me realise I wanted (or maybe even needed) a place to vent, reflect and maybe laugh about it later – hence, this blog.
A professional procrastinator looking for purpose
A few weeks later, I finally had the time – and excuse – to get started. I had three weeks of vacation without anything particular planned. I figured it would be nice to work on a project instead of just endlessly procrastinating by scrolling Reddit, or watching an absurd number of videos on everything from how a dehumidifier works (in excruciating detail, I might add) to urban planning. Since I had just gone through that Azure experience, it was the perfect opportunity to get started on my blog.
I didn’t feel like just creating a generic Wordpress site – not that there is anything wrong with that, I’m just a control-freak. I wanted to build my own site from scratch and preferably learn something along the way.
I started looking into React and Next.js for my stack, mostly because I was vaguely familiar with those already.
But I quickly realised working with those JavaScript frameworks just isn’t fun. There are so many dependencies for even
the simplest things – and the recent supply-chain attack on npm didn’t exactly boost my confidence in that ecosystem.
So instead, I started looking for alternatives and soon stumbled upon Elixir and Phoenix. I’d heard really great things
about Elixir, and getting some more hands-on experience with a functional programming language seemed like a fun
challenge – especially since I’ve barely touched functional programming since coding in SML and Scheme back in university.
I started small – solving a few programming exercises to get my hands dirty while going through the Getting Started section of the Elixir hexdocs. The documentation is genuinely excellent, I rarely needed to look anything up elsewhere.
I wrote a few scripts, some modules to play with functions and structs, experimented with maps and collections and the Elixir concurrency model. Before long, I found myself remembering both the excitement and confusion of functional programming from back in the day – especially when diving back into recursion.
After a few days, I’d built up some familiarity with this (to me) new and exciting language, Elixir. I know it takes a long time to really get good at a new language, but in my opinion, there’s no better way to learn than by building something real.
So I decided to jump into the deep end and try my hand at the Phoenix Framework - a web framework for Elixir. The very first thing you’ll see when you go to their website is a bold tagline promising
Peace of mind from prototype to production
That’s exactly what I needed – a framework that is stable, opinionated, and fun to build with! A few weeks (and an undisclosed number of coffees) later, this blog was up and running.
I don’t want to go into too much technical detail in this post, since I might write another one about it, but I drew a lot of inspiration from this post by Sebastian Seilund from 2016. It really helped me kick-start my development and have a solid foundation to keep building on.
Of course, there were other technologies I had to brush up on as well. I really hadn’t touched HTML and CSS in any
meaningful way for years. I’d of course heard of Tailwind, but never actually used it to style anything properly. And
even though I said I don’t really enjoy working with the JavaScript ecosystem, I still ended up installing highlight.js
through npm in order to have nice looking code blocks in my blog posts – and some JavaScript will be required if I
ever want to work with the Phoenix JavaScript interoperability.
So, everything isn’t always quite so clean-cut.
Wrapping up (before I break something)
This site is my playground, and from time to time I’ll probably break it (by accident) – but that’s alright. It’ll just give me something to write about, and let’s be honest, development horror stories are always the most entertaining ones. On a serious note, I’ll do my best to post once every couple of weeks for a start, while also continuing to tinker with and improve the site along the way. I’m not exactly where this little project will go yet, but I’m excited to work on it nonetheless – and to bring you along for the ride.
My excursion into Elixir gave me quite a few ideas, and right now I am going through the book ‘Writing An Interpreter In Go’ by Thorsten Ball – except I am not writing it in Go, I am however having a go at implementing it using Elixir (sorry not sorry).
Please don’t hesitate to get in touch with me – either in case you want us to work together, or you have a suggestion for something you’d just love to see me dive into (or just want to say hi), I’d love to hear from you. You can find my contact information here.
So, do we really need another programming blog? Probably not. But this one exists – and that’s good enough for me.