DEV Community: Shaquille Niekerk

The cost of learning everything

Shaquille Niekerk — Mon, 29 Jun 2026 08:16:18 +0000

The more I tried to learn, the less I felt like I actually knew.

For the longest time, I thought becoming a better software engineer meant learning as much as possible, and I tried to do this as quickly as possible.

If a new Typescript framework appeared, I wanted to learn it. If everyone was talking about AI agents, I wanted to understand them. My thinking was simple: the more I learned, the better of a developer I'd become.

At least that's what I thought.

It wasn't until recently that I realised I wasn't running out of motivation, I was running out of mental resources.

The never-ending checklist

My weeks started looking something like this:

A full-time software engineering job.
LeetCode before work.
YouTube tutorials during lunch.
Researching a topic after work.
Books I've bought, waiting to be read.
Side projects that would help me "experiment" with what I've learned.
A playlist of talks on topics I'd find time to watch.

AI became a big thing, and suddenly there were LLMs, agents, MCP servers, RAG, prompt engineering, and another hundred rabbit holes waiting to be explored.

Instead of feeling excited, I felt like I was just falling behind. Every topic I wasn't learning felt like I was falling behind.

The knowledge gap

Part of this came from conversations I'd have with senior developers. I'd walk away thinking, "I have so much left to learn". Now, I don't think that's a bad realisation; the problem was with how I responded to it. Instead of picking one area to improve, I tried to improve everything at once. Frontend, backend, architecture, cloud, devops, AI, all of it.

Every new technology felt like another piece of the puzzle I couldn't afford to ignore. Ironically, trying to close every knowledge gap only made me feel further behind.

Context switching is more expensive than we think

I've tried creating the "perfect" schedule, as you read about previously...
LeetCode before work, tutorials over lunch, study sessions after work, and reading after dinner. On paper, it looked productive. But in reality, my brain could never adjust. I'd get stuck on a LeetCode problem before work, then I'd spend half my workday subconsciously trying to solve it. At lunch, I'd start watching a tutorial while still thinking about the feature I'd been building five minutes earlier. By the evening, I'd sit down to study another topic... The words on the screen made no sense, and it felt like a mission just to keep my focus.

I wasn't being lazy, I was just mentally exhausted.

The IDE was open, but my brain was closed

I'd open my IDE, open the project I want to work on, look at the code, and just sit there. Not because I didn't want to work. But because I genuinely didn't have the mental energy to start.

The same thing happened with documentation or tutorials. I'd be three sentences deep until I realise I've just been reading, or listening, to the words but not actually paying attention to understand what is being said. That was always frustrating.

The side project graveyard

If there's one thing I'm embarrassingly good at, it's starting projects. Actually finishing them, though? That's another story.

Every new idea felt more exciting than the last one. I'd jump into it, convinced this was the one. A few weeks later, another idea would steal my attention. Months later, I'd revisit an old repository only to wonder, "Why did I build this again?"

I wasn't lacking motivation; I was constantly resetting it on new projects.

The real cost

The strange thing is that I was busy, really busy. But six months down the line, I struggle to point to anything I'd actually finished.

I'd spend more time planning how I was going to learn something than actually learning anything. I'd make enormous roadmaps and become overwhelmed by the size of them. So, I'd shorten the roadmap only to convince myself I was taking shortcuts. So, I'd rebuild the roadmap again.

Somewhere along the way, planning became a substitute for progress.

How I'll approach learning instead

Now, I'm still figuring this out. I don't have a magical productivity system. But what I do know is that trying to learn everything at once has never worked for me.

So now I'm trying something much simpler.

One project.
One topic.
One goal.

Finish what I'm doing before chasing the next exciting idea. Accept that some technologies will have to wait. And understand that it's better to be great at a few things than to be okay at a lot of things.

Final thoughts

If I could send one message back to myself a couple of years ago, it would be this:

Focus on small increments. Decide where you want to go, commit to that path, and ignore all the shiny things trying to pull you away from it.

Software development moves incredibly fast. There will always be another framework, another AI model, another language, another "must learn thing". The list will never end, but your mental energy does.

Thanks for reading, and I hope that if you take anything away from this, it's that finishing what you start is far more valuable than constantly chasing the next big thing.

The Hidden Job of a Software Architect

Shaquille Niekerk — Mon, 22 Jun 2026 11:45:16 +0000

Before we begin, I'd like to preface this post by saying that these are simply my thoughts on the subject. I'm not a software architect, nor do I claim to be an expert. This is me exploring the topic and putting my thoughts "on paper," so if I've misunderstood something, feel free to correct me in the comments.

In this post, I'd like to cover what it means to be a Software Architect.
Imagine you're asked to build a simple login screen.

A junior developer might think about the form and UI that need to be built.
A mid-level developer might think about authentication and authorization.
A senior developer might think about security, performance, maintainability, and operational concerns.

So what does the software architect think about? All the above for sure, but also how all components fit with each other, what happens when requirements change, and what trade-offs the team is willing to accept today that they'll probably live with for years to come.

The term Software Architect gets thrown around a lot. Sometimes it sounds like the most senior engineer's responsibility. Other times it sounds like the person who spends all day drawing diagrams and attending meetings.
So what is a software architect, really?

The Software Architect

Martin Fowler describes architecture as the set of important decisions that are difficult to change later.

The database you choose.
Whether you go microservices or monolith.
How systems communicate.
How security, scalability, reliability, and maintainability are handled.

These decisions create constraints that shape everything built afterward.

So, an architect's job would be:

Defining system structure.
Evaluating trade-offs.
Managing technical risk.
Aligning technical decisions with business goals.
Creating a shared vision for development teams.

An architect's job seems to be less about writing code and more about making decisions that help other developers write better code.

Thinking like a Software Architect

As a developer we all usually start out thinking about features. But architects need to think in systems. Where a developer thinks "How do I build this?", and architect would think "Should we build this at all?". Where a developer thinks "Which library should I use?", an architect would think "What happens if this dependency disappears?".

Thinking like an architect must be difficult because every decision comes with trade-offs.

A microservice is scalable, but comes with complexity.
A monolith is simpler to build and maintain, but may become harder to scale.
SQL gives us consistency, but sacrifices some flexibility.
NoSQL gives us flexibility, but can introduce consistency challenges.

There are rarely perfect solutions. There are only solutions that are appropriate for a particular context. And these decisions affect the team in major ways, because going back on most of these decisions will be very costly, some decisions can be reversed in a week, while others can take months or even years to undo.

Architects spend much of their time identifying which decisions fall into that second category.

So an architect doesn't optimize for elegance, they optimize for outcomes.

The core of being an architect is understanding systems, constraints, trade-offs, and people better that anyone else.

The more I think about it, the less software architecture seems to be about technology and the more it seems to be about decision-making. Technologies change. Frameworks come and go. Databases evolve.

But understanding systems, constraints, trade-offs, and people remains constant.

Maybe that's why software architecture feels so difficult. You're not designing software for today. You're making decisions for a future version of the system, a future team, and a future set of problems that don't exist yet.

The Last Generation of Developers Who Learned to Code Manually

Shaquille Niekerk — Mon, 15 Jun 2026 06:21:15 +0000

There was a time when software engineers had to understand the machine almost as much as the software itself.

Not metaphorically. Literally.

Game developers working on older consoles didn’t just write games, they engineered around physical limitations. Cartridges weren’t just storage devices. Developers learned how to manipulate the hardware itself to squeeze out more performance, more memory, more possibilities. Every byte mattered.

And that got me thinking about AI.

Not in the “AI is replacing developers tomorrow” kind of way. More in the:
“What actually happens to software engineering when the hardest part is no longer writing the code itself?” kind of way.

Because if you zoom out far enough, software engineering almost feels like a long history of abstraction. Each generation moves one layer further away from the metal.

From Hardware Wizards to Software Builders

Early programmers needed to think about hardware constantly.
Memory constraints.
CPU cycles.
Storage limitations.
Manual optimization.

Then came higher-level programming languages. Suddenly we weren’t flipping bits or writing assembly for everything anymore. Languages started handling more complexity for us. Eventually memory management became less painful too.

Manual garbage collection gave way to runtimes and managed environments.
Frameworks appeared.
Libraries exploded.
Open source communities grew.

And slowly, software engineering started becoming less about building everything yourself, and more about knowing how to assemble systems effectively.

The Internet Changed the Developer Brain

Then came another massive shift: the internet.

More specifically, searchable knowledge.

Sites like Stack Overflow completely changed how developers worked. Before that, a lot of programming knowledge lived in books, documentation, university courses, or the minds of senior engineers guarding ancient deployment rituals like dragons protecting caves of gold.

Then suddenly:

someone somewhere had already solved your problem
explanations were searchable
code snippets were one copy-paste away

Developers joked about it constantly.

“99% of programming is just Googling.”

“Stack Overflow is my senior developer.”

At the time, some people criticized this shift.
“You don’t really understand the code.”
“You’re relying too much on external knowledge.”

But something interesting happened. Developers didn’t become less productive, they became dramatically more productive.

The value wasn’t memorizing syntax anymore.
It became understanding systems, architecture, trade-offs, debugging, and knowing how pieces fit together.

And now AI feels like the next evolution of that same pattern.

AI Might Be the Biggest Abstraction Layer Yet

Today, AI can:

scaffold applications
explain concepts
generate APIs
debug code
write tests
create SQL queries
refactor components
summarize documentation

Sometimes frighteningly well.

The weird part is that this changes the development process itself.

For years, writing code was the bottleneck.
Now the bottleneck is slowly becoming:

knowing what to build
verifying correctness
designing systems properly
communicating intent clearly
understanding whether the generated solution is actually good

Maybe the future software engineer spends less time manually writing every line and more time acting like:

a systems architect
a technical director
a reviewer
a validator
an orchestrator of intelligent tools

Not replacing engineering knowledge, but changing where that knowledge gets applied.

The “Copy-Paste” Debate Is Happening Again

What’s fascinating is how familiar this all sounds. People once mocked developers for relying on Stack Overflow. Now people mock developers for relying on AI. But maybe we’re watching the same cycle repeat itself.

Every major leap in software engineering seems to create fear that “real engineering” is disappearing.

Higher-level languages.
Frameworks.
Libraries.
Search engines.
Open source.
Cloud infrastructure.

Each abstraction reduced friction.
Each abstraction also changed what skills mattered most
And every time, developers adapted.

We’re Still in the Launch-Window Era of AI Development

One thing I keep thinking about is console generations in gaming.

If you compare early games released on a console to games released near the end of that same console’s life cycle, the difference is insane.

Developers eventually learn:

the quirks of the hardware
optimization tricks
hidden capabilities
workflow improvements
what not to do

By the end of the generation, you get masterpieces that seemed impossible when the console first launched.

That honestly feels a lot like where we are with AI right now.

We’re still shipping the equivalent of launch titles.

Some AI-assisted software today feels messy.
Over-engineered.
Poorly understood.
Built too fast.
Held together with hope, dreams, and motivational quotes.

But that might simply be the awkward early phase of learning a new tool.

Over time, developers will probably learn:

when AI helps
when it hurts
how to structure workflows around it
how to validate outputs properly
how to combine speed with quality

And eventually, teams that truly understand these tools may build things that feel impossible by today’s standards.

So… What Does a Software Engineer Become?

I don’t think software engineers disappear. At least not in the way some people predict, but I do think the role evolves.

The same way engineers once moved:

from hardware-focused thinking
to software-focused thinking
to framework ecosystems
to cloud-native systems

…we may now be moving toward intent-driven development.

Where the real skill isn’t:
“Can you write every line manually?”

But rather:
“Can you design, guide, validate, and refine complex systems effectively?”

Because AI can generate code.

But understanding:

trade-offs
scalability
maintainability
security
user experience
business logic
architecture

That still matters, and maybe now more than ever.

Final Thoughts

I don’t think we fully understand yet how AI will reshape software engineering.

Honestly, I think we’re still in the experimental phase where everyone is simultaneously excited, confused, skeptical, and slightly terrified.

But looking back at the history of software development, one thing seems consistent:

Every major abstraction changed the way engineers worked.
And every time, the developers who learned how to properly use the new tools ended up building incredible things.

Maybe AI is just the next chapter in that story, or maybe it’s the biggest shift yet.

Either way, I think we’re witnessing a fascinating moment in software engineering history.

And I’m very curious to see what developers become on the other side of it.

What do you think?

Are we moving toward a future where developers become architects of intent?
Or do you think AI-assisted development is being massively overhyped?

The Real Power of Claude Code Isn’t the Code Generation

Shaquille Niekerk — Mon, 08 Jun 2026 12:01:51 +0000

I would like to take some time to talk about AI coding tools, specifically my experience moving from GitHub Copilot to Claude Code CLI.

This isn't going to be a "Copilot vs Claude" cage match. I still use Copilot daily inside VS Code. It's great at what it does.

But over the last few months, I noticed something changing in the way I worked with AI.

I started with Copilot mostly with:

autocomplete
inline questions
formatting help
quick logic block reviews

Alongside that, I'd use ChatGPT for debugging, refactoring, tests, and explaining concepts when my brain temporarily hits a blue screen. And all this worked well.

Then one day, my company got a subscription to Claude, and things started shifting pretty quickly.
Not because the code generation was magically better. But because Claude Code made me think differently about context.

The early days

The first moment that really sold me on Claude Code wasn't some massive autonomous feature implementation. But rather a skill.
I had set up a reusable skill that updated multiple files across a test structure while keeping formatting and conventions consistent.

That was the moment it stopped feeling like "smart autocomplete" and started feeling collaborative. And honestly, the transition wasn't too difficult for me because I was already used to properly prompting AI by:

giving enough context
clearly defining goals
discussing changes before implementation
reviewing plans before execution

The harder part was learning how to structure everything around Claude Code, because once you start using the skills, hooks, CLAUDE.md file, and agents, you realize pretty quickly:

The real power of Claude Code isn't the code generation.

It's the systems you build around it

Copilot vs Claude Code

Copilot still shines for quick edits for me. If I'm manually working through a logic block and know exactly what I want, Copilot's inline autocomplete is fast and lightweight. I still use it constantly.

Claude Code feels different in that it feels more context-aware, especially when working across multiple files.

With Copilot, I tend to monitor more closely. With Claude Code, I spend more time planning before implementation even starts. And strangely enough, that planning phase has made me think more like an architect than just a developer.
This honestly has been one of the biggest benefits for me.

My Claude Setup

Every project I work on now has its own Claude structure:

.claude/
 | skills/
 | agents/
 | hooks/
 | docs/
CLAUDE.md

This setup was heavily inspired by Anthropic's courses, which I'd genuinely recommend if you want to use Claude Code properly. They are free to all.
The ones I found most useful were:

What I like about project-specific setups is that each codebase gets its own context. A React TypeScript frontend gets frontend-focused skills. A Go backend gets backend-focused skills. And each CLAUDE.md file contains things like:

coding standards
naming conventions
architecture rules
project overviews
patterns to follow

Even some simple rules have a huge difference in consistency.

The skill I use the most

The skill I always use is a planning skill.
The workflow is simple:

I describe the feature or bug
The skill scans the codebase
It identifies what exists and what may need to change
It creates a planning document inside: .claude/docs/

Once the document is created, I manually review and approve it before implementation starts.

The approval step matters the most because one thing I've learned real quick is this:

AI should not be left alone to do the heavy lifting

Hooks, Guardrails, and Security

Another thing I think many developers overlook with AI tooling is security. These tools can read a lot if you let them.

I use hooks to prevent Claude from accessing sensitive files using PreToolUse matchers for:

Read
Edit
Write
Grep (this one is often overlooked) A simplified version looks something like this:

{
   "matcher": "Read|Edit|Write|Grep",
   "block": [
     ".env",
     "secrets/",
     "private-keys/"
   ]
}

It's not perfect, but it adds guardrails. And I think guardrails should be one of the most important parts of AI-assisted development. Because AI tools are incredibly capable, but they're also extremely confident, sometimes they're confidently wrong.

The best description I've heard, and the one I now use constantly, is this:

Treat AI like a super confident junior developer.

It will be Fasr, Helpful, and sometimes brilliant, but they still require oversight.

Where I am today

Right now, I still don't fully trust Claude Code to implement large features without supervision. And I think that's a healthy mindset because sometimes it hallucinates patterns, over-engineers, or confidently walks directly into the architectural equivalent of a wall.

But despite that, it has already changed the way I develop software. I spend more time planning, more time thinking about systems, and creating reusable workflows instead of solving the same problem time and time again.

My goal is not to stop coding, it's to code better. AI should not be used to replace developers, but rather to help developers think at a higher level.

That’s it from me for this post.
I'd love to hear how other developers are using Claude Code, Copilot, Cursor, or any other AI tooling in their workflow.

What's your current setup looking like?
And which AI has become your go-to coding copilot so far?

Comms Under Fire - Update 01

Shaquille Niekerk — Fri, 16 Jan 2026 13:27:50 +0000

This is a major update that I've done on my game.
From a shift in the overall purpose of the game, to the mechanics, down to how things look. Below I will go over everything that I've done and try and explain why I've done it.

Purpose

Originally I wanted to create a web demo of a game I've wanted to create for PC, a game where you're in the drivers seat of a propaganda machine, and the middle man between soldiers on the ground and the powers that decide the fate of the nation. Oh, and this takes place during a war...
Once I created the demo I realised that the tools I had to create this proved to be more difficult, so I stripped back on some functionalities and in doing so I realised I was working toward a different idea. a classic competitive typing game.
This will have leader boards, with those who have the highest WPM sitting at the top, challenge modes where you can challenge other users to see who types the fastest, and a story mode, if you just want to improve in a relatively stress free mode, while getting the gist of what the story would be in this world.

Mechanics

The mechanics have not changed that much, the major change is that I am trying to remove any mouse input. Having the main element of the game be controlled solely by keyboard inputs.

Looks

Originally I had two monitors on screen. One that displayed the text you needed to type, and the other displaying the text that you were typing.
This approach brought a few issues. Firstly people kept getting lost where they were in the text because they had to move their eyes between two monitors. The fix for this was to show a cursor of where you were as you typed, but this just made people only focus on that one monitor, making the two monitor approach seem redundant... Now I think I will still keep the two monitor approach for the main game I plan on creating, but for now one monitor seems to do the job just fine.

Update 01

So here we are with the first update.
A whole new game mode, from a story driven typing game to a ranked typing game. A whole new look, from a two monitor setup to a single monitor setup that can be controlled entirely with the keyboard.

For Update 01 I've only included the story mode. But rest assured that I am working on many updates to get this thing having all game modes I've mentioned, and any new ones that come to mind as I go.

Thank you for reading,
And please check out the game here.
And leave a comment on what you think, or let me know if you have any issues

How One Game Made Me a Gamer Again

Shaquille Niekerk — Tue, 13 Jan 2026 14:56:04 +0000

Lately, games have started to feel less like an escape and more like a chore.

Every new release seems to come with a trade-off. Battle passes, cosmetic shops, seasonal content, daily logins. The message feels clear: the more money you spend and the more time you sink, the more fun you’re allowed to have. Microtransactions are “optional,” of course. Just like breathing.

I started wondering if the problem was me.

Maybe I’ve just lost the patience to really get into games. Maybe adulthood hollowed out that part of my brain. I’d watch reviews where someone confidently stamped an “8/10” on a game, boot it up myself, and immediately feel like I’d played it already. Same mechanics, different coat of paint. Or worse, a game that felt unfinished unless I paid to fill in the gaps.

Then, almost by accident, I played Dispatch.

For those who don’t know it, you’re in charge of a superhero group, managing crises and sending heroes out to fight crime. No endless progression systems. No dangling carrots. Just a focused idea, executed well.

I finished it in one sitting. And immediately wanted to replay it to see the other outcomes.

That hasn’t happened to me in years. I still haven’t finished The Sims 2, and I started that around 2007.

That experience made me pause. Maybe I wasn’t burnt out on games. Maybe I was just burnt out on the kinds of games I’d been choosing.

So I tested that idea.

Instead of relying on reviews and scores, I went back to how I picked what game I play back in the day, so I started watching trailers and forming my own opinion about whether a game actually looked fun to me. Not “content-rich” not “worth the grind” just fun.

That’s how I landed on High on Life.

On my first play, I went for four uninterrupted hours.

That might not sound impressive, but for me, that’s huge. Four hours without checking the time. Four hours without feeling guilty. Four hours without that nagging sense that I should be doing something more “productive.”

And when I stopped playing, I didn’t feel like I’d wasted my time.

So now I’m left with a burning question.

Is it just me, or have a lot of modern games become either souls like pits that require time and dedication just to master one move, or carefully engineered money machines designed to drip-feed dopamine? Games that don’t respect your time unless you give them your wallet too?

So great games are still out there, and I’ve just been looking in all the wrong places.

What game(s) have you been playing lately that was just an absolute blast?

My First game - Comms Under Fire

Shaquille Niekerk — Thu, 11 Dec 2025 14:57:28 +0000

A game set in an alternate world where two nations are locked in a brutal war. You’ve been assigned to man the comms, where you’ll find yourself drafting Propaganda to keep your fellow citizens calm, hacking into enemy communication channels to leak sensitive state secrets, and planting destabilizing messages to push the enemy’s civilians into panic.

All of this while staying alive during active invasions, relaying time-sensitive comms from the frontline to HQ, and doing whatever it takes to help win this war.

The Comms Under Fire mini-demo has just gone live, and you can play-test it right now. It’s the tiniest snippet of the full idea — a small taste of what the final game will become. I’ll be releasing the full version on Steam once I’ve got the proper tools to build it out.

For now, enjoy the free online mini-demo. Updates will be rolling in, so keep an eye out!