Personal

I'm the Worst at Creative Writing

#Open Source#Sentrello#Career#Writing
James Conway7 min read

TL;DR: First post. Twenty-eight years in IT, a layoff in May, and a self-hosted business platform I've been building quietly for three and a half years. I'm going to start writing about all of it — technology, infrastructure, open source, and Sentrello.

See Sentrello on GitHub

I have spent more than 28 years working in Information Technology, and somehow I have managed to avoid writing a blog for almost all of them.

That takes some commitment.

I’ve written technical documentation. I’ve written project plans. I’ve written architecture diagrams that somehow require three other diagrams to explain the first diagram. I’ve written thousands upon thousands of lines of code, along with the obligatory comments explaining why some particularly questionable piece of code exists.

Creative writing, though?

Nope.

That has never really been my thing.

My writing style has historically been less “engaging personal narrative” and more “documentation you accidentally opened at 11:47 p.m. while trying to figure out why the server is angry.”

If insomnia is ever a problem, I may have a solution for you.

So Why Start a Blog Now?

Twenty-eight years of silence

That’s the part I’ve been asking myself.

For most of my career, I didn’t really have a reason to write publicly. My work happened behind the scenes, usually inside companies and client environments where the interesting stuff wasn’t exactly something I could publish on the internet.

I started working in the private sector in 1998 as an independent contractor. I was still a junior in high school at the time, which sounds ridiculous now. It probably sounded ridiculous then, too.

My first traditional job came in 2003.

Since then, I’ve worked across an unusually broad slice of IT. Software development. Systems administration. Infrastructure. Cloud. DevOps. Security. Automation. Architecture. Business systems. Somewhere along the way, I also discovered that apparently I enjoy fixing complicated things that other people have already declared “too complicated to fix.”

That turned into running my own IT consulting company for nearly a decade before I spent the next ten-plus years working at XTIVIA. My career has involved everything from building applications and automating infrastructure to managing enterprise environments spanning multiple cloud platforms, implementing security programs, and trying to convince people that spending money on something now can sometimes prevent spending considerably more money on it later. (The short version is on my résumé.)

Basically, I’ve spent most of my adult life making computers do things they didn’t want to do.

And I got pretty good at it.

My portfolio probably does a better job explaining the technical side of that career than I ever could here. I’ve put together case studies covering projects involving multi-cloud infrastructure, monitoring and observability, identity governance, security, automation, and enterprise systems. One recent identity governance project, for example, involved three cloud platforms and more than twenty enterprise applications, while recovering more than $30,000 a year in licensing costs. Another involved replacing basic uptime monitoring with actual infrastructure observability across AWS, Azure, and Google Cloud. (That identity governance project is written up here.)

Those are the kinds of things I’ve always been comfortable talking about.

Writing about myself?

Much harder.

Then May Happened

The part I didn't plan

After more than ten years with my last employer, I was laid off in May.

It wasn’t exactly how I had planned to end that chapter.

The company had struggled to recover after COVID, and years of poor executive decisions had finally caught up with the business. Eventually, the writing was on the wall.

Unfortunately, nobody had written it in a language I could automate.

Being laid off after that much time in one place gives you plenty to think about.

For the first time in a long time, I had to stop and ask a fairly simple question:

What do I actually want to do next?

The obvious answer would have been to update my résumé, start applying for jobs, and spend the next several months explaining to recruiters that, yes, I really do know what Kubernetes is, and no, I don’t need a six-month certification course to prove it.

I decided not to do that.

Instead, I decided to do something considerably more interesting.

A Different Kind of Career Move

Out from behind the firewall

I’m moving into open source.

That’s a bigger change than it probably sounds.

Almost my entire professional career has been spent working on enterprise-level private projects, proprietary systems, client environments, and infrastructure that was never intended to be publicly visible.

The code lived behind company firewalls.

The documentation lived in SharePoint.

The systems lived in data centers and cloud accounts that belonged to somebody else.

And then, for the last few years, I’ve been quietly building something of my own.

For roughly three and a half years, I’ve been working on a project in my spare time that started as an idea and gradually became much, much larger than I originally intended.

That project is called Sentrello.

Sentrello is a self-hosted Unified Business Management Platform, or UBM. The basic idea is pretty simple: instead of forcing a business to stitch together a collection of unrelated SaaS products, Sentrello puts core business functions into one platform that the business can run and own itself.

CRM.

Quotes and invoicing.

Accounting.

Forms.

And eventually a growing collection of additional business applications that can work together instead of existing as isolated islands.

The Free tier is open source under AGPLv3, runs on the business’s own infrastructure, and doesn’t charge per user. The repository is public, the application is self-hosted, and the database belongs to the business running it. (The Sentrello repository is on GitHub.)

There is something strangely satisfying about that.

After spending decades building systems for other people, I finally built one that I get to put my name on.

And Now I Have to Talk About It

Why the blog exists

This is where the blog comes in.

I’ve reached the point where keeping everything in my head doesn’t make much sense anymore.

There are things I’ve learned over nearly three decades in IT that might be useful to somebody else. There are mistakes I’ve made that somebody could probably avoid. There are projects I’ve worked on that are worth explaining. There are opinions I’ve developed after watching the technology industry repeatedly invent the same problem in a slightly different shade of blue.

And then there’s Sentrello.

I’ve spent the last three and a half years building it quietly.

Now I’m going to start talking about it publicly.

That part is new.

Very new.

I’m much more comfortable sitting at a terminal at two in the morning debugging some obscure infrastructure problem than I am sitting down and trying to explain what I was thinking when I built something.

But apparently that’s what blogs are for.

So here we are.

I’ll probably write about technology, infrastructure, open source, software development, business systems, security, automation, AI, and whatever else catches my attention. Some posts will be technical. Some won’t.

Some may even contain opinions.

You’ve been warned.

One More Thing

No promises about the prose

I’m not suddenly going to pretend I’m a professional writer.

I’m still the guy who thinks a well-written README counts as literature.

But this is a new chapter for me.

For the first time in my career, I’m building something publicly, sharing the work publicly, and opening the door for other people to see what happens behind the scenes.

That’s a little uncomfortable.

It’s also pretty exciting.

And if the writing is terrible?

Well, at least the code should be reasonably well documented.

Probably.

We’ll see.

Welcome to the next chapter.

// Let's talk

You have ideas.
I have IT solutions.

Fifteen minutes on Zoom is usually enough to tell whether I'm the right person for what you're building.

Denver, CO · Available for architecture, infrastructure, and DevOps engagements