Building for the Web
· 2180 words · 11 min read
Another item off my to-do list.
A year after joining UF Law, my freelance site (soloistsystems.com) was still live. I’d meant for months to move that content to a personal Hugo blog, creating a TIL section for my weekly ‘aha’ moments. After the hundredth spam email, I decided it was time. I had already been taking private TIL notes for months. Setting up this new Hugo site, I realized I’d done this half a dozen times.
Static HTML, PHP, WordPress, Node.js, Metalsmith, Hugo—I’ve cycled through them all. If there’s a through-line to my career, it isn’t the technology. It’s that I keep leaving things and coming back to them, usually with a clearer sense of why.
To some, I’m a webmaster; to others, a marketing technologist or the person who fixes the website. I work at The University of Florida Levin College of Law, managing a large website with 600 pages, 40,000 visitors a month. If you told the 2013 version of me, still learning how to float an image and use a clearfix, that I’d end up here, he would have believed you.
He believed a lot of things back then. Most of all, he believed he understood the web.
Clearfix My Career
In 2013, I moved to North Carolina and worked a remote business development job. Lacking a degree and tired of sales, I needed an escape hatch. When a friend suggested web design, I subscribed to Treehouse and threw myself into front-end development.
I bought a domain, paid for hosting, and made a single element appear in a browser. For the first time in a while, I felt competent. I’d played guitar since I was nine and recorded music on a computer since I was thirteen, so I expected web work to satisfy my creative itch. Instead, I discovered the joy of problem-solving. Debugging. Making the machine obey.
I convinced myself I understood the web in its entirety.
I didn’t. I understood one tiny trick. But the thrill was real, and for a while, that was enough. I leveraged some of these new skills to move into the marketing department at work.
Fatal Error
Then Treehouse moved me from JavaScript to WordPress. WordPress broke my brain.
It wasn’t PHP. Variables, loops, and functions are universal. It was the mountain of WordPress-specific architecture. All the functions and hooks that fired in invisible sequences; theme files nested within theme files. It felt like walking into a house where every light switch was hidden.
Everyone else seemed to get it. I didn’t.
I did what many others did: I copied snippets from Stack Overflow, changed values, and hoped for the best. I didn’t ask for help because I thought I was supposed to already know. I pretended. Pretending stifled my growth.
The problem wasn’t just WordPress. The curriculum had thrown me into the deep end without explaining the pool. This was my first encounter with hype. In 2013, everyone built WordPress sites. It made sense to throw me into it, but it was all just magic. I had no primer on PHP, SQL, or Apache servers. I was lost, and admitting it felt like failure.
RTF…T
I left WordPress swiftly, chasing shinier tools. Ruby on Rails, MEAN, early Next.js—the details blur because the pattern never changed. I’d start a tutorial, build a Todo app, build a basic blog, feel smart, then consider auth and middleware never to move past the tutorial, acutely aware of the gulf between my toy projects and what professionals shipped.
My folders were full of half-finished projects. I was studying hard but going nowhere. I assumed this was how you learned because nobody told me to build what I actually wanted to build. What did I want to build? Why was I even doing this?
There were small exceptions. I loved writing JavaScript on the frontend where I could get immediate feedback. I loved Python and Bash; I could automate little tasks and feel like a sorcerer. I’d gotten just good enough with Python to build a ton of automation into my work, then I quit. I picked up a C programming book instead, spent weeks learning about GCC and pointers, and felt ashamed I’d ever touched Python. As if C were a “real” language and Python a toy. As if I actually knew enough for it to matter.
That era was a slump. I was busy, I was learning, but nothing was real. I performed the role of a developer without ever shipping anything, or even building a portfolio piece I could be proud of.
Tutorials are often just a way to avoid the risk of building something real. A tutorial guarantees a working project, no matter how boring. It’s safer than hitting a wall on a unique project you actually care about.
Simplicity as a Feature
To break the tutorial cycle, I did something unfashionable: I went back to basic PHP and the LAMP stack. I built simple-markdown-blog, a minimal blogging engine for myself. No databases, no complex frameworks. Just raw PHP parsing markdown into HTML and my Apache server.
It was tiny and unimpressive. It was mine. For the first time, I realized simplicity wasn’t a limitation; it was a feature. I finally understood every line of code. The relief was immediate: no database-driven anxiety, just functional, readable code.
sudo mkdir
My foray into JAMStack (static site generators) wasn’t another course—it was an accident.
I made a video about KDE Neon that went unexpectedly viral. I loved KDE’s Plasma 5 desktop when many didn’t; it made me feel like I could finally leave Windows behind. A few years later, I started making content about producing music on Linux, simply because figuring it out had taken me forever and I wanted to spare others the trouble.
That was how Linux-Studio was born. Over a weekend, I bought a domain and built a website using Metalsmith. I followed a tutorial, modified it, and wired in the YouTube API to list my latest videos. I had an about page, one article, and a video feed. I felt accomplished.
I had started a small online community. That weekend taught me what tutorials never could: when you build something because you actually want it to exist, you learn faster. Necessity is a better teacher than rote memorization.
The project eventually became LinuxCreative. The domain changed, and the focus shifted, but the lesson stuck.
Paid to Learn
Years later, I quit my job of a decade. I had no plan; I just needed a break. Almost immediately, people began asking for work.
It’s strange how side hobbies quietly become qualifications. My career had been in marketing and communications, but most requested work involved websites. Years of Linux tinkering and building small sites had turned into a marketable skill.
My first paid gig was rebuilding my cousin’s website, moving it from WordPress to Hugo with a theme I barely modified. I added NetlifyCMS (now Decap) over Git Gateway and wired up all the content types and fields. Then I fixed a larger company’s broken WordPress install, patched vulnerabilities, set up caching, cleaned up old links and GUID problems in the database, and migrated them to faster hosting. My freelance work ranged from motion graphics to web development and marketing automation. I said yes to almost all of it, even when I wasn’t sure I could deliver.
Every time, I thought about saying no. I had very little clue what I was doing. And every time, I said yes anyway.
That era rewired me. Clients don’t care about your stack, MVC, or REST. They care that the thing works and that you don’t disappear. “I can’t” slowly became “I’ll find out.” It’s not confidence; it’s a deadline, a willingness to learn in public, and the humility to admit when you’re in too deep. Building these solutions for others was a catalyst for immense growth in my technical skillset and professional communication. It was also a serious boost for my self-esteem to solve real-world problems while getting paid and thanked for doing it.
Scale and Restraint
Freelancing ended when I needed consistency and work-life balance. I applied for every role at the intersection of communications and technology I could find. The University of Florida Levin College of Law won me over: fantastic people, a highly technical role, and the largest website I’d ever managed. Scale changes everything.
As a freelancer, I moved fast: break it, fix it, move on. At UF Law, every change has a radius. Stakeholders, approvals, political considerations, and complex link structures mean shipping is easy, but shipping responsibly is difficult. I now run two separate development environments for staging major changes: a Docker container in my homelab (the “break it” zone) and a mirror of the production Apache RHEL host environment.
I’ve developed real agency in this role, built on trust and a track record of not blowing things up. Every messy lesson feeds into it: breaking sites early taught me caution, freelance panic taught me problem-solving, and those tutorial years taught me that motion is not progress.
docker ps
Running parallel to my professional work was a homelab obsession. It started with an old laptop, then a desktop demoted to the closet. Running only one service felt wasteful, so I installed Proxmox and started spinning up VMs with no idea what I was doing.
At NinjaTrader, I used that server to automate screen capture, and built an NGINX RTMP mirror service before the company decided to pay for Restream. Since Zoom could only stream to one RTMP endpoint, I built a mirror that pushed to YouTube, Facebook, Twitch, and Twitter simultaneously. It was messy, it worked, and I felt like an MVP. I’d figured it out by searching the web and experimenting, my usual approach.
Eventually, half that Proxmox box became a single Linux VM running Docker containers. When I recently bought a new mini PC to replace the old one, I moved everything into Docker on Fedora Server: an internal network shared with a cloudflared container, Cloudflare tunnels, and Tailscale for SSH access from anywhere. Migrating traditional LAMP servers into Docker builds required a wide domain of knowledge: database dump imports, file permissions, Dockerfile, Docker Compose stack, bind mounts, volumes, and networks. Again, every failure is an opportunity to learn and grow. Pulling this migration off was a direct result of all the lessons I learned along the way.
This hobby has given me a deep understanding of servers, networks, and virtualization. But owning everything is exhausting. Running your own infrastructure makes you respect the managed platforms you used to complain about. You can own your stack, but you have to balance the time you sink into it. I feel like I have struck that balance.
The Marketing Technologist
Which brings me back to Hugo.
Building wesleysinks.com and linuxcreative.com as static Hugo sites felt familiar in the best way: markdown files, templates, and no database to break or containers to keep updated. I’d been here before, in different forms, but this time, I came back on purpose.
I’m not a “real developer” in the way my younger self wanted to be. I still get tripped up defining classes and methods, and I don’t dream in algorithms. I am a marketing technologist. I connect tools, content, and people. That identity fits me better than the one I was chasing.
Simplicity isn’t a step backward. It’s knowing what you actually need.
What I’m Curious About Now
I’m currently curious about Astro, especially given Cloudflare’s backing—I already use their services heavily. Could it replace Hugo for me? I’m also interested in Svelte, despite generally hating frontend frameworks; the two could fit well together. I’ve experimented with Go for simple servers, wondering how far I can push it (or FastAPI) before needing to call myself a backend engineer. I’ve also touched HTMX, Datastar, and Web Components. I like the idea of doing more with less JavaScript, especially with some genuinely cool features coming to native HTML lately.
What I’ve Learned So Far
I don’t deeply know any one technology, and that’s fine. I’ll leave most and return to a few; that’s the pattern. I still don’t know what I’m doing most of the time, but I’ve learned to stop pretending otherwise. The words I lean on most: I don’t know, but I’ll figure it out.
If you’re learning and feel behind, you aren’t. The people you think have it figured out are mostly figuring it out quietly, just like you. You don’t need to finish every course or feel confident. You just need to be willing to look foolish, ask questions, fix what breaks, and come back tomorrow.
The web is too big to master. The industry will keep cycling through the same ideas under new names. The tools will change, but the work—solving real problems for real people—remains the same.
And I’m still learning. Building for the web professionally, I learn something new (and sometimes embarrassingly obvious) every week. Check out my TIL if you want to see what that looks like.