Five years ago, I needed to get out of my old job quick when they called everyone back to the office and I lived two hours of one-way commuting away. Just then, I received a job offer from a former colleague to join the dark side of consulting - an offer that I would not have even considered a week before or after. But at the time, it was a quick way out of what I had assumed would be a slow and cumbersome job search, so I took the offer with only a little bit of negotiation.

I figured I could probably survive a year and start applying for real jobs in the meantime, and now I still sit here, honestly having a very good time with the job that I barely took serious at first glance. Anytime I do a full turn on an opinion like this, I feel it is worth taking a deeper dive into the why, and how my own previous bias shaped my impressions, almost preventing me from a good thing.

For the first ten years of my career, I barely got in touch with consultants (or freelancers for that matter), and the ones that I ended up working alongside were honestly shitty people with low ethics, low skills and a lot of arrogance. I thought so back then and I think so even more today, now that I work for a company where by and large, people are professional and experts at the things they do. These people I met over the years would not stand a chance making it to the first performance review, much less through it.

I write more code rather than less

My original biggest fear was that I would end up becoming a talking head, even though I specifically applied for an implementation role. I was just so used to consultants coming in to tell me how to do my job that I was already doing, never once writing a line of code themselves, then swooping back out to add another company to their growing resume of expertise.

As it turns out, the opposite has become true, and I write more code rather than less. It turns out that as soon as I had a price on my head, and this price was visible and in people’s minds, they suddenly developed a strange disliking of having me sit in useless meetings, or otherwise wasting my time.

It almost seems like everyone around me suddenly has a vested interest in keeping me happy. The clients would much rather have me writing code than sit in an hour-long meeting that could have been an email. My own boss back home would rather have me working more billable hours, so I barely ever get to sit in useless internal meetings, either.

It is almost maddening to see that I am now part of multiple companies at once, and still have a fraction of the meetings that I had in my old jobs. If it’s clearly possible, then why wasn’t it possible before? I must have sat years of my life in meetings at this point, and an easy half of them were useless enough to have me working through them.

Even before factoring in the expected overtime hours, I get to write a lot more code than before (or do other related activities like architectural planning and design work). I usually have to sit through one or two daily standups depending on the project load, but those are generally short enough to count as actual standups. A lot less “how was your weekend” type chatter, too, which honestly counts as a job benefit at this point in my life. The people I care about can tell me what they did on the weekend without needing a standup for that.

On any given day, I have at least six hours of software development time, with two hours reserved for project overhead, doing my time sheets, and talking to people. That seems like a good level to be at, especially since I usually have most of my afternoons as uninterrupted coding time. Everyone seems to love bunching up meetings in the morning, so there is sometimes a day or two where I don’t get much work in, but generally speaking, I have enough time to do what my job description says I do.

I have a lot more agency over the work that I do (and the hours that I work)

Now, we get to the overtime hours that are sort of expected in our world, and probably the main split between people who have a good time or a bad time at work is how we handle this.

From where I stand, having easy access to overtime hours is a job benefit that allows me to make a lot more money than I did in my old jobs, thanks to a combination of a general pay raise and the fact that I can decide if I want to work more hours or not on any given day.

From where someone else stands, they might struggle to make it to their regular eight hours, and every hour on top of that becomes crunch work, painful and slow, not productive, with a boss breathing down their necks to ask what they did in that time.

Obviously, this is all highly dependent on individual circumstances, but for me, it simply works out. The way I do it, this is how my days look:

I get up early, make breakfast, and sit at my desk watching the world wake up while I do light work like generating reports, fixing server issues from nightly batch runs, or writing scripts that combine dozens of xml files to get a version that has all possible combinations - things like that.
From eight to around nine is an hour of meetings, standups, and figuring out the day’s priorities
Nine to twelve, I work down the day’s priorities
Lunch, I make food and do some work around the house, my goal is to do at least one useful thing per lunch break. Cleaning, garden work, repairing something that’s broken. This works extremely well for getting my mind off of work and refreshing my spirits.
From one to around five, I keep working regular tasks that are part of my main work. Project work, implementing features, fixing issues, explaining something if someone asks. These are usually my most productive hours.
After work, I take at least one hour of break time to make dinner, do things around the house, or go cycling, shopping, whatever I feel like that day. Even just sitting outside in the sun counts as productive use of time here, because it’s meant mainly as a way to move my brain over from work to playtime.
Now, I get back to work, usually some kind of side project that my boss likes paying for, because the clients like paying for it, and my work could potentially be sold to multiple clients over the years. Or I just switch from working on project one to project two, which feels the same kind of fun.

I know this highly depends on personal priorities, but for me it really works out well. I do some work in the evening that I would otherwise spend working on some private coding project, and I usually work a handful of hours spread across both weekend days as well.

The way I structured my life, this workload does not impact my private life much, I still get out and live my life - probably more than most, even. I am out and about almost daily, I take trips on weekends, I lead a somewhat active social life. It’s just that having like sixteen hours per day is a lot of time, and I don’t mind bouncing between cleaning rust from garden sheers with a grinding wheel to making lunch, to going inside on a hot summer day to flee the heat and writing some code.

The way it all works out, I make almost double what I made in my old job, and I am honestly a lot more relaxed than I was there, because I was spending half my day trying to find little pockets of programming time between the meetings.

We can iterate not just on the code, but also on project landscape and infrastructure

One thing that I like about the whole way of basically building the same thing over and over again for different companies is that our projects evolve, and the main issues that one project has are usually not present in the next one we work on.

We even sometimes go back and implement better solutions in old projects, assuming the client wants to pay for it. Every new project, we sit around for a week with a bunch of people doing architectural design workshops, and this is really intense work with all of us physically in a room with a whiteboard and making sure we don’t repeat yesterday’s mistakes.

For me, this is highly rewarding, because personal, individual code contributions can only get so good before they start hitting walls, or at least diminishing returns. But a single developer can do their best work ever and the project could still fail if it’s set up to fail, or things that nobody expected happen too late into the development cycle to fix.

With this way of repeating the same thing, we can iterate over the whole project in a way that I don’t think many regular companies can, and that is quite rewarding. We can also afford the time that it takes to build testing frameworks, extract working components, streamline workflows, because it will save us time and make us more competitive pricing wise on the next project.

Interestingly, I am a lot less “ashamed” of my work from five years ago than I am of the code that I wrote six years ago, or ten. Not even because I became a better developer in that time, but also because most of it has seen multiple iterations in just five years than any of my previous work has. I happen to know from a former coworker that there is actually code still in production that I wrote thirteen years ago, and I doubt I would write a single line of that system the same way today.

Specializing allows me to generalize better

For most of my career, I used to think that specializing was inferior to generalizing, simply because my life at work was like that. I did work on servers, I wrote program code, I worked on websites, I fixed issues in repos from other teams that had some impact on my own system. I did performance testing for database scripts or lines of code, and once I had to use a spreadsheet with a working SQL connection and VBA to reverse engineer and get data out of a production database that nobody had the password for.

I did a little bit of everything, and I never really had the time to get really good at one single thing. In fact, I saw little reason to even do that, because I succeeded at work by doing simple fixes and only taking deep dives when needed. And honestly, most things that break are only one or two layers deep and within reach of a motivated person with the knowledge of a million software developers sharing their knowledge online.

However, these days, I think quite differently. I still do a little bit of everything, but it really helps to have one thing that we are good at, then better at than most, then eventually so experienced that we build systems that actually work without major outages. I have more than five years of experience in the main things I work on as I came into contact with them over the years, but even just five years spent on one thing is a lot of time to get good at it. Knowing what functions exist, knowing where the limitations and opportunities lie, how to work with or around them, and how to connect one system to others. Especially the work spent designing middleware makes the sky the limit when it comes to custom requirements any client might have.

I also see how much further ahead our junior developers are to how I was at their age, or others I came up with. Specializing allows much quicker success in our personal journeys as developers - assuming we specialize on the right thing, of course. It also makes me breathe easily in times of LLMs, they make me faster without really endangering even our junior developers as the main work we do is not impacted by it.

I am part of multiple families, and none of the family drama reaches me

An unexpected side effect of the whole project work lifestyle has been how I shed virtually all company drama overnight. I am not really part of any of the companies I work for, and not really part of my own one, either. I spend so much time working for clients that I am only really at the company headquarters for the two parties per year and my performance review, and sometimes at one of the offices around the country when we do our architecture workshops.

In the same way, I am almost never physically on location with the clients because they would rather have me working than paying for my travel time and hotel stay. That means I usually travel there for project kickoffs and when we press the big red button that pushes everything to production, at which point I usually spend up to two weeks on site. Sometimes, they invite us over around Christmas for some team building, and other times, we get send out to do workshops and trainings.

All in all, I usually travel a few days every month, but even that can be two weeks one months and nothing the next.

What that leads to is that none of the regular office drama reaches me. I don’t have to pick sides, my loyalty is never in question because my loyalty is to money, and also because I am never there when things reach their boiling point. Very tough to even get into the line of fire of any kind of drama, and people can easily forget that I even exist when they go around looking for enemies.

Working in established systems leaves more room for actually creative software development

One of my biggest worries was that the whole thing of implementing standardized systems into existing landscapes would either get boring quick, or mind-numbing slowly.

To my own biggest surprise, the complete opposite has proven to be true, and I spent a whole lot more time building customized solutions, workarounds, middleware, both inside and outside the actual system. Every week, I bounce between server workflows, APIs, write code in multiple languages, and experiment with edge cases to see if we can implement them inside the system or need an outside solution. It gives me far more room for creative solutions and “actual software development” than I feared - and in fact, probably more than my old jobs ever did.

At this point in my career, I actually value this part of “it keeps my brain occupied” as much as the money I’m making, and it is the main foundation for me to even want to work overtime hours. I am also at the point where I don’t need to work overtime hours to survive, but thanks to all that homeoffice work, I save so much time on commuting and other bullshit overhead that I end up with spare time I can’t always fill. My house is cleaned, I get my daily dose of sports, the garden is growing, all in the time that I used to spend just getting to work, the suddenly usable lunch break hour, and the time not spent getting back from work. And then, my usual spare time from before starts.

This easy access to overtime hours is actually another hidden job benefit, I simply couldn’t get to another side job as quickly as I can take a quick break, refresh my mind, and then start working on an internal side project. This mental switch from one topic to another is very nice and makes the extra hours feel like playtime more than work, especially because I don’t get any calls in the evening. I could also be sitting on the couch working on my own side projects, but instead I get paid to do basically the same kind of relaxed experimentation and building.

Software development was never a forty-hours job anyway

I have long said that there is a case to be made for working either thirty or fifty hours, but forty hours of software development are hard, bordering on impossible. There is just not enough static work to fill the same number of hours every single day, and there is often no way to just drop what I’m doing because the clock has reached a certain point.

Other days are super slow, down to just writing a single line of code or a single query against the database, and there is just this pocket of unexpected spare time that can’t really be filled, right before things get hectic again and ten hours aren’t enough to get everything done.

Getting paid by the hour, mixed with the flexibility of multiple projects and potentially the agency of working overtime and weekend hours gives me a lot of personal flexibility that I never had before, including being artificially constrained by automated “employee health monitoring” in one company that required us to never work more than ten hours per day, and if you worked more than eight, you had to fill out forms explaining why.

Especially in our times, there is so much variance in tasks, some are just a good LLM query away from completion, others that seemed simple take up the whole rest of the day. I quite like that I can bill the hours that I actually worked, and when there is a slow day, I can always switch over to another project and don’t even have to ask anyone, just pick a task on JIRA and get to work.

Other companies I worked at simply didn’t have this kind of flexibility, because you can’t just switch to another project if you are only assigned to one project. It also doesn’t lead to any thanks if you do more than the work assigned to you, at best your coworkers give you the stink eye, at worst your boss tells you that because you clearly don’t have enough to do, you are now expected to work on both projects at all times.

Getting paid by the hour surprisingly takes a pen and crosses through a lot of bullshit in this regard (and others), and I feel a lot less pressure on me every day now that I always have a list clearly explaining what I worked on. It’s downright impossible to accuse me of laziness, and just as impossible to find excuses in the performance review for why I shouldn’t get a raise this year.

I write about code

Surprisingly, getting paid by the hour makes software development better, not worse