DJ Wynyard

Useful enough to steal

I build software, platforms and automation that make complicated things behave like useful things—and when they don’t, I work out exactly why, fix them and explain the lesson without pretending it was obvious.

I am technical enough to go all the way down the rabbit hole, but practical enough to know nobody came here to admire the rabbit hole. You came because something is broken, confusing, slow, expensive or taking far too much of your life. Let’s sort that out.

Useful Stash is where I tell you what actually worked, what didn’t, why I chose it and where it might blow your foot off. I am not here to perform expertise at you. I am here to leave you with something useful enough to steal.

How I got here

I have worked in technology for more than 20 years and been obsessed with it for more than 28. I’m old(er). Deal with it.

It started with a Commodore 64 and the revelation that BASIC could make a machine do what I told it to do. Then came Computer Studies after school, our first Windows 95 PC, friends, magazines, library books and an obscure mate with an early headless Linux system his dad brought home from Telecom. There was no clean curriculum. I learned by pulling at threads until the whole jumper came apart.

From there it was self-directed learning, learning on the job, TAFE and eventually a PhD in Computer Science from RMIT. I started close to the metal with C, graduated to C++, landed on C#, and used plenty of languages in between whenever the wind blew another one into the stratosphere.

I have worked across small business, large enterprise, government and military environments; on-premises and cloud-hosted systems; custom development, platforms, infrastructure and automation. Name an environment and there is a reasonable chance I’ve either worked in it, migrated it, fixed it, replaced it or been asked why it caught fire.

What I work on

My centre of gravity is C# and modern .NET, software and platform architecture, automation and delivery, and practical AI. I am especially interested in local LLMs and fitting models into real systems without pretending they should own every decision.

The daily toolbox includes macOS, Docker, Python, PowerShell, Bash when it behaves, Rust when I feel like arguing with a compiler, llama.cpp, Cloudflare, Vultr and whatever small tool gets the actual job done.

I work as CTO of Avanoa Technology and founded RePass Cloud. One of the platforms I am currently building is Cinturon360. I will share the interesting parts when they are ready to be shared; a launch date is not permission to manufacture evidence.

How I make this stuff

It normally starts with irritation. Something takes too long, fails stupidly, is badly documented, costs more than it should, or is being explained by somebody who has clearly never tried it.

Then the pattern is simple:

Here’s the problem.

Here’s the tempting bullshit.

Here’s what I actually tried.

Here’s what broke.

Here’s the thing that worked.

Here—steal this.

I start with primary documentation, find the disagreements, and test the thing myself. If a claim is measurable, I measure it. If a command can destroy data, I test it somewhere disposable. If I cannot verify something, I say so instead of upgrading a guess into a fact.

There is no content team hiding behind the logo. It is me: researching, testing, writing, recording, editing, building the site, operating the infrastructure, producing the artwork and discovering why the audio track is wrong at an hour nobody should be awake. Laid-back is the presentation style, not the quality-control process.

What I don’t pretend

I work with databases; I am not a database specialist. I use Rust; I am not a Rust expert. I can operate Kubernetes; I am not the person you hire to rescue a deeply cursed cluster at 3 a.m. Bash and I maintain a functional working relationship, whereas I am a fucking legend in PowerShell.

More importantly, I will tell you when I am outside my depth. Seniority does not turn every opinion into expertise, and using a tool regularly does not make me the final authority on it.

Production taught me another permanent lesson: a successful deployment is not proof the system works, a backup is not a backup until you restore it, and a process still running is not evidence of a healthy service. Test the thing people depend on. Test how it fails. Then test that you can recover it without prayer.

Away from the keyboard, allegedly

I am married to my husband, Johnny. Our household includes four cats and a big brown dog, so nobody is really in charge and every clean recording is an improbable victory.

Outside work there is lots of coffee, Pokémon GO, cooking at home, dinner and date nights, television, travel and going for walks—for real, we actually do that. I also code and invent new solutions outside work, which suggests my understanding of “outside tech” may need professional review.

Tell me where it breaks

Try the thing. Tell me what worked, what broke, or which question I failed to answer. Useful corrections beat polite silence every time.

Say hello, leave a comment on YouTube, or send the question that should become the next piece. If I got something wrong, bring evidence. I will not be offended by being corrected; I will be offended if we knowingly leave the wrong answer sitting there.