DEV Community: Daniel Possible Kwabi

[Boost]

Daniel Possible Kwabi — Mon, 31 Aug 2026 18:25:30 +0000

Compares casual versus technical writing times

FrancisTRᴅᴇᴠ (っ◔◡◔)っ

Aug 31

How long does it take for you to write a dev.to article?

#discuss #community #writing #devto

2 min read

Computers Powered By Living Human Brain Cells?

Daniel Possible Kwabi — Thu, 20 Aug 2026 13:37:04 +0000

You heard me right, this isn't some SciFi or a new movie script, it's real. Actual Neurons cultivated in labs, wired into computing systems. Though my first question is... does this mean we are a bit closer to AGI? A future where machines don't simply just calculate but think?

So what is this even? It's Bio-computing. And what is Bio-computing? It's using living neurons as processors instead of your normal silicon chips. Now these cells can adapt, self-organize, and process information in parallel. As we can see, this mimics our human brain.

Still lots of English. What does it even mean?

Unlike chips, neurons can change their connections over time. So technically they can "learn."
Energy efficiency: Biological systems consume far less energy compared to traditional data centers.

I'd think of all this like swapping out your CPU for a tiny brain network.

Why does this matter? Why do all this bio-hacking?

Have you ever been online and there's that one guy in the comment section talking about how AI is wasting our water resources or consuming too much electricity etc? Well, they mean the data centers... that's what these models work off.

This bio-computing solution is essentially energy efficient. Now all this is still fairly early and experimental, but think about all the doors it opens in Science and Technology. Think of the hybrid systems that we can have.

However, that being said — it's not all rainbows.

It sounds impressive for a reason. That's because it's not just difficult, it's "hard" too.

1. Keeping Cells Alive

Neurons need nutrients, oxygen, and stable conditions. So running this "living server" is like running a lab itself more than a data center.

2. Scaling Up

Sure, a petri dish of neurons is all well and good, but powering global infrastructure on the level that data centers do, or even 2021 ChatGPT, is another thing entirely.

3. Ethical Questions

To put this in perspective, when I first saw this I didn't know how to react. My tech brain was going cool, awesome wow!!! And then it was like... wait, did they kill someone? (they didn't). We aren't even done with AI ethical frameworks yet. How would we control this?

What new angles of philosophy do we need to consider? Is there going to be a new Alan Turing test? Like, what even is thinking? Is the "thinking" these bio-computers are going to be doing actually identical to human thinking, or is it just mimicking small portions of thinking?

My brain runs wild.

Silicon gave us the digital age, neurons might just give us the biological age of computing. And at this point it's not even about the question of can we build it?

It's rather the question of... what happens when we do build it?

I hope your brain runs wild as my brain runs wild.

Is Your REST API really a REST API?

Daniel Possible Kwabi — Thu, 20 Aug 2026 01:13:53 +0000

Before anything I want us to keep this name at the top of our heads, not forever but for now. LEONARD RICHARDSON. I know your question. Why?

That's because he gave us a practical measure of some sorts to measure how "RESTful" your API actually is, the Richardson Maturity Model (RMM).

Essentially, it's like a grading system for APIs. From RPC-over-HTTP (Level 0) to hypermedia (Level 3). So let's not be so sure your API is RESTful, let's walk through some ground rules.

The 6 REST Constraints

Contrary to what a lot of novices think, it's not about slapping JSON on HTTP. REST is defined by six additional architectural constraints.

1. Client-Server

Separation of concerns. The client (frontend) focuses on the UI and experience while the server (backend) handles data and security. And they evolve independently.

2. Uniform Interface

The way I look to put this is that a "contract" should be established between client and server, in the sense that they are on the same page. Resources are identified by URLs (/users/5), manipulated via standard HTTP methods (GET, POST, PUT, DELETE), and described with self-contained messages. This uniformity makes APIs predictable and interoperable.

3. Stateless

The server should "remember" nothing between requests. All requests must carry all the information needed to process it. This makes scaling and reliability possible.

4. Cacheable

Because we want to be stateless, things can get expensive real fast, so we cache.

Resources must "say" whether they should be cached or not. So we keep data in some sort of volatile storage as opposed to persistent storage so we prevent the server from repeating identical work.

5. Layered Architecture

As the name suggests, we should have different layers, e.g., a web tier, app tier, and DB tier. Clients don't really know if they are talking to the actual server or some form of intermediary — maybe a proxy, load balancer, or a gateway. This allows for scalability behind the scenes.

6. Code on Demand

This is the only optional constraint, as in reality not every system would need this.

Servers can extend client functionality by sending executable code. Again, this is rarely used but it's part of the family.

RMM

Good, we have looked at the 6 REST constraints. But how do we measure RESTfulness? Well, remember our name? It comes into play here again. We'll use the Leonard Richardson Maturity Model.

Level	Name	What It Looks Like	Problem / Limitation
0	The Swamp	One single endpoint (`/api`) doing everything. RPC over HTTP.	No real REST. Hard to scale, brittle.
1	Resources	Multiple endpoints (`/users`, `/orders`). But still relies mostly on POST for all actions.	Slightly better, but verbs are misused.
2	HTTP Verbs	Proper use of GET, POST, PUT, DELETE. Most APIs stop here.	Good practice, but still missing hypermedia.
3	Hypermedia (HATEOAS)	Server responses include links that tell the client what actions are possible next.	True REST. Flexible, evolvable, self-describing.

At level 3, your API becomes truly navigable like a website. Instead of hardcoding routes, the client can follow links provided by the server. Which means backend can evolve without breaking the frontend. That's the point of REST in the first place...

So, is your API really REST? If it's a level 2, I think you're in good company. Not so bad (most APIs are). But if we want to embrace the full REST vision, we should aim for level 3. Hypermedia is not just some fancy word, it's the key to building truly resilient, adaptable, and RESTful APIs.

Please check out my channel, I just made a Python full Course.

Peace!!!

How I Built a Retro Python Racer from Scratch (Screenshots Included)

Daniel Possible Kwabi — Thu, 06 Aug 2026 16:44:10 +0000

Lovely people, it's been a minute. I hope everyone has been good, alive, and well.

From my introductory post, I spoke a lot, well actually I speak a lotabout how I build games with Pygame, and... well, here's a little "gamedev" piece with Pygame.

Let's start with the finished product. Here's a visual.

I know it's not exactly Need for Speed, but let's just go through my building procedure.

Creating the Window

The first thing to do with Pygame, as I have come to find, is to make your game window. I mean, everything is going to be within the window, so it makes a bunch of sense.

Now, this should be simple, and it usually is but you have to think about the kind of game you want to build.

I realised I needed a portrait-style window for mine as opposed to a landscape window.

Building the Environment

Now I had to start putting things in the window because you can't have a blank game, right?

Of course... unless it's ghosting your partner or those mind games you people do lol.

The first thing to think about really was the environment. I mean, it's supposed to be a racer, so we need the road, the road lines, and all that.

I had a plan: just find a colour that looks like a road and add some race lines to divide it.

Problem solved, right?

Yeah... not exactly.

As you can see above, I tried to "cheat." I was thinking I could just use the pipe character (|) on the keyboard to fake it, but I changed my mind.

(What do you think?)

I ended up just drawing some rectangles to make the lane divisions instead.

Now, if this is your first Pygame trip, don't be confused. A lot of the stuff under the hood is just shapes.

You'd be amazed at what rectangles can do.

I bet you thought all that school math was useless.

Spoiler: it isn't.

Drawing Rectangles

Now let's stop having fun and add a little more substance.

When I say I used rectangles, here's what I mean in detail.

First, you'd define the rectangle (think of it like creating an object).

Example:

rect = pygame.Rect(x, y, width, height)

Now you need to define its position. In other words: Where should this appear?

x = 50
y = 100
width = 200
height = 80

rect = pygame.Rect(x, y, width, height)

Now you have to actually draw it for it to appear on the screen.

Think of it like creating a variable and performing some calculations. Until you actually print() something to the terminal, you won't see any output.

Same idea here.

pygame.draw.rect(screen, (255, 0, 0), rect)  # Red rectangle

Creating the Player

Now let's continue.

Having dealt with the road, I now have to add our player car (it's all shapes for now).

Generally, it's the same procedure.

At this point, we're simply adding a red rectangle to represent our player car.

Making the Car Move

Then our car has to move.

We can't have a game if it doesn't move, right?

When I was learning this, absolutely everyone would just write some mathematics and leave it at that.

No proper explanation.

Just vibes.

But let me see if I can break the cycle.

I like to think of it as a graph.

Let's go back to grade school.

Think of the player car as a single dot.

Now imagine the Cartesian plane.

What does it take to move a point either left or right?

Let's say, on a scale of 10, the left side contains points 1, 2, 3, 4, while the right side contains 6, 7, 8, 9, 10.

Our car is currently sitting at 5, right in the middle.

So if we want to move one unit to the left, that's simply:

5 - 1 = 4

If we want to move four units to the right:

5 + 4 = 9

The summary of all I'm saying is this:

Subtract (decrement) to move left.
Add (increment) to move right.

Keeping the Car on Screen

Then I hit a problem.

In theory, the x-axis keeps going forever, so if you keep incrementing, you can literally drive off-screen.

So we need to set boundaries and handle the left and right wall collisions.

The way to do this is to reset the position of the car to the last valid value within your screen's width.

In our example, let's say the screen width is 500.

But that's not all.

In my explanation, the car is just a single point.

In the actual code, it's a rectangle with both width and height.

So we need to subtract the car's width from the screen width to make sure the entire car stays inside the window.

And Now We No Longer Disappear

Adding the Enemy Car

So now we can add in our enemy car, in blue.

But... same problem with collisions.

They kind of "smush" into each other.

And we don't want that.

That should be a crash that ideally ends the game loop (or whatever outcome you choose).

For this, I made object variables for both the player and enemy cars with all the necessary position values and everything else.

Then this is where Pygame helps.

I found a method in the docs called colliderect(). It's a simple way to check whether the two car objects have touched each other.

Once a collision is detected, I can decide what happens next. In my case, I simply ended the game.

Adding a Score

Then I added a score system.

Basically, increment the score as long as the game loop is running.

(Very creative, I know.)

And that's pretty much it.

Under the hood, we've basically finished the physics and mechanics for our game.

Replacing the Rectangles with Assets

But we don't stop there.

Hell no.

So I went asset hunting and picked up some car sprites.

I got them from the PNGTree website (this is not an ad).

I mention the site just for anyone who may want to replicate the project.

The last thing to do was swap the rectangles out for the sprites so the game would render the actual car assets instead.

And... that's that.

Wrapping Up

If there was something you think I missed, or anything you'd like me to explain in more detail, I go much deeper on my YouTube channel.

I have:

A short, punchy video if you just want the overview.
A full 50-minute tutorial for anyone who wants to recreate the game from scratch.

Thanks for reading. I hope this was fun to read as it was fun to build and write about.

Deployment strategies every engineer should understand...

Daniel Possible Kwabi — Mon, 20 Apr 2026 15:10:19 +0000

1.Big Bang Deployment

Here's how it works:

You build a feature for two weeks. You test it on your machine. Everything is beautiful. Then you push it straight to prod. (it sounds bad already)

Sure this is the easiest way out but if and when something breaks so help you God.

This one is no bueno.

2.Blue-Green Deployment

Better. You run two identical environments. So basically in parallel and you'd route traffic to it using a load balancer.

Rollback is fast. That's great. But if that new code has a nasty bug, it still hits everyone at once when you flip the switch. Better than big bang but still not there yet.

3.Canary Deployment

The smart play. You roll out new code to like 1% of users first. You watch it. You breathe. If nothing breaks then you roll out to 5%, then 25%, then everyone.

If something breaks, only a tiny sliver of users ever see it. This is the way.

Tho there are cases where you just have to big bang it... example being a side project you know isn't very significant.

I'll like to hear your thoughts in the comments.

Self taught Dev is not a flex

Daniel Possible Kwabi — Wed, 18 Mar 2026 14:12:11 +0000

Self-taught developers aren’t real.

Stay with me now....

It's a term that shouldn't really exsist because....

Even the CS grad from MIT.
Even the bootcamp alum.
Even the engineer with 10 years at Google.

They all are self taught....

Sure, some people had structured education.
Some had professors.
Some were lucky enough to learn from legends like David J. Malan

But let’s be honest…
Nobody spoon-feeds you how to debug a production issue at 2AM.

Nobody forces you to read documentation. (you'll learn)
Nobody can teach you how to think through edge cases under pressure. They can try but replicating the real life pressure is just not realistic...

At some point, it’s just:
• You
• The docs
• Stack Overflow
• YouTube
• And now… ChatGPT

And your ability to sit there and figure it out.
The real difference isn’t “degree vs self-taught”.

It’s:
Are you resourceful?
Can you teach yourself what you don’t know?
Can you stay when it gets frustrating instead of quitting?

That’s the actual skill.
In tech, your survival depends on how fast you can learn without permission.
So when I see people leading with:

“Self-taught developer ”
I don’t see a flex, that's just a gimmick at this point

I see the bare minimum requirement to survive in this field.
If you can’t teach yourself… you’re not lasting anyway.

I do get it though, it's normal for human beings to try and find ways to be "special". If you do this then from today start leading with your actual skills... your specialization and stuff like that, and let's dwell more on that.

How to Never Quit Your Coding Journey

Daniel Possible Kwabi — Thu, 05 Mar 2026 13:29:07 +0000

So a lot of times, we look at the tech industry and the advice for people looking to get in is all technical. It's always talking about learning this framework, then learning that one, then getting this certification, or following that creator. We all know the drill.

But we tend to forget the most important skill of all that you will absolutely need, and that is consistency. Because you won't be motivated every day. God knows—and you know—that it's hard to be on this journey.

And maybe people do actually speak about this, but it still doesn't quite land for me. Don't get me wrong, I am not taking the piss out of anybody's suggestions, but I just think it's coming from an angle where only naturally driven or passionate people can utilize it.

Enough rambling. Here are the three targeted mindset shifts that I think you should have that will help you succeed on this journey.

1.Consistency doesn't mean being busy
Consistency doesn't mean that you have to go and be overly productive, packing an impossible schedule that's just going to end up in burnout. Instead, it means we should focus on establishing a pattern. As long as there is a pattern, your smaller efforts compound.

I know we have better attention spans here, so let me go deeper. Say we have two guys who have downloaded Duolingo to learn German. The first guy goes in on the first day and puts in a massive 45 lessons—I am talking serious hours. But that's it. He never actually gets to practice again, and then six months or so later he watches a video, gets motivated, and does the same thing again.

Then we have the second guy who is doing his lessons for 20 minutes a day for a year or even two. Who do you think is closer to being fluent? Yeah, exactly, the second guy. So consistency doesn't necessarily mean being intense and overly productive (if that's even a thing), but rather establishing patterns.

2.Don't stop
What do we think would help the second guy get to the two-year mark? Yeah, right again: not stopping. And I won't just leave it at that—don't worry, I have some pointers.

Think about how you remember to brush your teeth. Every morning when you wake up, you do it. You have done it since you were a child. In fact, on the off day you don't do it—say you went for a sleepover and forgot your brush—you feel weird, no? Good. Now I want you to build a pattern in 90 days. I want you to study code at a particular time every day to the point where, if you miss it, it feels weird, like you committed a crime. Three months is level 1. Later, push it to six months, and don't stop.

3.Switch up your forms of content
Now, you might say that you do not have time. No problem. Maybe you have a demanding day job, a big family at home, or a newborn... whatever it is, no problem, you just need to be strategic.

If you have 15 minutes, watch a tutorial video where they are not doing heavy coding, but just explaining a concept. If you have 10 minutes, or even 5 minutes, use it. If you are on the road a lot or have a lot of chores to do around the house, plug in a tech podcast or an audiobook.

That's just three ways out of many that I used—and still use—to stay sharp in my day. Hope you found value.

And I have a video on this on my YouTube:

https://youtu.be/UUbRJFcwBqI?si=GAm9hJK4ed-Rwu70

You can check it out if you like. Peace.

Confession time: I’ve been keeping a secret from you all...

Daniel Possible Kwabi — Fri, 27 Feb 2026 09:42:00 +0000

Dev family, I have a secret.

In my introduction, I shared most of me but not all of me. And what I failed to share is that I actually have a YouTube channel where I make tutorials on Python!

Between working as a software engineer for the last couple of years and being a Teaching Assistant for a Python, I’ve spent a lot of time figuring out how to explain coding concepts in ways that actually click. I realized I wanted to take the exact same energy I use to help my university students and share it with the wider dev community.

On the channel, I’m focused on breaking down Python concepts, sharing practical tips, and walking through tutorials designed to help you build real skills without the usual headaches.

Whether you're just starting out with Python or looking to sharpen your existing knowledge, I’d love for you to check it out. I'm also super open to feedback and requests—if there's a specific concept or project you want to see a tutorial on, drop it in the comments below!

Here is the link to the channel:

https://youtube.com/@danielpossiblekwabi?si=UydKV-Xd7-GVap22

Let me know what you think! 🚀

The killer’s signature wasn’t on the weapon, it was in the code.

Daniel Possible Kwabi — Thu, 26 Feb 2026 09:05:31 +0000

The killer’s signature wasn’t on the weapon, it was in the code.

In the Bull episode “E.J.”, a self-driving car kills a man. The world blames the AI… until the team digs deeper.
Turns out, someone had slipped in a backdoor, lines of hidden logic that influence the AI.
When the truth surfaces, it’s because the CEO notices, “Carter’s coding signature was all over it.”
That’s how they find the real culprit, not through sensors or data logs, but through human fingerprints inside machine logic.
Fast-forward to today.

Everyone, from students to professionals, even curious hobbyists, are now writing code with AI.
Lines are suggested, completed, or even fully written by a model trained on someone else’s work.
And while that’s powerful, it also means something else: attackers use the same models.
They generate malicious code that look harmless but hides intent deep inside.
No clear style. No signature. Just machine-written precision masking human purpose.

If E.J. were real today, would we even find Carter’s signature anymore?
Could anyone say, “this line of logic belongs to this person”?
Because the deeper we depend on AI, the more invisible human fingerprints become.

Obviously things like this are only relevant to critical systems. But I think it's something to think about.

And just to add on, bull is a very nice TV show. You should watch it some time.

You'll be a junior forever if you don't learn

Daniel Possible Kwabi — Wed, 11 Feb 2026 14:28:59 +0000

You'll always remain at junior level if you think "it works" is an excuse for bad code.

Stop playing the victim when someone with more experience tears apart your code. We aren't trying to find faults. We are trying to save the product.

I recently reviewed a specific codebase. It was a disaster. Thousands of lines stuffed into two files, zero structure, just a big ball of mud. (They took the monolith literally)

So, I did the work. I segregated the code. I introduced folders. I analyzed the whole codebase, the imports, the logic, the functions, let's just say I made it modular. I cleaned up the mess.

The feedback?(More of gossip really but....) "This wasn't necessary. The original code worked."

"He just wants to make us look wrong" (If you do your job well then mine takes me 10 minutes instead of hours). "There's always something to 'fix' with him. Why change it if it runs?"

Let’s get one thing straight.
"It works" is not a standard. It's the bare minimum requirement for software to exist. A house built without pillars works fine until the wind blows.

When I break your code into modules, I am not feeding my ego. I am reducing the cognitive load for the next person who has to read this.

If you think modularity is optional or just an opinion, you haven't mastered simplicity. You’ve mastered laziness and mediocrity.

Until you can appreciate why we force you to structure your code, you aren't ready for the next level. 👇 Devs: Does "it works" ever justify a 2,000-line file?

[Boost]

Daniel Possible Kwabi — Sun, 08 Feb 2026 17:22:39 +0000

Build an Accessible Audio Controller

Richard Pascoe ・ Feb 8

#community #learning #programming #webdev

Are you doomed learning coding in the AI era?

Daniel Possible Kwabi — Fri, 06 Feb 2026 03:08:06 +0000

I pity all those learning to code post chatgpt

"They'll never know the feeling of finally solving a problem after going at it for 24 hours."

I hear this sentiment a lot. And honestly? I get it.

I mean the dopamine hit from solving a problem that was holding you down for days was crazy good(sometimes you still even won't know why it finally worked)

It felt like earning your stripes.A brain massage if you may. Now all that being said....

But I can't help but think some of us want to live in the past.

Isn't what we have now objectively better? I know the application of it is mostly flawed especially in the school system but for this lets assume it's being used wisely.

We used to spend hours just to realize we missed a semicolon.(I do not miss this specifically)

That wasn't problem-solving, that was just a syntax bump

You can still have the pleasure of finishing your projects, though if it takes you too little effort and time it's not the same thing. You won't get the same hit.

So these days with AI I always tell people the bar has gotten higher and just simple projects are not going to cut it. Whether it's your dopamine hit or in the processional space, the bar is very high.

We aren't coding just to debug; we are coding to build. If AI lets new learners skip the frustration and get straight to the shipping, I'll take that trade every time.

And for anyone who shares the nostalgic sentiment;

Do you really pity them or you're angry they have it easier?
Or is it the tech debt that icks you?

I'd like to hear what you think in the comments.