I recently gave up a perfectly good career as a software developer, and instead I plan to write blog posts and shoot YouTube videos for a living. I figure that it’s worth writing down why I have made this decision – if only for myself.
I don’t fully know what I’m going to write here (I haven’t pre-planned anything)… but here goes nothing.
As a bit of background about me, I did a maths and computer science degree in University, and then for the last decade I have been working ‘professionally’ as a software developer – mainly on backend systems, but I’ve done a fair bit of frontend development and devops too.
But that doesn’t tell the full story. I actually built my first website when I was 10 or 11 years old, initially using Microsoft FrontPage and then teaching myself HTML, CSS, JavaScript and PHP.
I love programming. I love starting with nothing, and creating something. Over the past two decades I have gained quite a lot of software dev experience: be it with React, Java, PHP, Python, Linux or Ansible/DevOps.
So why did I just give up my (stable|well-paid) career as a software developer/engineer, to instead be a (b|v)logger?
I guess there’s three main parts to my decision (sorry that the list below starts from 1 – you can tell that I’ve given up programming already!):
- I feel burnt out from programming.
- I have always wanted to work for myself, and my digital media business will allow me to do that.
- Since becoming a parent, being able to choose my own working hours has become more important than ever to me.
Let’s explain all three. The latter two points will be easy enough, but the first may be trickier so let’s start there.
Reason #1: Programming Burn-Out
It’s not the case that I suddenly hate programming (because I still love it), or that my last few programming jobs have been rubbish (because they’ve been great).
The WHO define burn-out as an occupational phenomenon, and not a medical condition, by saying:
Burn-out is… characterized by three dimensions:
1. feelings of energy depletion or exhaustion
WHO, 28 May 2019
2. increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job
3. reduced professional efficacy.
And that’s fairly applicable to me. Whilst my recent jobs have been good, and I’ve worked on some really interesting projects, I no longer feel motivated or satisfied by programming.
Whilst the pandemic has led to a rise in work burnout and a ‘great resignation’ wave, I don’t think that this is why I feel burnt out. For me, I think that the main reason is that the programming community sometimes make simple things very difficult, for no good reason.
I’ll explain what I mean with two examples: building a simple webpage, and also moving from monoliths to microservices.
How To Build A Three Page Static Site
I saw a question on Reddit a year or two ago, where someone said that they wanted to build a simple three page website, and they were asking for the best technology to use.
This confused me, because there’s only a single choice: HTML. Right? Well, the thread was full of unironic replies suggesting Gatsby and React, or Next.js.
Before I continue, I should be clear that there’s nothing wrong with using new technologies to learn new skills. That’s naturally a great thing. It’s also good for new technologies and developments to pop up (both within programming, and generally). Human innovation is necessary, and a great thing.
But in this case, the requirement was for a standard, simple, website. There’s no catch. The user didn’t want to build a fancy SPA which generated static files as part of the workflow. They just wanted a simple website.
Something like Gatsby is completely overkill. Just start by creating three HTML files:
/index.html/about-us.html/portfolio.html
You want images? Great, add them to an images folder and then include them in the usual way (<img src="...">) within the HTML. You’ll then have:
/index.html/about-us.html/portfolio.html/images/image-1.jpgimage-2.jpg
You’re bored of the white background and white text? Great, add some CSS and include it in the usual way (<link rel="stylesheet" href="styles.css">). Now we have:
/index.html/about-us.html/portfolio.html/styles.css/images/image-1.jpgimage-2.jpg
Wait, you want some basic dynamic stuff? Cool, let’s add a Javascript file and include that in each page too (<script src="/dynamic.js">). Great, we’re done and our file structure is:
/index.html/about-us.html/portfolio.html/styles.css/dynamic.js/images/image-1.jpgimage-2.jpg
Simple.
Okay okay, I know that the reality is often more complicated, but this is all that the original poster on Reddit really wanted/needed. They’d still be crying into their terminal about npm issues if they went down the Gatsby route.
Well, maybe that’s not true. But what is true is that an entire Gatsby and React project would be massively overkill to begin with.
Having said all that, if the website starts growing in size, having individual HTML files will quickly become unmanageable. Jekyll, Hugo or Gatsby (ironically) would all help here.
Equally, if the website gets large, a single CSS file would be unweildly. Using something like Sass would help here.
And if the dynamic stuff ever got too complicated for a single Javascript file, using Vue.js or React (or simple, vanilla Javascript organised over multiple files) would help.
But the key thing is that (IMO) it’s much better to start with something simple, and only use more complicated technologies if you need them. Don’t commit to a massively difficult tech stack when all you need is to build a two page website for your mum’s sewing club. (Unless you want to learn new skills for your portfolio, that is).
How To Move From Monoliths To Microservices
When I first came across microservices, I had been working on a fairly bloated Java monolith for two years – and so I naturally loved the idea of microservices.
- “Split things down into small, simple parts” – yep, that makes sense.
- “Have one data source per microservice” – tick, that’s much better than having a single bloated database.
- “Use the right programming language for the job” – awesome, we can use Python or R for the data analysis microservice, Node.js for the lightweight middleware service, and PHP for a laugh. (Sorry, just kidding, I actually think that PHP is fairly decent).
- “Easily move things into the cloud for horizontal and vertical scaling” – woohoo, being able to auto-scale each service based on load makes perfect sense.
Right, I’m sold. I actually wrote a Spring Cloud demo on Github that got mentioned on Spring’s blog a couple of times.
I was fully invested in microservices. “Was” being the operative word. I’ve worked with three microservice-heavy companies since then, and done more reading on them too, and I now think that microservices should be avoided in many cases. Why? Well, Stack Overflow’s blog discusses this better than I could, but some things I’ve observed from microservice-heavy architectures are:
Microservices Won’t Fix Bad Codebases
It’s often the case that companies have a badly coded monolith, full of legacy spaghetti code. They therefore decide to move to The Promised Land™ of microservices.
“It’ll be so much better this time”, the developers said.
But fast forward 5 years, and all the company has is badly coded microservices.
What went wrong? Well, I’ve come to the conclusion over my career that terrible codebases are terrible due to organisational issues, not because of the monolith architecture.
A well run company, with good software development processes, will generally have good (or good enough) codebases – whether they are split into microservices or grouped as a monolith.
Microservices won’t fix bad companies. They’ll actually make things worse.
“1 Data Store Per Microservice” Isn’t Good
The idea that each microservice should have their own data source is good, but often it leads to each team choosing a different database.
MariaDB, Postgres, MongoDB, Neo4J, DynamoDB, Cassandra and Redis are all great data stores (well, apart from Cassandra, which is awful). But the worry with adopting microservices is that each team will decide that they need to use a particular type of data store – usually based on their own individual experience with each.
This can then lead to the case where a company has 15 microservices and 7 different data stores – with all the extra infrastructure and cognitive load that comes from that.
Yes, this shouldn’t happen in a well-run company, but I’ve seen (and heard about) it happening enough times to know that it is a real risk of microservices.
“Cloud Scale” Is Often Not Needed
Many dev teams start a new greenfield project, and immediately decide that it’ll be a major success and hence it’ll need to be built in such a way that it can be scaled in the cloud with ease.
Enter microservices.
It’s naturally a good thing to assume that a new project will be successful – and often the business side of a company will be the ones bigging up the project, leading the devs to assume that it’ll encounter massive level of traffic really quickly.
But it’s easy to get carried away with this, and build an overly complex set of microservices to meet future traffic demands that never quite materialize.
I’m not saying that we should build terribly written POCs that are impossible to ever scale, of course. But we also shouldn’t get carried away and take much longer to build an overly complex microservice architecture, until we know that we specifically need microservices.
Significantly More Complex
Microservices don’t have to be complex. It could be as simple as having three services, deployed as-is (without containerisation), storing data in a single Postgres DB (but with a separate database schema per microservice):
That is a perfectly valid microservice architecture. Each microservice could ensure that they follow the Twelve Factors and be deployed onto a baremetal server, along with the Postgres service. Then if they need to scale in the future, this would be easy because each service is already designed for this.
But I’ve never seen that happen.
Instead, each codebase usually has a series of build scripts which containerises them and publishes helm charts. There’s then a bunch of build infrastructure tools: Jenkins, Docker registries, Artifactory, K8s dashboards, Ansible, AWS set-ups per environment, the ELK stack, Terraform, continuous integration and load test suites, and more.
The end result is Netflix-scale, huzzah! This can be great and necessary – especially when a company truly needs a microservice architecture, and truly needs to meet high demand. (Side note: My previous company was a FinTech company that did actually benefit from all this – downtimes and costs-per-trades are expected to decrease a fair bit over the next few years, due to their cloud/microservice approach.)
But in many other cases, this isn’t the case. All the extra cloud bloat is usually not required and will just slow everything down:
- Development will be slower, because there’s loads more steps to follow, and technologies to be mindful of.
- SRE/DevOps now need to maintain significantly more things, which will also delay any new infrastructure roll-outs because there’s more things that could be impacted.
- The actual hosted software might actually be slower too. Whilst cloud can of course be quicker, running a simple service on a baremetal service will naturally be faster than wrapping it in layers of containerisation, which are then hidden behind 2-5 other cloud services (reverse proxies, ALBs, NLBs, WAFs etc).
Working with microservices (something I originally loved the idea of, I hasten to add) increasingly feels like using a sledgehammer to open a banana, to be honest!
So… yeah. That’s pretty much why I feel a little burnt-out from programming, I think. Now onto the other reasons why I decided to give up my software dev career.
Reason #2: Being My Own Boss
I have wanted to have a business and ‘be my own boss’ since I was a teenager. I’m not sure why this was the case, but it’s just always something I have wanted to try. There’s nothing wrong with working for other people, but the idea of being in the driving seat has always appealed to me.
The main difficulty I’ve had in making this move (i.e. from being an employee, to being my own boss) is that I’m fairly risk averse financially, so I have never wanted to just pack on my ‘day job’ without some financial safety net.
However my digital media business is doing fairly well, and our personal expenses shouldn’t increase anymore from now on (we have two children, and aren’t planning any more!), so it feels like the right time to make the leap from being an employee to being my own boss.
#winning
(I hope)
Reason #3: Working My Own Hours
This one is probably fairly self explanatory: being able to pick and choose my own working hours is awesome. Whilst working 40 hours a week wasn’t too bad for my wife and I a few years ago, we now have two children and being able to pick and choose my own hours has become much more important to me.
For example, over the past year or so, my wife and I have found that our mornings are completely manic, and then our afternoons are quieter (since our children nap then). Equally, we are both freed up after 7:30pm when our children go to bed for the night.
So being my own boss and being able to choose my own hours means that my ‘schedule’ can be:
- Monday-Sunday: whatever day(s) work best. I’ll aim for Monday-Friday in general, but sometimes one of my children might have a bad day, so I might not be able to work much (or at all then). In that case, I might choose to work a bit on the weekends instead.
- Mornings: meh. Maybe I’ll work a little bit, maybe not.
- Afternoons: I’ll aim for 2-3 hours.
- Evenings: will work some evenings.
In general, I doubt that I’ll work much more than 15-20 hours per week to begin with. But the key here is that this will be focussed work.
There’s various sources (from Inc, Medium and others) showing that the average office worker is only productive for 3-4 hours a day, so I’m hopeful that working for 15-20 hours per week will still yield good results.
Which leads me onto actually talking about what my new business is in practise!
My Digital Media Business & Future Plans
When I say “Digital media business”, it sounds a little pretentious to me at times. But I find that it’s the most descriptive term… I’ve never been a fan of the term “content creator”, for some reason.
I currently have three WordPress-powered blogs, and then a YouTube channel.
One of the blogs is Smart Home Point, and this is the one with a YouTube channel.
However I plan on launching 1-2 new blogs over the next year, and I’ll also ensure that I launch YouTube channels for all my blogs (so I should end up with 4-5 blogs and 4-5 YouTube channels).
In some ways, this is a perfect business for me:
- I have been building websites since I was 10 or 11.
- I am fairly good at explaining things to people (or at least, I like to think this is the case!).
- I enjoy helping people (and good quality content can definitely do that).
- This is something that I have been able to build up on the side of my day job (usually before work, but sometimes in the evenings too). I would have struggled to build a programming business on the side, after programming all day. But blogging before/after work? Yep, I have found that easy enough.
So that’s pretty much it for now.
I sort of feel like I’m “coming home”, as weird as that sounds. I don’t know what drove me to build websites when I was a pre-teen, but it’s always been a passion of mine. And since I’m a bit burnt out by programming, building websites (and YouTube channels) definitely appeals to me.
I still plan on programming at some point (be it programming smart home tutorials, or a separate SaaS business), but for now I’m mainly going to be a “content creator”..!