Building Software When You’re Not a Full-Time “Tech Influencer”

Building Software When You’re Not a Full-Time “Tech Influencer”

I write software for a living now, but that is a relatively new chapter in my life. For nearly two decades, most of my work involved roofing, framing, construction, and the kind of jobs where you come home physically tired instead of mentally tired. I learned a lot doing that work, and I still have a tremendous amount of respect for the people who make a living with their hands. There is something satisfying about standing back at the end of the day and being able to physically see what you built.

At some point, though, I realized I wanted something different for myself.

It wasn’t that I suddenly thought I was above construction or that there was anything wrong with the work. I just started looking farther down the road. I wanted more room to grow, more opportunities to learn, and a career that could continue opening doors instead of slowly becoming harder on my body. I wanted to prove to myself that I could make that change, even though I was entering technology much later than a lot of people around me.

That decision eventually led me into software development.

In a strange way, I don’t think I ever really stopped building things. The materials just changed.

There are parts of construction and software development that feel surprisingly similar. You start with an idea or a set of requirements, figure out what you have to work with, and begin putting pieces together. Sometimes everything fits the way you expected. Sometimes you get halfway through and realize the plan was wrong from the beginning.

The difference is that tearing down a bad afternoon of code is considerably easier than tearing down a wall you framed incorrectly.

Getting into technology also changed the way I looked at learning. When I first started, there was an enormous amount I didn’t know. There still is. Software is one of those fields where learning enough to understand the size of the field mostly teaches you how much more there is left to learn.

Early on, that could be intimidating. Now, I actually enjoy it.

I have become comfortable saying, “I don’t know how to do that yet.” That last word makes a difference. If I don’t know something, I can read documentation, experiment, ask another developer, build a small test, use AI, break something, fix it, and eventually understand it better than I did when I started.

That process is probably one of the reasons software has held my attention.

I’m a Developer, Not a Professional Developer Personality

There is a strange thing about the way software development is presented online. If you spend enough time around tech content, it can start to feel like every developer is supposed to be building a SaaS company, recording tutorials, posting daily coding tips, maintaining six open-source projects, and explaining how they became a senior engineer at 23.

There is nothing wrong with any of that. I have learned a tremendous amount from people who dedicate their time to teaching and creating technical content. Some of them are exceptionally good at it.

It just isn’t my life.

I work full time as a software developer. Outside of that, I have a family and other responsibilities. I still have some military obligations, occasionally find myself doing wildland fire work, continue learning, work on my own projects, and every once in a while manage to sit down and play a game.

That means Goose Solutions isn't being built by someone whose entire day revolves around producing content about software. Most of the time, if I’m working on it, I’m doing it because I had an idea I wanted to see become real.

That is where the tagline “Creating the Tools We Couldn't Find” comes from.

A lot of my ideas begin with me looking for something and wondering why the available options are more complicated than they need to be. Maybe the tool is full of ads. Maybe everything useful is locked behind an account. Maybe somebody wants a subscription for something I need to use twice a year. Sometimes I simply don't like how the existing solutions work.

Eventually I start wondering whether I could make a better version myself.

That question has a habit of becoming a project.

Changing careers wasn't something that happened because I stumbled into the right opportunity one afternoon. I had to make a deliberate decision that I wanted more for myself and then start closing the gap between where I was and where I wanted to be.

I was competing with people who had been interested in programming since they were kids. Some had computer science backgrounds. Some had already been writing code professionally for years. Meanwhile, I had spent much of my adult life doing work that had almost nothing to do with software.

There wasn't any shortcut around that difference. I had to learn.

That experience still affects how I approach development now. I don't expect myself to immediately understand every technology I touch, but I do expect myself to be capable of learning it. There is a big difference between those two expectations.

Software rewards curiosity in a way I really enjoy. You can start with a tiny question and suddenly find yourself learning about networking, authentication, databases, APIs, cloud infrastructure, deployment pipelines, or something else you hadn't planned on touching when you started.

That happens to me constantly.

A project that begins as “I want a simple tool that does this” can turn into weeks of learning things I didn't even know I needed to learn.

Becoming a developer hasn't made software less impressive to me. If anything, understanding a little more about how it works has made some software even more impressive.

Games are probably the easiest example.

I enjoy games like The Elder Scrolls V: Skyrim and Mount & Blade II: Bannerlord, and I have a tremendous amount of respect for the people who build worlds at that scale. When you start thinking about how many different systems are running together and doing complex tasks like rendering, physics, animation, AI, audio, quests, inventories, combat, weather, networking, and everything else—it becomes difficult not to appreciate the engineering behind it.

What Hello Games has done with No Man's Sky is especially fascinating to me. The scope of the game is impressive enough, but watching what that team continued to build and improve over the years is something I respect tremendously.

Then there are developers working on games from studios like Rockstar. I can play something like Red Dead Redemption 2 and understand enough about software to know that I barely understand how something that complicated actually gets built.

Those developers might as well be wizards.

I like having people and projects like that to look up to. I don't think getting better at something requires reaching the point where nothing impresses you anymore. There should always be something out there that makes you wonder, “How did they do that?”

That question is useful.

Professional software development and personal software development are very different experiences.

Professional software comes with constraints. There are users, existing systems, security requirements, standards, deadlines, architecture decisions, business requirements, and code written by people who may have left the building years ago. You don't get to rebuild everything because you woke up one morning and decided you don't like it anymore.

That environment teaches discipline.

Personal projects give me freedom.

If I build something for Goose Solutions and decide the architecture is terrible, I can tear it apart. If I want to try a technology I've never used before, I can. If I spend an evening experimenting with something and discover it was a bad idea, the experiment still taught me something.

That is one of the biggest reasons I keep building things outside of work.

It isn't about padding a résumé. I already write software professionally.

It is about becoming better at something I chose to make my career.

I have never been particularly excited about building something solely because it makes a good portfolio project. Tutorial projects absolutely have value, and everybody has to start somewhere, but the projects that hold my attention are usually the ones that solve an actual problem for me.

There is a different level of motivation when you want the finished product to exist.

When something annoys you enough to build your own solution, suddenly the little details matter. You care whether the interface feels right. You start thinking about what happens when somebody uses it differently than you expected. You discover that the simple feature you imagined requires four other features you hadn't considered.

Then you deploy it and discover an entirely new category of problems.

Something that worked flawlessly on your computer suddenly behaves differently in production. Authentication breaks. Configuration is wrong. Mobile doesn't look like desktop. An environment variable is missing. A database connection fails. A deployment pipeline decides that today is the day it stops cooperating.

None of that is particularly fun at the moment it happens, but it is an important part of becoming a better developer.

Writing code is one thing.

Finishing software is another.

I want Goose Solutions to be a place where I do more of the second.

Of course, I don't want every hour of my life to turn into another development project either.

Sometimes I still want to fire up Bannerlord, wander through Skyrim again, or get completely absorbed in something somebody else created. Games were one of the things that made computers interesting to me long before I understood anything about writing software.

The funny thing is that becoming a developer has changed the way I play them.

Every now and then I'll notice some small system working in the background and think about the person who had to implement it. Somebody had to figure out why a horse was clipping through a rock. Somebody spent days making an NPC behave correctly. Somebody built the system that decided what happened when I did something the designers probably hoped I wouldn't do.

I get to stop building for a while and appreciate somebody else's work.

That's not time I regret making room for.

I'm not starting this blog because I think I have software development figured out.

I don't.

What I do have is a somewhat unusual path into the field and a long list of things I still want to learn.

I spent a large part of my life building things physically. Eventually I decided I wanted a different future for myself, went back to learning, and worked my way into technology. Now I get to build things in an entirely different way.

There are still days where I put on boots instead of sitting behind a keyboard. There are still responsibilities that have nothing to do with software. There are still nights where I'd rather play a game than open Visual Studio.

But I also still get excited when I have an idea and don't know how to build it yet.

That's probably what most of this blog will be about: things I'm building, things I'm learning, mistakes I make along the way, technology I find interesting, and occasionally the things other developers have built that make me wonder how the hell they pulled it off.

I didn't move into software because I wanted to become a tech influencer.

I got into software because I wanted something better for myself, discovered that I genuinely loved building things this way, and realized just how far there still was to go.

I'm pretty happy with that.