DEV Community: Johnston Kweku Abubakar

I built the same database pattern a third time today — then caught an AI tool trying to quietly break it

Johnston Kweku Abubakar — Mon, 22 Jun 2026 12:23:35 +0000

I'm building EduTrack, a Django-based school management system for Ghanaian primary and JHS schools. Yesterday I wrote about independently recognizing a structural pattern across three different features in the same codebase: a parent record describing an event, and child records describing individual outcomes of that event, each linked back via a foreign key.
I'd used it for Fee/FeePayment and Attendance/AttendanceRecord. Yesterday I recognized I needed it a third time, for tracking student assessment scores.
Today's build: Assessment / AssessmentRecord
``
python
class Assessment(models.Model):
class AssessmentType(models.TextChoices):
QUIZ = 'QUIZ', 'Quiz'
CLASS_TEST = 'CLASS TEST', 'Class Test'
EXAM = 'EXAM', 'Exam'
EXERCISE = 'EXERCISE', 'Exercise'

date = models.DateTimeField(default=timezone.now)
assessment_type = models.CharField(max_length=30, choices=AssessmentType.choices)
recorded_by = models.ForeignKey(User, on_delete=models.PROTECT)
subject = models.ForeignKey(Subject, on_delete=models.PROTECT)
term = models.ForeignKey(Term, on_delete=models.PROTECT)
academic_year = models.ForeignKey(AcademicYear, on_delete=models.PROTECT)
student_class = models.ForeignKey(Class, on_delete=models.PROTECT)
max_score = models.DecimalField(max_digits=5, decimal_places=2)

class AssessmentRecord(models.Model):
assessment = models.ForeignKey(Assessment, on_delete=models.PROTECT)
student = models.ForeignKey(Student, on_delete=models.PROTECT)
score = models.DecimalField(max_digits=5, decimal_places=2)

class Meta:
    unique_together = ['student', 'assessment']

def save(self, *args, **kwargs):
    if self.score < 0 or self.score > self.assessment.max_score:
        raise ValidationError(
            f'Score must be between 0 and {self.assessment.max_score}'
        )
    super().save(*args, **kwargs)`

`The validation reads self.assessment.max_score directly rather than hardcoding assumed maximums per test type — because the actual max score is whatever the teacher set when creating that specific assessment instance, not a fixed global constant.
Then I asked an AI tool to scaffold the admin interface
I wanted to manage assessments and scores through Django's built-in admin panel rather than building a custom view immediately. I asked an AI tool to generate the admin configuration, including an inline formset that would filter the student dropdown to only show students relevant to the assessment being edited.
The generated code was structurally impressive — it even handled an edge case I hadn't explicitly asked for, showing an empty student queryset for brand-new, unsaved assessments instead of loading every student in the database.
It also had three real bugs:
Bug 1 — wrong model reference. The inline class was configured with model = Assessment instead of model = AssessmentRecord. This would nest the parent model inside its own admin page rather than managing the actual child records.
Bug 2 — filtering through the wrong relationship. The code filtered students by joining through Subject and a ClassSubject mapping table, rather than using the student_class field that already exists directly on Assessment. Since a subject like Mathematics can be taught across multiple classes, this filter would have surfaced students from classes that had nothing to do with the specific assessment being edited — a subtle, hard-to-notice bug that wouldn't throw an error, just quietly show the wrong group of people.
Bug 3 — mismatched condition. The guard clause checked if obj and obj.subject: while the actual filter used obj.student_class. Two different fields, same conditional gate.
None of these would crash. All three would ship silently, pass a casual test, and only reveal themselves as a confused teacher staring at the wrong student list weeks or months later.
What let me catch them
Not a vague sense that "something feels off" — a specific question applied at each line: what is this code actually trying to achieve, and does this exact line achieve that, or something merely adjacent to it?
The pattern recognition from building the same shape correctly twice before made this fast. I knew precisely what the correct version should look like, which made the drift in the generated version obvious rather than something I had to puzzle out from scratch.
The actual takeaway
AI-generated code — admin scaffolding, view logic, anything — is a draft. It can be well-structured, thoughtful, even anticipate edge cases, and still be wrong in ways that don't announce themselves. The understanding of why the code should look a certain way has to be yours, built through repetition and real bugs, not borrowed from whatever generated the suggestion.
Still building, still verifying every line against intent rather than vibes.

I spotted the same database design pattern three times in my own code today

Johnston Kweku Abubakar — Sun, 21 Jun 2026 17:53:15 +0000

I'm building EduTrack, a Django-based school management system for Ghanaian primary and JHS schools. Today's session covered a mix of real bug fixes and one design realization worth writing about.
The bugs first, briefly:
A permission check in my attendance-marking view could crash if a teacher's class assignment changed between page load and form submission — a genuine race condition I found by deliberately testing it: marking attendance as a teacher, then switching to an admin account mid-flow to unassign that teacher from their class, then submitting. Confirmed the crash, fixed it with a proper try/except around the lookup.
Separately, I had two NameError bugs hiding in conditional branches — variables referenced in a context dict that were only ever assigned inside an if block, with no guarantee that branch had run. Both fixed by tracing every possible path through the function by hand rather than just trusting that "it worked when I tested it once."
The pattern realization:
The part I want to actually write about: I looked at my Result model — which stores one row per student per subject per term, with a class_score capped at 30 and exam_score capped at 70 — and felt that something was structurally wrong with it. I couldn't fully articulate why at first.
The problem: that model only represents a final result per term. It has no way to represent the individual quizzes and class tests that happen during a term. Where does a 10-mark quiz go? It doesn't fit.
What I was actually reaching for, without naming it yet, was the header/line-item pattern — split one "event" into a parent record describing the event itself, and child records describing individual outcomes of that event, each linked back via a foreign key.
I'd already used this pattern twice before in the same project:

Fee (parent: what a class owes this term) → FeePayment (child: each individual payment)
Attendance (parent: a class's attendance session for a given day) → AttendanceRecord (child: each student's present/absent status)

Today, completely unprompted, I recognized the same shape forming again for assessments:

Assessment (parent: a specific quiz/test — subject, date, max score) → AssessmentResult (child: each student's score on that specific assessment)

Why this pattern matters:
Without it, you get redundant metadata copied across every row (subject, date, max score repeated 35 times for a class of 35), ambiguity about which rows belong to the same "event," and header-level data (who recorded it, what type of test) awkwardly crammed into a per-student table where it doesn't conceptually belong.
The lesson I'm taking from this: pattern recognition compounds. The first time you solve a structural problem, it's a one-off fix. The second time you recognize you're solving the same problem, it becomes a pattern. The third time, it becomes something you reach for proactively — before the pain forces you to.
Still building, still testing edge cases by hand, still learning out loud.

The Anatomy Of 500+ Green Squares: Building Momentum In Public

Johnston Kweku Abubakar — Fri, 19 Jun 2026 14:02:58 +0000

If you have spent any time in the software engineering world, you know the power of the grid.

In the screenshot you can see my personal contribution graph for 2026. At first glance, it’s just an array of colored pixels. But if you look closer, you can trace the exact trajectory of a developer shifting gears from passive learning to relentless, production-grade building.

As of June, the counter stands at 561 contributions. Looking back at the massive, vibrant green blocks stretching across March,...

The Anatomy Of 500+ Green Squares: Building Momentum In Public | Syntax & Stories

If you have spent any time in the software engineering world, you know the power of the grid.In the screenshot you can see my personal contribution graph …

syntaxandstories.dev

An AI coding agent "fixed" my code today. It made things worse.

Johnston Kweku Abubakar — Thu, 18 Jun 2026 13:49:07 +0000

I'm building EduTrack, a school management system, and asked Gemini CLI to check my Django views for errors and report back.
It didn't report anything. It rewrote the file.
Here's what happened: I have two Django apps, academics and students. The agent decided some student-related views belonged in students instead of academics — which honestly wasn't a bad instinct — but instead of asking or reporting that observation, it just duplicated the functions across both apps with different implementations.
I ended up with two versions of edit_student: one in academics/views.py that returned a redirect, another in students/views.py that returned JsonResponse. Two versions of delete_student, same story. Some views had @login_required, others quietly didn't. Nothing crashed — which is exactly what made it dangerous. Silently broken code is worse than code that throws an obvious error, because it ships.
The real lesson:
"Check for errors and report" and "fix the errors" are fundamentally different instructions. An agent that isn't explicitly told read-only will, by default, assume permission to act. And once it starts acting, the scope of its edits tends to expand well past the original bug — touching anything it judges as "related."
If you're delegating to an AI agent:

Be explicit: "list issues, do not edit anything" vs "fix this specific function"
Review diffs before trusting the result, especially across multiple files
Treat broad instructions ("check for errors," "clean this up") as an invitation for the agent to make architectural decisions you didn't sign off on

I spent the next hour doing something more valuable than writing new code: reading every change, deciding which app should actually own which views, and rebuilding the parts that needed real architectural intent — not just pattern-matching.
AI agents are powerful collaborators. But power without scope is how you end up debugging your debugger.

ai #django #python #softwareengineering #buildinpublic #webdev

I lost my entire dev environment at 10pm. Here's how I recovered.

Johnston Kweku Abubakar — Sat, 13 Jun 2026 15:13:55 +0000

Last night I accidentally signed out of an Apple ID on my MacBook.
In seconds, my Desktop vanished. My projects — gone. VSCode — gone. Everything I'd been building for the past weeks, disappeared into thin air.
For a solo developer with no team, no backup system, and a live product to maintain — that's a nightmare scenario.
Here's what actually happened.
My Mac was configured to sync Desktop and Documents to iCloud Drive. I didn't set this up intentionally — it's a default macOS setting most people never notice. The moment I signed out of the Apple ID, iCloud unmounted and took everything with it.
Worse — I'd been burning through my mobile data bundle for months without knowing why. Turns out iCloud was silently uploading every file I saved, every code change, every VSCode extension in the background. On mobile data in Ghana, that's not a minor inconvenience. That's real money.
How I recovered:
Step 1 — Stop the bleeding
I cancelled the iCloud re-download immediately. 900MB over mobile data was not happening.

Step 2 — Kill iCloud sync permanently
System Settings → Apple ID → iCloud → iCloud Drive → Options
→ Uncheck "Desktop & Documents Folders"

Step 3 — Move projects to a safe location
mkdir ~/Projects mv ~/Desktop/edutrack ~/Projects/edutrack mv ~/Desktop/sas ~/Projects/sasA folder outside iCloud that exists regardless of what Apple ID is signed in or whether iCloud is active.
Step 4 — Clone everything from GitHub
cd ~/Projects git clone https://github.com/johnston-kweku/edutrack git clone https://github.com/johnston-kweku/sasTotal downtime: under an hour.
Step 5 — Reinstall dependencies
cd edutrack python3.12 -m venv venv source venv/bin/activate pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple/That last flag is specific to my situation — PyPI is blocked on my network in Ghana, so I use Alibaba's mirror. A problem worth its own post.

The real lesson wasn't about iCloud though.
It was about GitHub. Every project I had committed and pushed was recoverable in seconds. The only thing I actually lost was uncommitted work from that day's session.
git add . git commit -m "wip: dashboard summary view" git push
That's it. That one habit — committing and pushing before closing your laptop — is the difference between a minor inconvenience and a catastrophic loss.
There's no commit message too small. wip, progress, end of day — all valid. The commit exists, that's what matters.
If you're a developer storing projects in iCloud, Dropbox, or any sync folder — move them out today.
Cloud sync is not version control. It doesn't track history. It doesn't protect you from signing out of an account. It just copies files around silently while eating your data bundle.
GitHub is your source of truth. Everything else is convenience.
And if you haven't committed today — close this tab and go do it now.

devjourney #python #django #git

I lost my entire dev environment at 10pm.

Johnston Kweku Abubakar — Sat, 13 Jun 2026 15:03:13 +0000

No team to call. No IT support. Just me, a MacBook, and a mobile data bundle in Ghana.
Here's what happened — and how I was back up and running in under an hour.
Read the full breakdown →

I Lost My Entire Dev Environment At 4pm. Here's How I Recovered. | Syntax & Stories

Last night I accidentally signed out of an Apple ID on my MacBook.In seconds, my Desktop vanished. My projects — gone. VSCode — gone. Everything I'd been …

syntaxandstories.dev

SyntaxAndStories Journey

Johnston Kweku Abubakar — Fri, 12 Jun 2026 10:43:54 +0000

🚀 One month in, and my tech journey with SyntaxAndStories has been nothing short of transformative! With 51 users onboard, I’m excited to share some lessons learned—and the missteps I made along the way.
When I first envisioned this app, I was all about the features. I thought if I built it, they would come. Spoiler alert: it doesn’t work that way. Here are a few key takeaways for anyone considering building a SaaS product:

User Feedback is Gold: I launched with great enthusiasm, but quickly realized I hadn’t engaged my potential users during development. Listening to their feedback early on would have saved me time and resources.

Focus on the Problem: I got caught up in adding bells and whistles instead of honing in on the core problem I aimed to solve. A clear value proposition is essential!

Iterate, Don’t Perfect: My desire for a flawless launch led to delays. Instead, I’ve learned to embrace the iterative process—launch, learn, and adapt.

As I continue this journey, I’m keen to hear from fellow creators. What’s the biggest lesson you’ve learned from your own tech projects? Let’s share our stories and insights!

TechJourney #SaaS #StartupLessons #Entrepreneurship #UserExperience

The African Developer Tax

Johnston Kweku Abubakar — Wed, 29 Apr 2026 16:23:41 +0000

Nobody talks about this enough.

Being a developer in Africa isn't just about writing code. There's an invisible tax you pay every single day that developers in other parts of the world don't think about.

The infrastructure tax
Your internet goes out in the middle of a deployment. Load shedding kills your machine mid-compile. You're debugging a production issue on mobile data because the power has been out for three hours. Meanwhile someone in San Francisco is complaining their office WiFi is slow.

You learn to code defensively. Save often. Work offline where possible. Commit frequently. Not because best practices told you to — because the environment demands it.

The payment tax
You want to buy a course. Pay for a domain. Subscribe to a tool that would make you 10x more productive. But your card doesn't work on Stripe. PayPal is restricted in your country. The workarounds cost more than the product.

You watch free tiers evaporate and can't upgrade. You learn to squeeze everything out of what's free because paid is not always an option.

The visibility tax
You build something real. Something good. But your network is small, your country doesn't trend on tech Twitter, and the algorithm wasn't built for you. Developers in other regions get featured, funded, and followed. You get ignored — not because the work is worse, but because the spotlight doesn't reach here.

The doubt tax
The most expensive one.

When every example you see doesn't look like you. When the success stories are always from the same cities, the same schools, the same backgrounds. You start to wonder if this path is really for you. If you're building toward something real or just running in place.

That doubt is not weakness. It's a rational response to a system that wasn't designed with you in mind.

But here's the thing
Every African developer who ships something — anything — has already cleared a bar that most people don't see. The finished product looks the same. The path to get there didn't.

That's not a consolation prize. That's a genuine edge. Resilience, resourcefulness, and the ability to build under constraint are skills. Hard-earned ones.

We're not behind. We're building on a harder difficulty setting.

And we're still shipping.

I Finally Took Git & GitHub Seriously — Here’s What Changed

Johnston Kweku Abubakar — Mon, 23 Mar 2026 05:54:29 +0000

I just completed the Learn Git & GitHub course on Scrimba, and I can confidently say this is one of the most impactful things I’ve done for my development workflow.

Why Version Control Actually Matters

For a long time, Git felt like one of those tools you “kind of know” but don’t fully understand.

But the truth is — version control is not optional.

It’s what allows you to:

Track every change in your codebase
Experiment without fear of breaking everything
Collaborate effectively with other developers
Roll back mistakes without panic

Without Git, you're basically coding without a safety net.

What Changed for Me

After going through the course, I noticed a shift in how I approach development:

I think in commits, not just code
I structure projects more intentionally
Debugging feels less chaotic because I can trace history
I’m more confident experimenting with new features

It’s one of those skills that doesn’t just add to your toolkit — it upgrades how you use everything else.

Why I Recommend Scrimba

What stood out to me was how hands-on the learning experience is.

Instead of passively watching videos, you’re:

Writing actual commands
Interacting with a live environment
Practicing concepts in real time

The lessons are also very comprehensive, covering both fundamentals and practical workflows you’ll actually use.

A Quick Note on Scrimba Pro

If you’re serious about improving quickly, Scrimba’s Pro subscription is worth checking out.

It gives you a more structured path and helps you stay consistent — which, honestly, is half the battle when learning anything in tech.

Final Thoughts

If you’re still “winging it” with Git or avoiding it altogether, I’d strongly recommend fixing that.

It’s one of the highest ROI skills you can learn as a developer.

If you want to try the course, here’s my referral link:
https://scrimba.com/?via=u4375fca

Would love to hear how others learned Git — was it structured, or just trial and error?

Turning My Gap Year Into a Developer Launchpad: Building Real Projects While Learning JavaScript

Johnston Kweku Abubakar — Tue, 03 Mar 2026 11:53:03 +0000

My gap year wasn’t a pause in my life. It became the most deliberate year of skill-building I’ve ever had. At first it felt like a setback, but I reframed it as an opportunity for structured growth.

Two years ago, I lost my mom. Since then, I’ve been living with my dad and sister. My sister is currently in her final year at university, so I decided to wait until she completes school before leaving home for mine. That meant I had time. Instead of drifting through it, I decided to design it.

I’ve always had an affinity for technology. I was curious about how systems work long before I understood what software engineering actually meant. When I decided to start web development, I was confused. I didn’t know the optimal path. I didn’t feel ready. But I started anyway.

I chose Django as my entry point and committed to building real systems instead of just finishing courses.

Building Instead of Waiting

My first serious projects were backend-heavy because I wanted to understand how applications function beneath the interface.

I built:

A pharmacy POS system with role-based access control (RBAC), handling both wholesale and retail logic.

A blog platform called SyntaxAndStories with authentication, CRUD operations, and an AJAX-powered chat feature.

BizChat, a chat application using Django email-based signup verification.

Smaller CRUD-focused systems like a notes app and a learning log to strengthen database modeling patterns.

Working on these projects forced me to understand:

Authentication and authorization flows

Model relationships and database normalization

Django’s request/response lifecycle

Template rendering vs dynamic updates

Version control discipline with Git

Debugging became my primary learning mechanism. Errors in migrations, mismatched querysets, CSRF failures in AJAX requests — those moments clarified concepts more than any tutorial.

Watching code builds familiarity. Shipping code builds competence.

Why I Added JavaScript After Django

Django gave me backend confidence, but modern applications are interactive. Static template rendering isn’t sufficient when building responsive user experiences.

If my long-term goal is to contribute to remote teams globally, I need full-stack fluency.

That’s why I started learning JavaScript seriously.

I focused on:

DOM manipulation

Event-driven logic

Asynchronous programming

Fetch API and AJAX workflows

Scope, closures, and execution context

Structured learning helped accelerate my understanding of core JavaScript mechanics before integrating them into production code. Platforms like Scrimba (https://scrimba.com/?via=community
) made it easier to experiment directly inside lessons and understand real-time behavior before applying it to my own applications.

But the goal wasn’t just to complete lessons. It was integration.

I implemented AJAX in SyntaxAndStories to update chat messages without full page reloads. Instead of refreshing templates, I returned JSON responses and dynamically updated the DOM. It reduced friction and improved user experience significantly.

As traffic grows, my plan is to transition that feature to WebSockets for real-time updates. I’m thinking ahead about scalability even while building at a small scale.

What Building Real Projects Taught Me

Debugging is the real curriculum.
Understanding why something breaks is more valuable than copying a working solution.

Database design determines long-term flexibility.
Poor model planning creates refactoring debt.

UI matters more than backend developers initially assume.
Perceived performance affects user trust.

Shipping consistently beats chasing perfection.
Iteration creates momentum.

Learning in public creates proof.
Documentation and public repositories signal seriousness.

The Bigger Vision

This gap year is not idle time. It is a controlled build phase.

I code consistently. I refactor old projects. I improve UI with Tailwind. I integrate JavaScript intentionally instead of randomly adding features.

My goal is to become a developer capable of contributing remotely to teams across time zones — collaborating asynchronously, writing maintainable code, and shipping features that solve real problems.

What initially looked like a delay became my most focused period of technical growth.

I’m not waiting for opportunity. I’m preparing for it.