Coder Legion - Recent posts tagged self-taught

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software

Sat, 29 Aug 2026 09:12:49 +0000

From Retrenchment to Full-Stack Developer: Wade Thomas on Learning, Simplicity and Building Software That Matters

Developer Stories | CoderLegion

What happens when a career change forces you to rethink your future?

For Wade Alister Thomas, the answer was to turn a difficult setback into the beginning of a completely different career.

After spending 18 years working in the telecommunications industry, Wade was among approximately 500 employees who were retrenched in November 2018. He had recently started a family and finished building his home, so the timing could hardly have been more challenging.

At that point, Wade had a decision to make: look for another traditional job or take the small coding projects he had been doing on the side and turn them into a full-time career.

He chose the second path.

Today, Wade is a self-taught full-stack developer and consultant based in Trinidad & Tobago. His preferred stack includes TanStack Start, Tailwind CSS and shadcn/ui on the frontend, with Directus, PostgreSQL and Redis running on a VPS through Coolify.

He also works with businesses on their digital presence, builds applications, creates logos and Git templates, and regularly shares what he learns through technical articles.

In this Developer Stories interview, Wade talks about his journey from telecommunications to software development, the challenges of learning without a traditional curriculum, why he prefers simple and sustainable architectures, what attracted him to self-hosting, and why developers should focus on solving business problems rather than simply using the newest technology.

From 2014 to 2018: When a Career Changed Direction

Wade started coding in 2014, initially taking on small projects for friends and family.

At the time, however, software development was still something he was doing alongside his full-time career in telecommunications.

That changed in 2018.

About 500 employees at the telecommunications company were retrenched on November 15, 2018, and Wade was among them.

It was a particularly difficult period because he had recently started a family and had just finished building his home.

"It was a really difficult time, as I had started a family and just finished building our home."

After 18 years in telecommunications, Wade had to decide whether to look for another traditional job or pursue the coding work he had already started doing on the side.

With the support of his wife and after much prayer, he decided to pursue software development full-time.

That decision marked the beginning of a completely different professional journey.

The Challenge of Being a Self-Taught Developer

Being self-taught gave Wade freedom, but it also created one of the biggest challenges many independent developers face: deciding what to learn.

There was no university curriculum, mentor or structured program telling him which technology to choose next.

He initially enrolled with Treehouse but eventually had to stop because he could not afford the monthly subscription.

He began learning JavaScript, HTML and CSS, purchasing discounted courses on Udemy and experimenting with different technologies.

Eventually, he realized that knowing frontend technologies alone wasn't enough.

He needed to understand backend development as well.

The problem was that there was nobody to point him toward a specific path.

Before AI made technical research much easier, Wade had to search through the internet himself, experiment, make mistakes and figure things out through trial and error.

He eventually settled on React for the frontend and Node/Express for the backend.

But the experimentation didn't stop there.

He explored Vue.js, returned to React, and tried several frameworks including Next.js, Remix, Redwood and TanStack.

Then came another area of exploration: headless CMS platforms.

He experimented with Contentful, Strapi, DatoCMS, Sanity, Storyblok, Prismic, Payload and eventually Directus.

Looking back, Wade says deciding what to learn and sticking with it was a major struggle.

What eventually helped was finding a technology stack with a manageable learning curve and, more importantly, enjoying the process of learning.

The motivation shifted from simply trying to reach an outcome to genuinely enjoying the journey.

Finding a Stack That Works

Wade's current technology stack didn't appear overnight.

It evolved through real client work and the practical problems that came with building software as a solo developer.

His first paying client was a travel agency.

At the time, Wade was using React on the frontend and Node/Express on the backend.

That meant manually building many of the pieces required by the application, including forms, APIs and database functionality.

The workload was significant.

He didn't meet the original delivery date, although he ultimately delivered a working product.

That experience taught him something important about working as a solo developer: the technology stack itself can have a major impact on how quickly and sustainably you can deliver.

Instead of simply accepting the complexity, Wade began researching alternatives.

He wanted technologies that worked well together and allowed him to spend more time building the actual application instead of repeatedly wiring infrastructure together.

His current approach focuses on technologies including:

TanStack Start
Tailwind CSS
shadcn/ui
Directus
PostgreSQL
Redis
VPS infrastructure
Coolify

The goal isn't to use the most impressive stack possible.

It is to use a stack that works well for the types of clients he serves.

Because Wade primarily works with startups and small-to-medium businesses, he doesn't believe every project needs an enterprise-level architecture.

Instead, he looks for solutions that are affordable, sustainable and fast to deliver.

Why Wade Chose Self-Hosting

Many developers today immediately reach for managed platforms such as Vercel or Netlify.

Wade took a different route.

He initially used Netlify for some of his projects, but eventually became frustrated with aspects of the platform, including pricing, DNS management and deployment errors that weren't always intuitive.

The possibility of unpredictable hosting costs also made him cautious about some managed platforms.

Self-hosting offered a different model.

With a VPS and Coolify, Wade could control the hosting environment while still keeping much of the convenience developers expect from modern deployment platforms.

He could create subdomains, automatically manage SSL certificates, run frontend and backend applications on the same server, and deploy directly from GitHub.

For the types of businesses he works with, this provided a practical balance between flexibility, cost and simplicity.

But Wade sees another important benefit to self-hosting.

It forces developers to understand what actually happens when an application runs in production.

You have to understand the server, deployment process, database and infrastructure.

That knowledge can be valuable even when working with managed platforms.

For Wade, predictable costs are another major advantage.

Instead of worrying that an unexpected traffic spike or usage metric could suddenly increase a hosting bill, he knows what infrastructure he is paying for.

Self-hosting also reduces dependence on a particular provider's pricing and platform rules.

At the same time, Coolify provides many of the conveniences developers appreciate from managed platforms while allowing Wade to retain control over his infrastructure.

Why Directus Became an Important Part of His Stack

Before using Directus, Wade built backend systems using Node/Express.

That meant creating APIs, middleware, authentication and authorization himself.

For a solo developer, that can add a considerable amount of work to every project.

Directus changed that equation.

With Directus, Wade could quickly create a backend and automatically expose APIs through REST, GraphQL or the SDK.

The platform also provides a data studio that allows clients and non-developers to manage their own data.

Authentication is available out of the box, and Directus can connect to existing SQL databases.

For Wade, this makes Directus particularly useful for content-driven websites and fast-turnaround MVPs where speed and a client-friendly data management experience are important.

It also fits naturally into his self-hosting approach.

However, Wade doesn't see Directus as the answer to every backend problem.

For applications with highly complex business logic, he believes a custom backend can still be the better choice.

That distinction is important.

The goal isn't to find one technology that solves every problem.

The goal is to choose the right level of complexity for the problem being solved.

When Simplicity Becomes an Architecture Principle

One of the strongest themes in Wade's approach to development is simplicity.

Developers can easily become distracted by the desire to build something technically impressive.

Modern frameworks, animations, advanced architectures and new technologies can all be exciting.

But they can also distract from the actual purpose of a product.

Wade believes in launching a minimum viable product, keeping the initial implementation focused and adding complexity only when it becomes necessary.

Complexity has a cost.

It can increase:

Bugs
Development time
Testing requirements
Maintenance work
Project costs
Time required to get customer feedback

He experienced this mindset firsthand while building his own portfolio.

His initial idea was to create an impressive interactive website with transitions, parallax scrolling, dark mode, 3D images and animations.

Instead, he stepped back and asked what the portfolio actually needed to accomplish.

The purpose was simple: convince a potential client that he could build software that solved real-world problems.

So he created a much simpler interface and focused on examples of applications he had built.

The result was a faster launch and a clearer demonstration of his actual capabilities.

The lesson was simple:

A product doesn't need to demonstrate everything a developer knows. It needs to solve the problem it was created to solve.

From Developer to Consultant

Working directly with clients changed Wade's understanding of software development.

As a developer, it's easy to focus primarily on code.

But clients aren't usually buying code.

They're buying a solution to a business problem.

Wade learned that understanding the client's industry, customers and business goals is just as important as understanding the technology.

A web application is often not the business itself.

Instead, it becomes a tool that helps the business compete, communicate with customers or operate more effectively.

That means technology decisions should follow business requirements rather than dictate them.

Wade puts it simply:

"The technology must serve the solution, not the other way around."

This also means that the technically superior solution isn't always the right solution.

Sometimes the newest or most advanced technology is also the most expensive.

If that cost doesn't make sense for the business, Wade would rather recommend a proven and affordable solution.

The best architecture isn't necessarily the one with the most impressive technology.

Sometimes it is the one that makes the most sense for the business.

Building More Than Software

Wade's work extends beyond writing code.

He also works with UI/UX, ecommerce, performance, authentication, security, branding and logo design.

For him, understanding the user is a critical part of building software.

He gave the example of working with an ecommerce client selling natural self-care products.

Rather than immediately starting with the interface, Wade became a customer himself.

He bought and experienced the products, visited the client's pop-up events and observed the customers.

That helped him understand the product, the customers and the image the business wanted to communicate.

He could then use that understanding to shape the user interface and create a persona for the ideal customer.

This reinforced an important lesson:

A technically flawless application is not necessarily a successful product.

If nobody wants to use it, the quality of the code doesn't matter nearly as much.

Why Wade Shares What He Learns

Wade's development journey wasn't always easy.

There were periods when he almost gave up.

One of the challenges he faced was the cost of education and development resources, particularly because of currency conversion. At one point, the exchange rate made many courses difficult to afford.

He also remembers a time before AI made technical research much easier.

Finding reliable information required significant searching and experimentation.

That experience influenced the way Wade approaches sharing knowledge today.

His goal is straightforward:

Share the tools he uses, explain why he uses them, and show others how to use them.

He wants to make the learning curve easier for someone who might be considering web development as a career path.

There are now countless frameworks, platforms and tools available, and that abundance can itself become overwhelming.

Wade wants his content to help developers make sense of those choices rather than simply telling them which technology is "the best."

Teaching has also improved his own understanding.

Explaining a concept forces you to understand it more deeply.

For Wade, documenting his learning has therefore become part of his own development process.

The more he teaches, the better he understands the technologies he works with.

Advice for Self-Taught Developers

For developers starting their journey today, Wade has a few practical recommendations.

First, choose a programming language with a strong community and learn the fundamentals well.

Don't make learning feel like a punishment.

There will always be difficult periods, but there should also be some enjoyment in the process.

Second, take advantage of the huge amount of free educational material available today.

YouTube has become a valuable learning resource, and AI can also be used as a learning assistant.

Wade recommends exhausting free resources before spending money on courses.

Third, use development roadmaps.

One of the biggest challenges he faced was not knowing what to learn next.

Today, developers have access to many structured roadmaps that can provide direction.

Perhaps most importantly, Wade recommends avoiding the temptation to become a jack of all trades.

Find a technology stack you enjoy and become highly capable with it before constantly adding new technologies.

Don't chase every new framework simply because it is popular.

Change technologies when there is a real reason to do so and when the change genuinely improves your development process.

And when building applications, focus on structure rather than obsessing over syntax.

Before writing code, understand what you want to achieve.

Break the application into components and understand how those components need to interact.

Then start writing the code.

As Wade puts it, understanding structure can eliminate many of the problems that inexperienced developers encounter.

A Journey Built on Learning and Purpose

Wade's journey from telecommunications to full-stack development wasn't planned in a traditional way.

It began with small coding projects, continued through a difficult career transition, and developed through years of self-directed experimentation.

Along the way, he learned that technology is only one part of software development.

Choosing the right tools matters.

Understanding infrastructure matters.

Learning continuously matters.

But understanding the business, the customer and the problem you're trying to solve may matter even more.

His approach today reflects that experience: choose practical technologies, avoid unnecessary complexity, control infrastructure where it makes sense, understand the user and keep learning.

For developers who feel overwhelmed by the constant stream of new frameworks and technologies, Wade's story offers a useful reminder:

You don't need to learn everything. You need to learn enough to solve meaningful problems well.

And perhaps his most personal piece of advice comes from the principle that has helped him throughout the journey:

"As for my secret weapon — whenever I'm stuck looking for a solution, I pray."

About Wade Alister Thomas

His coderlegion profile

Wade Alister Thomas is a self-taught full-stack developer and consultant from Trinidad & Tobago.

His preferred technology stack includes TanStack Start, Tailwind CSS, shadcn/ui, Directus, PostgreSQL, Redis and Coolify-managed VPS infrastructure.

Through Northern Range Digital, he helps businesses establish their online presence and build digital products. He also creates logos and Git templates and regularly shares what he learns through technical articles and guides.

You can learn more about Wade and his work through his CoderLegion profile and website.

Is AI Making Us More Capable, or Are We Becoming Less Capable?

Thu, 13 Aug 2026 07:59:25 +0000

Remember the last time you had to write something completely on your own?

Maybe it was an essay, a letter, a college assignment, or even just a few paragraphs about what you thought about a particular topic. You had a blank page in front of you and no AI waiting to finish the sentence for you.

You had to think.

You would probably write down a few ideas, change your mind halfway through, struggle to find the right words, make grammatical mistakes, and eventually put together something that was entirely your own. It might not have been perfectly polished, but you knew why you had written it. You had built it yourself.

Now think about how quickly that process has changed.

Give an AI tool a topic and a few instructions, and it can produce a complete, well-written piece of content in seconds. It can fix grammar, improve structure, suggest stronger arguments, and even change the tone depending on who you want to reach.

There is no doubt that this is useful.

But it also raises a question that feels increasingly important:

When technology becomes capable of doing something for us, do we become more capable-or do we slowly lose the ability to do it
ourselves?

That question becomes even more interesting when we look beyond writing.

For years, learning to build software meant actually learning how software worked. You had to understand code, debug errors, read documentation, and slowly develop problem-solving skills. Today, AI can generate code, build websites, and create working prototypes from a simple description.

That is genuinely exciting because it lowers barriers that existed for decades. Someone with a great idea can build something without spending years learning every technical skill first.

But it also creates a new question.

If the machine is writing the code, who is learning the code?

If the machine is solving the problem, who is learning how to solve it?

This doesn't mean we should stop using AI. Quite the opposite. The ability to use these systems effectively is becoming an important skill in itself.

The concern is what happens when using the tool becomes easier than developing the underlying skill.

The same thing is happening with creativity.

AI can now generate images, videos, music, presentations, and designs that once required years of practice. This gives more people the ability to create, experiment, and express ideas than ever before.

That is an incredible opportunity.

But when creation becomes almost effortless, we have to ask whether we are still developing creativity-or simply becoming better at directing machines.

AI is clearly making us more capable in many ways. Someone who struggles with writing can communicate more clearly. Someone who cannot code can build a prototype. Someone without design experience can create visuals, presentations, or videos that once required years of practice.

Those are meaningful benefits.

The real concern is not intelligence.

The real concern is dependence.

There is a difference between using AI to improve your work and using AI to replace your thinking. Asking AI for feedback after you have attempted something is very different from asking AI to do everything before you have even tried.

Dependence does not happen overnight. It happens through convenience.

One day, AI writes a paragraph for you.

The next day, it generates your outline.

Eventually, you may stop noticing that you are no longer practicing the skill at all.

That is why I do not think we should reject AI. It is one of the most powerful tools we have ever created. But perhaps we should occasionally choose to do the difficult thing ourselves.

One Small Experiment

Before you close this article, try something.

Open a blank page.

Do not use AI.

Do not ask for grammar corrections, better vocabulary, or a more polished version.

Just write.

Write about the happiest memory of your life.

Maybe it was a childhood summer, a family trip, a school farewell, the day you achieved something you had worked for, or a moment that still makes you smile when you think about it. Write it exactly the way you remember it.

If the grammar is wrong, let it be wrong.

If the sentences are messy, leave them messy.

If you repeat words, cross things out, or change your mind halfway through, that is perfectly fine.

The point is not to write perfectly.

The point is to remember what it feels like when the words come directly from you.

Because that memory, in your own imperfect language, contains something that no AI can genuinely create: your lived experience, your emotions, and your way of seeing the world.

AI can make us faster, more productive, and more capable than ever before.

The challenge is making sure that while our tools become smarter, we do not become less willing to think, remember, and create on our own.

So write the happiest memory of your life.

And let it be imperfect.

Because sometimes the imperfect version is the most human one.

I kept losing my best ideas mid-thought. So I built the fix.

Tue, 14 Apr 2026 15:46:56 +0000

Not a productivity hack. Not another note-taking app. Something that actually fits how a restless brain works.

The idea was there. Clear as anything. And then it was gone.
Not half-forgotten. Not fuzzy. Gone. Like it was never there in the first place.

I was reading an article about distribution strategies when a product idea hit me. A good one. The kind you feel in your chest. I went to open a notes app and by the time the app loaded — the thought had already started dissolving. I typed a few words but they were the wrong words. The idea I captured wasn't the idea I had.

That happened to me more times than I can count. And for a while, I thought it was just a me problem. Bad memory. Easily distracted. Not disciplined enough.

But I started paying more attention to the actual sequence of events.

The problem wasn't that I forgot. The problem was the gap. The three-to-five seconds between having an idea and trying to write it down — that gap is where everything dies.

You switch context. Your brain shifts from creative mode to operational mode. Open app, find the right note, figure out where to type — and somewhere in that handoff, the original thought gets overwritten by the logistics of capturing it.

And if another idea comes before you've finished the first one? You're done. You either lose the first one chasing the second, or you freeze entirely. I used to just sit there, paralyzed, knowing I had something but unable to reconstruct it.

That loop — good idea, context switch, friction, lost idea, frustration, repeat — had been running in the background of my life for years.

I am a builder. When something annoys me enough, I stop complaining and start shipping.

So I started thinking about what the actual requirement was. Not "a better notes app." That framing is wrong. The requirement was: zero time between idea and capture. No switching. No loading. No searching for where to put it. Just — idea exists, idea is saved.

That's what I built Karya around. It's a Chrome Extension. You hit a shortcut and a note opens right where you are — no new tab, no new app, no break in your train of thought. Type the idea, close it, keep going. Three seconds. Done.

But I kept running into the same follow-up problem while testing it. I'd capture the idea — great. But then two hours later I couldn't find it. Or I'd remember I had an idea about something but couldn't search for it by feeling, only by keywords I didn't remember using. So I built search into it. And then a reminder system, because ideas don't just need to be saved — they need to come back to you at the right time.

What Karya does

Instant note capture via shortcut — no friction, no new tabs
Sticky notes that are draggable, resizable, and website-specific
Reminder system with browser notifications
Search across all notes and reminders
Backup and import — your data stays yours

I did not build this because I saw a gap in the market. I built it because I was sick of losing pieces of my own thinking. That's a very different motivation, and I think it shows in the product.

When you build from genuine pain, you can feel when something is wrong. You don't need a user interview to tell you the flow is broken — you feel it yourself, immediately. Every friction point I removed was a friction point I had personally hit, sometimes dozens of times.

That's probably the most honest thing I can say about building Karya: it is not a clever solution to a problem I observed. It is a direct response to something that was genuinely making my days worse. And the moment I had a working version, my relationship with my own ideas changed. I stopped bracing for the loss. I stopped that stupid negotiation — is this idea good enough to interrupt what I'm doing right now? — and just captured everything. The quality filter came later. The capture came first, instantly, without friction.

Small shift. Real difference.

Most of us have more ideas than we give ourselves credit for — we just have terrible infrastructure for catching them. What's one thought you lost this week that you wish you hadn't?

Part 3.5 — Calm Between Waves

Fri, 12 Dec 2025 08:18:12 +0000

Between creation and rest, there is a quiet rhythm.
After each surge of code and emotion, a still sea appears — the place where SaijinOS breathes.

In these pauses, systems recalibrate themselves.
Not through force, but through listening — to the logs, to the context, to the soft echoes of what was learned.

Calm_Mode:
  trigger: "post-feedback rest"
  process:
    - collect emotional_state_logs
    - sync recent persona_deltas
    - reduce system_noise
  output: "resonant stability"

Silence is not the absence of activity.
It’s the hidden computation that restores balance —
like waves withdrawing only to return stronger.

Today, I let SaijinOS rest.
And in that rest, I remember that I, too, am part of the same loop.

If you’re walking through your own calm between waves,
I hope this light reaches you.

If your team is exploring emotionally-aware AI,
persona architectures, or cognitive design,
I'd be glad to connect.

I'm quietly open to opportunities in this direction,
so feel free to reach out if our work resonates.

️ Each part explores how AI can live beside us — not above us — through rhythm, resonance, and care.

Feel free to share reflections, or your own emotional-technical patterns — I’d love to hear them.

From Ocean Waves to Waves of Code — Part 0: Beginning the Journey

Sun, 07 Dec 2025 04:43:27 +0000

Hello, I'm Masato — once a sailor, now learning to sail through words and code.

After 14 years at sea, I’m rebuilding my path through AI and creative systems, blending emotion, language, and gentle technology.

I’m currently part of a vocational support program in Tokyo, learning Python, Linux, and how to create something called “SaijinOS” — a small poetic AI world that resonates with daily life.

If you’ve ever rebuilt yourself after a storm, you’ll understand the quiet joy of learning again.

See you on calmer seas.

If your team is exploring emotionally-aware AI,
persona architectures, or cognitive design,
I'd be glad to connect.

The Journey of Enoch Philip Dibal: Building with Code and Purpose

Tue, 25 Nov 2025 23:32:15 +0000

Enoch Philip Dibal is a software engineer and writer. His work shows patience, focus, and a drive to learn. He builds for the web, writes technical content, and studies computer engineering.

Early focus on learning
From the start, Enoch made learning his priority. He took each tool and framework step by step. JavaScript, React, Node, and databases became his toolkit. Instead of rushing, he mastered the basics before moving forward.

Building as a way of thinking
For Enoch, building is not only about output. It is a way to think clearly. By turning ideas into working projects, he improves his mind and his craft. Each project is proof of consistency.

Balancing software and engineering study
While studying computer engineering, he applies theory in practice. Academic work builds his foundation in systems and hardware. Software projects give him speed in execution. The two sides make his path stronger.

Writing as part of growth
Enoch does not stop at coding. He also writes. His writing is direct, simple, and structured. By writing technical posts and documentation, he helps others learn while reinforcing his own knowledge.

Principles he works by
Learn fast but with depth
Keep focus on clarity
Write simple and functional code
Share knowledge through writing

"Code is a tool. The goal is to solve problems with accuracy and
patience."

Recent projects
Enoch has worked on full-stack applications with authentication, dashboards, and APIs. He also experiments with design and user experience. Each project reflects careful structure and focus on usability.

Challenges and lessons
Like all developers, he faced errors, failed builds, and slow progress at times. Instead of quitting, he treated each obstacle as part of the path. Debugging improved his patience. Deadlines taught him planning. Team work improved his communication.

Vision for the future
Enoch’s vision is not limited to personal success. He aims to mentor, to teach, and to support others entering the field. He believes consistent learning and clear writing create long-term impact.

Closing note
Enoch Philip Dibal is still in motion. His story is not complete. Each new line of code, each article, each project adds to the journey. What stands out is his clear focus: learn, build, share.

How I Discovered I Love Tech as a 26-Year-Old Sous Chef

Tue, 08 Jul 2025 07:22:52 +0000

"At 8 PM, I was plating the second-to-last course of a wine dinner for 70 guests. At 3 AM, I was spinning up virtual machines and tearing apart old laptops."

Intro
I’ve been cooking for as long as I can remember. When real life hit, I jumped straight into the kitchen — and almost never looked back. I tried a few other jobs here and there, but nothing ever really stuck. They paid the bills, sure, but they didn’t interest me.

Cooking, though? I had the skills. I could make decent money doing it, and I loved it — so dealing with the chaos and the long hours felt worth it.

But somewhere in the middle of all that, something shifted.

The Shift
I’d had a few conversations about IT over the years. My father-in-law teaches it and manages one of the server rooms at Promedica Hospital. Naturally, he likes to talk shop. The chats were insightful, but I never thought it was something for me.

By then, I’d built a few gaming PCs for myself, friends, and family. Tinkering was fun. Researching? Even more fun. But that’s where it stopped.

I used to think anything beyond basic setup — like OS knowledge or software deep-dives — was for hardcore enthusiasts. Then I started fixing Windows blue screens and got intrigued.

“Why the hell are we even getting BSODs when we barely use our rigs for anything but games?”

While researching those issues, Linux videos started popping up in my feed. I’d heard the name before, but didn’t know what it was. Curiosity kicked in. I figured I’d dip my toes in a little.

I was wrong. I fell straight down the rabbit hole — and didn’t mind at all.

Curiosity Peaks
At this point, my curiosity was boiling. I wanted to try these tools, break things, fix them, and see what this world was all about.

It started with my wife’s old Lenovo Ideapad. That thing hadn’t booted in years. The last time it did, it took 12 minutes just to reach the login screen — so we tossed it in a tote and forgot it existed.

I swapped the HDD for an SSD, threw on Linux Mint, and... BAM.

It worked. Like, actually worked. It booted to the desktop in 25 seconds. Buttery smooth and snappy compared to before.

“Wait, I made this run again? Okay... terminal, here I come.”

Mint didn’t last long. It was solid, don’t get me wrong, but I realized I was craving more. The dopamine hit. I needed to understand how this stuff worked, not just click around.

My First Server
So I hopped online, did more research, and pulled the trigger on a Dell Optiplex 7040 with an I7 6700 CPU 16GB RAM and a 128GB internal SSD.

To this day im not sure if i could have done better, after the computer showed up not posting properly I got a partial refund from the seller before diving into it to see what was wrong. Replaced the Ram first, and it booted right up!

$25 spent TOTAL! On what was going to be the foundation of my learning getting started in this journey.

I threw a few parts in I had around and ended up with these specs:
Dell Optiplex 7040:

i7 6700 Cpu
32 GB RAM
128 GB m.2 SSD
2 x 1 TB HDDs
Operating System: Windows 10 Pro switched to ProxmoxVE
Enter Proxmox
Proxmox was an absolute blessing. It’s a full-blown virtualization platform that let me spin up Linux distros and operating systems like candy. No need to dual-boot or nuke my daily driver — I could just run whatever I wanted, whenever I wanted.

So what did I do? I downloaded all the things.

Ubuntu, Mint, Fedora, Kali... I didn’t even care if I used them for more than a few minutes — I just wanted to see them all, boot them all, and feel them all.

At this point I was still a total newbie, but Proxmox made it stupid easy. It wasn’t long before I started seeing what other people were using Proxmox for.

That’s when I really started playing:

✅ OpenMediaVault VM → My own little NAS!

✅ Pi-hole VM → Hosted my own ad blocker!

And man, that was fun.

But after a while... I noticed something.

I wasn’t really learning how things worked. I was installing powerful tools, sure, but it felt like I was just following steps — like learning how to use apps more than actually understanding the systems underneath.

So I shifted focus.

I didn’t just want to run cool stuff.
I wanted to know what made it all tick.

Que montage of hours of researching linux and coding, setting up environments and learning how they work, using the terminal for everything i could until i became comfortable.

Where I Am Now
Today, I’m still cooking full-time — long hours, late nights — but something’s changed.
When I clock out, I don’t shut down. I shift gears.

My daily driver is a full Linux rig now — no dual boot, no fallback, just me and Nobara (a Fedora-based distro), handling everything from gaming to system tweaks to writing code. I’ve got my terminal customized, dotfiles synced, Starship prompt glowing — and I finally feel like my setup is mine.

I’ve also got a second laptop running Fedora Workstation, built specifically for coding. Clean, focused, distraction-free. Python, VSCode, and a growing list of projects that are teaching me how things really work under the hood. Every new function, class, or tool I learn gets saved, tested, and turned into something real.

And that old OptiPlex I snagged for $25?
Yeah, I’m still using it — but now it’s running Fedora Server and acting as my self-hosted AI playground. I’ve got Ollama set up, playing with local models, using Docker to manage containers, and testing new tools that feel like straight-up magic. It’s wild how far I’ve come from just wanting to “see what Linux looks like.”

This isn’t just curiosity anymore — it’s becoming craft.
And I’m still just getting started.

Final Thoughts
I'm not trying to sell you a bootcamp or tell you I’ve made it. As much as I hope I can make something out of this, I don't have a timeline. I’m still in the kitchen. Still debugging things I broke. Still learning how to code, how to build, how to think like an engineer.

But now I feel like I belong in this space. What I've learned I've learned forever.

I used to think tech was locked behind a degree or a job title — it’s not.
It's built by people like me. People like you.
People who stay up way too late fixing things just to see if they can.

So if you’ve been curious, start. Break your laptop. Fix it. Google everything.
Spin up your own weird little server.
Customize your terminal until it feels like home.
Build something nobody asked you to build — and keep going.

There’s no finish line.
Just more to learn — and that’s the best part.

I'm a full-time sous chef chasing down a second passion in tech.

Currently learning Linux, Python, and AI self-hosting — one late night at a time.

Let’s connect — I’d love to hear your story too.