DEV Community: Daniel Possible Kwabi

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.

Top Linux commands: A Developer’s Survival Kit for the Terminal

Daniel Possible Kwabi — Tue, 03 Feb 2026 16:19:20 +0000

I know my job title doesn’t say DevOps engineer, but at the end of the day, I handle just enough of the Software Development Life Cycle (SDLC) that I have to know some DevOps. I don’t know who told me this, but “don’t ship on Fridays” is so real. It’s the easiest way to mess up your weekend, though I know sometimes you don’t have a choice.

Let me paint you a picture. It’s 4pm Friday and the deployment pipeline is red. The cloud dashboard is just spinning endlessly. It’s just you and your dark terminal, and you’re praying that your server responds.

In these moments, the GUI can’t save you. You can try, but good luck. You need the raw speed of the Linux command line. Having done this a few times over the years, I have built a survival kit of commands. I am not talking about cd and ls; I am talking about tools that have helped in debugging situations like this. I am talking about frozen processes, disk space issues, tracing API failures, and everything in between.

Enjoy.

tail -f Setting up the Scene: You deploy a new feature, and the user says it’s not working. You check the dashboard, but it’s delayed by five minutes. You need to see the error as it happens.

The Command:

tail -f /var/log/nginx/error.log

Why I Use It: This streams the log file to your screen. I usually open this in a split terminal window, trigger the bug on the frontend, and watch the error stack trace fly by in real-time. It’s the fastest feedback loop you can get.

2.grep -r
Setting up the Scene: You have 50 different log files or a massive codebase, and you need to find every file that references a specific variable or error code like "payment_failed."

The Command:

grep -r "payment_failed" ./src

Why I Use It: Opening VS Code to search is slow on a remote server. The recursive grep searches through every folder instantly. It tells me exactly which file and line number is guilty.

3.htop
Setting up the Scene: The server is lagging and requests are timing out. You suspect a memory leak or a rogue process eating the CPU.

The Command:

htop

Why I Use It: Unlike the boring top command, htop gives you a colorful, visual bar chart of your CPU and RAM usage. You can see exactly which process—usually a stuck Node.js script—is hogging 99% of the resources.

4.df -h
Setting up the Scene: Your database crashes out of nowhere. No error logs are being written and the server is acting weird.

The Command:

df -h

Why I Use It: This checks your Disk Free space in a human-readable format. Nine times out of ten, the crash happened because the logs filled up the hard drive. This command saves me hours of debugging ghost bugs.

5.netstat -tuln
Setting up the Scene: Your app says "Deployment Successful," but when you visit the URL, you get a "Connection Refused" error.

The Command:

netstat -tuln

Why I Use It: This lists all the ports the server is actually listening on. I often find that while my app is running, it’s listening on port 3000, but Nginx is trying to talk to port 8080. This command reveals the mismatch instantly.

6.history | grep
Setting up the Scene: You fixed a complex bug three days ago using a long Docker command, but now the bug is back and you can't remember the exact syntax you used.

The Command:

history | grep "docker"

Why I Use It: I don't memorize long commands; I just remember one word from them. This searches my entire command history for that word and shows me what I typed last week. It’s my external brain.

7.curl -v
Setting up the Scene: You are trying to debug an API, but you don't know if the issue is the firewall, the browser cache, or the code itself.

The Command:

curl -v http://localhost:3000/api/health

Why I Use It: curl fires a request directly from the server itself. The -v (verbose) flag shows the "handshake," the headers, and the raw response. If this works but the browser doesn't, I know the issue is the firewall or Nginx configuration, not my app logic.

8.kill -9
Setting up the Scene: You found the stuck process using htop, but it refuses to close. You tried asking nicely, and it ignored you.

The Command:

kill -9 [PID]

Why I Use It: This forces the process to stop immediately. It doesn't save data and it doesn't clean up; it just ends it. I use this only when a process is completely frozen and blocking the port. You just need to replace [PID] with the Process ID you saw in htop.

The terminal used to terrify me. I always wanted things to be graphical, but once you work on a few deployments, you realize it’s not just sysadmins who need this stuff. Once you know what you’re doing, you can be very fast.

DOCUMENTATION SAVED MY LIFE

Daniel Possible Kwabi — Mon, 02 Feb 2026 21:10:07 +0000

This is a story from the early, early days—I’m talking internship days at Telecel (a big deal company here in Ghana). To give you some context, Telecel itself is one of the top two internet providers for the whole country. However, they made a venture into fintech—yeah, let's call it fintech. Since they basically power people's phones, they opened up a new department for mobile money.

That's enough scene setting. Now I find myself in this large company working on the (you guessed it right) mobile money dev team. The more popular name for this was Telecel Cash. And my boss? He's a busy man. He knows he has to teach me and all, and to be fair he tries, but... he's not exactly there for me.

On top of that, he really trusts me. Boy, I do not know what they told him (I was moved from another office, but story for another day). So he just gives me these big projects to be doing. For example, I would do projects on DStv integrations so the TV service could have Telecel Cash as a payment option. I would design whole frontends and backends and have to integrate with the MPESA API.

Now here's where the life-saving comes in. The thing is, he trusts me that much, hell the whole company does, but at the time I wasn't quite there yet. And can you blame them? I guess not, because at the end of the day I would somehow pull it all off and fix all the errors too.

But we know all things come to an end (well, almost). So there's this particular project, and it's so big I can't even mention it. I think there was even an NDA, but big stuff. And of course, I as the intern get a chunk of responsibilities. This time though... a lot of things go wrong. Like, the code wouldn't even run, let alone get to the point of testing the endpoints in Postman. Missing imports that were right there... code words and errors that I didn't understand.

I ran to my boss, of course, and he's like, "Oh just look at the site where you downloaded the SDK." So I am on there not even really knowing what I am looking for, and then it dawns on me that it must definitely be the docs.

So I start reading it and reading it. And I now find out there's a kit for everyone's language. (You know how I write Python and all). All this while I was trying to hack it in C which I just "kinda knew." Also, all the dependencies you had to import had specific versions tied to them; for some the latest worked, and for some you would need to grab older versions. Turns out that particular project needed a whole different implementation.

I take all these problems one by one and I solve them. But this time when the boss finds out, he acts a little different. He's all like, "You actually did it." And as testimony to how impressed he was, I have recommendation letters and endorsements for all my trouble.

That's why I have a soft spot for documentation and always think it should be done right, especially if the project is of significance. I even looked into Mintlify yesterday, a tool that allows you to have the docs on the web. Very cool!!!!

Yeah, so that's how docs saved my life. Write good ones that save others too.

HOW I BECAME SUPERMAN

Daniel Possible Kwabi — Thu, 29 Jan 2026 13:19:05 +0000

When I was 3 years old I wanted to be superman (yh I know everyone did). Then when I was 6 years old I wanted to be the president. Then at age 9 I wanted to make the metal birds move in the sky, I wanted to be a pilot.

Things get really foggy from here but you get the idea. There was the doctor phase which I thought would stick because I actually studied general science at the high school level. There was the scientist phase where I wanted to be a physicist like Albert Einstein because I was topping the physics class. Oh and there was the hacker era where I wanted to take a peek into NASA. You get the whole picture.

Become a member
So at this point as you’ll imagine I am into computers and I start studying and studying and making a few projects here and there and once again in my life, I was like “I am going to be a software engineer”. And boy did it stick because as the second thing I really got serious about, I went to school for it and actually enjoyed it.

You’ll meet people who’ll say it’s a nightmare but I loved every bit of it. And since then I have gone on to contribute to the world. I have software solutions that are being used in offices today, I have lots of apps on the web that are helping businesses run, and I have myself tons of projects both professional and passion driven.

Most notably I spend my time building simple games in pygame and the mathematics behind it all is so fascinating. Learning about game loops, drawing, updating and even positioning objects (oh the object oriented programming) has been very fun. It’s harder without a dedicated Engine like Unity or Unreal but I do it for the passion.

Today I find myself in a remote team solving real world problems
with ambition just like when I was 6. And while the whole journey from 3 years old has taken about 18 years, I think I truly did become superman (at least in tech).

This is my own weird way of introducing myself. Hey, my name is Daniel Possible Kwabi and I am a product engineer.