DEV Community: Goodluck Igbokwe

Landing My First Commit in Django Core.

Goodluck Igbokwe — Wed, 11 Nov 2026 14:39:35 +0000

Every developer’s open-source origin story usually starts with the same comforting delusion: “I’ll just pick up a quick documentation ticket, fix a typo, and collect my shiny contributor badge before lunch.”

But when I joined Session 7 of Djangonaut Space and got placed in Team Carina, I quickly realised that contributing to a framework as battle-tested as Django doesn’t work like that, and honestly, I’m glad it doesn’t.

In Djangonaut Space, you aren’t just thrown into the deep end of Trac and told to swim. Having our Navigator, Lilian, and our Captain, Maryam, guiding Team Carina gave me a real framework for how to approach open source like an engineer rather than a drive-by code committer: understand the problem at its root before you even think about claiming a ticket.

Reproducing a 14-Year-Old Misconception.

While hunting through Django’s Trac issue tracker, I came across Ticket #18543 (a ticket opened 14 years ago) regarding ImageField validation.

Spoiler alert: it was among the tickets curated by my Navigator.

The core complaint on the ticket was deceptively simple: the documentation for django.db.models.ImageField originally claimed that the field "validates that the uploaded object is a valid image." At some point over the years, someone tried to address the confusion by adding a note to the documentation:

Django does not validate whether an uploaded file is an image.
We recommend to validate image file correctness in forms, or serializers.

Wait, does it validate images, or doesn’t it?

Instead of blindly clicking “Assign to me” on Trac and editing text, I wanted to see what Django was actually doing under the hood. If a ticket has survived for 14 years, there is a reason people are confused by it.

I updated my forked Django repository, spun up the local test environment, and wrote a small regression test to reproduce the behaviour firsthand. I created a model with an ImageField, passed it a corrupted non-image byte stream (essentially a text file pretending to be an image), and ran full_clean() directly on the model instance.

It passed without raising a ValidationError.

Only after seeing that test confirm the exact behaviour described in the ticket did I go back to Trac, officially claim #18543, and start digging into django/db/models/fields/files.py to understand why.

Where Django Actually Validates Files.

Tracing the source code revealed why that documentation paragraph had been tripping developers up for over a decade. Django splits ImageField across two completely different architectural layers that happen to share the same name:

django.db.models.ImageField (The Model Layer): This class inherits directly from models.FileField. If you inspect its methods in django/db/models/fields/files.py, it never overrides validate() or clean(). In fact, the model layer only ever touches Pillow lazily inside update_dimension_fields()—and only if you explicitly set width_field or height_field on your model. Otherwise, calling model.full_clean() performs zero image verification beyond basic FileField checks (like max_length or nullability).

django.forms.ImageField (The Form Layer): When a ModelForm or the Django Admin renders a model with an ImageField, the model field’s formfield() method swaps in django.forms.ImageField as the default form class. That class hooks into Pillow inside to_python() to verify that the uploaded file is a genuine, non-corrupted image.

The existing documentation tried to warn developers about the model layer’s limitation, but by broadly declaring “Django does not validate whether an uploaded file is an image. We recommend to validate image file correctness in forms or serializers,” it accidentally misled developers into thinking they had to write custom validation logic from scratch, even when using standard Django forms!

Opening PR #22210 and the Lesson of EAFP.
With the reproduction confirmed and the codebase traced, I opened PR #22210. When you are making your very first pull request to Django Core, your natural instinct is LBYL (Look Before You Leap): you hesitate in the comments, overthink every word, and want to ask permission before making a move so you don’t get it wrong in front of seasoned maintainers.

Early in the review process, Johannes Maron dropped a piece of Python wisdom that completely changed how I view open-source collaboration: EAFP (Easier to Ask for Forgiveness than Permission). Instead of waiting around asking if an approach is okay in theory, push the commit. Give reviewers a concrete diff to react to, and trust the review pipeline to refine it.

Architectural Boundary in Technical Documentation.
What followed on PR #22210 was a masterclass in technical writing and software architecture. In Django, PRs go through rigorous community review before being merged by one of the Django Fellows. Watching Johannes Maron, Tim Schilling, and Django Merger Sarah Boyce weigh in on my diff taught me that good technical documentation is never “just text”, but instead it is a strict reflection of architectural boundaries.

Takeaways for New Contributors.
Landing my first commit in Django core left me with a few practical principles for future tickets:

Read the implementation, not just the docs: Even on a documentation ticket, accurate technical writing comes from tracing the underlying Python code (validate(), clean(), and formfield()).
Practice EAFP on pull requests: Push your best attempt early. Reviewers can refine a concrete diff much faster than a theoretical question.
Respect architectural boundaries in documentation: Good reference docs mirror the separation of concerns in the codebase itself. Keeping model-layer docs focused on model behavior prevents confusion down the line.
Give reviewers room to align: When multiple reviewers are weighing trade-offs on your PR, pay close attention to the codebase conventions they cite, and be ready to synthesize their feedback when asked.
Thanks to Maryam(Captain), Lilian(Navigator), Tim Schilling, Johannes Maron, and Sarah Boyce for the thoughtful reviews on PR #22210, and to the Djangonaut Space organizers and my Team Carina peers for the constant support. On to the next ticket!

I Finally Got pgAdmin 4 Working in FlyEnv on Windows — Here’s What Actually Went Wrong

Goodluck Igbokwe — Thu, 13 Aug 2026 11:02:04 +0000

If you are installing pgAdmin through FlyEnv on Windows and the installation fails while building pywinpty, you may see an error similar to:

error: the configured Python interpreter version (3.14)
is newer than PyO3's maximum supported version (3.13)

You may also see:

ERROR: Failed building wheel for pywinpty
Failed to build installable wheels for some pyproject.toml

based projects

The important part of the error is not actually pip itself. In this case, pywinpty is being built from source and uses PyO3/Rust. The version of PyO3 involved in the build does not support Python 3.14, so the build fails.

The Fix

The simplest workaround is to make sure FlyEnv uses Python 3.13 for the pgAdmin installation instead of Python 3.14.

1. Select Python 3.13 in FlyEnv

In FlyEnv, open the Python section and make sure a Python 3.13 installation is available and selected.

For example:

Python 3.13.x

Do not use Python 3.14 for this installation while the affected dependency still has this compatibility limitation.

2. Remove the failed pgAdmin virtual environment

If FlyEnv already created a pgAdmin virtual environment using Python 3.14, simply changing the global Python version may not be enough because the existing venv still points to the old interpreter.

From the pgAdmin directory:

cd "C:\Program Files\FlyEnv-Data\server\postgresql\pgadmin4"

Remove the existing virtual environment:

rmdir /s /q venv

Then reinstall pgAdmin through FlyEnv so that the virtual environment is recreated using Python 3.13.

3. Verify the interpreter

After installation:

venv\Scripts\python.exe --version

You should see something similar to:

Python 3.13.x

You can also verify that pgAdmin was installed correctly:

venv\Scripts\python.exe -m pip show pgadmin4

4. Launch pgAdmin

The executable should be available at:

venv\Scripts\pgadmin4.exe

You can launch it with:

venv\Scripts\pgadmin4.exe

FlyEnv should then open pgAdmin in your browser, usually at:

http://127.0.0.1:5050

What about Python 3.14?

This workaround does not mean Python 3.14 itself is broken.

The problem is the dependency chain used during the pgAdmin installation. In particular, the pywinpty build in the affected setup uses a version of PyO3 that does not yet recognize Python 3.14.

This may no longer be necessary in a future FlyEnv/pgAdmin release if the affected dependencies are updated to support Python 3.14.

So if you encounter this error, try Python 3.13 first rather than fighting the Rust/build-toolchain errors.

NDPR, GDPR, and CCPA — What Every Nigerian Techie Should Know About Data Compliance

Goodluck Igbokwe — Fri, 18 Apr 2025 00:03:14 +0000

So today’s focus in my legal learning sprint was digital compliance—the rules that tell us how we can (and can’t) collect, store, and use people’s data.

If you’re building websites, apps, or working with client data, this is non-negotiable. Let’s break down what I learned.

What Is Digital Compliance?

Digital compliance refers to following laws and regulations that govern how data is handled online. This matters for:
• Websites that collect emails
• Apps with user accounts
• Payment or tracking systems
• Freelancers managing client/customer data

If you’re touching anyone’s data, you’re playing in this space.

Nigeria’s NDPR: Our Local Data Protection Law

The Nigeria Data Protection Regulation (NDPR) came into effect in 2019 and is enforced by the Nigeria Data Protection Commission (NDPC).

Key points:

• You must inform users when collecting data
• You need clear consent
• You must keep data secure
• You’re required to limit data collection to what’s necessary

If you run a business or handle any user data in Nigeria, compliance is your responsibility—even if you’re just one person.

How NDPR Compares to GDPR & CCPA

Here’s a simple breakdown of how Nigeria’s NDPR holds up against international data laws like the EU’s GDPR and California’s CCPA:

• Consent Requirements: All three laws (NDPR, GDPR, and CCPA) require user consent before collecting personal data. NDPR and GDPR focus on opt-in consent, while CCPA allows opt-out in some cases.


• Right to Be Forgotten: NDPR and GDPR both grant users the right to have their data deleted. CCPA offers more limited deletion rights but still gives users control over their information.


• Penalties: Under the NDPR, non-compliance can cost up to 2% of your annual gross revenue. GDPR has even steeper fines—up to €20 million or 4% of global turnover. CCPA fines can reach $7,500 per violation.


• Does It Affect Small Businesses? Yes. All three laws apply to businesses of all sizes, as long as personal data is involved—even if you’re a solo freelancer or developer.


• Transparency & Notice: Each law requires that users be clearly informed about what data you’re collecting, why, and how it will be used.

Why It Matters for Devs & Freelancers

• Writing a Privacy Policy is not optional—it’s a legal requirement.


• If you use cookies or trackers, you need a cookie notice and opt-in.


• Collecting emails for newsletters? NDPR requires explicit consent.

Even if your audience is mostly Nigerian, odds are someone from the EU or US will interact with your project at some point.

Takeaway: Know the Rules. Respect the Data.

The more we move into global work and SaaS, the more important data laws become. Ignorance isn’t an excuse anymore—especially when compliance is easier than ever with templates and no-code tools.

I’m already planning to add:

• A proper privacy policy to my website


• A cookie banner


• Better data storage hygiene on client projects

Tools & Resources I Checked

• [Nigeria NDPR Summary – TechCabal](https://techcabal.com/2019/03/05/nigeria-data-protection-regulation/)


• [GDPR Overview – EU Website](https://gdpr.eu/)


• [CCPA Basics – State of California](https://oag.ca.gov/privacy/ccpa)


• [Termly Privacy Policy Generator](https://termly.io/products/privacy-policy-generator/)

Contracts 101: What Every Nigerian Freelancer and Developer Needs to Know

Goodluck Igbokwe — Wed, 16 Apr 2025 09:09:02 +0000

Day 2 of my legal literacy journey focused on one of the most misunderstood but crucial topics in tech: contracts.

Whether you’re freelancing on Upwork, working with local clients, or building a product with friends, contracts are your first line of defense. Let’s break it down.

What is a Contract (and Why Should I Care)?

A contract is simply a legally binding agreement between two or more parties.
But in tech, it’s so much more than that. It defines:
• What you’re doing
• When and how you’ll get paid
• Who owns the work you create
• What happens if things go wrong

If you’re working without a contract, you’re basically running on trust and that’s not scalable.

Key Elements of a Valid Contract (Under Nigerian Law)

To be enforceable, a contract generally needs:
1. Offer & Acceptance – One person proposes, the other agrees
2. Consideration – Something of value is exchanged (e.g. your time, their money)
3. Intention to Create Legal Relations
4. Capacity – Both parties must be legally capable
5. Legal Purpose – It must not be for something illegal

Types of Contracts You Might Encounter as a Techie
• Freelance Work Agreements – Outlining deliverables, milestones, and payment
• Employment Contracts – With terms around hours, benefits, IP, and termination
• Non-Disclosure Agreements (NDAs) – To protect sensitive information
• Partnership or Co-founder Agreements – When building something with others

What to Watch Out For

Here are a few things that stood out to me today:
• If the contract doesn’t say when you’ll get paid, that’s a red flag.
• Avoid “Work for Hire” clauses unless you truly want to give up IP rights.
• Make sure scope creep (extra features) is addressed. This is a common dispute source.

My Personal Takeaway

As a developer, I used to think contracts were just corporate fluff. But now I realize they are protective tools—especially for freelancers. They help avoid scope disputes, late payments, and ownership confusion.

I’m working on drafting a simplified freelance contract later this week, and I’ll make it open-source.

Resources I Checked Out
• Contracts 101 – Nolo Legal Basics
• LawPadi: Nigerian Contract Law Overview
•Upwork’s Contract Terms Summary

What Every Nigerian Techie Should Know About Business Law and IP

Goodluck Igbokwe — Mon, 14 Apr 2025 23:01:38 +0000

Hello world, Devs and Freelancers!
Today marks Day 1 of my 4-week journey into legal literacy for tech professionals. I’m sharing this series not as a lawyer, but as a developer who wants to stop being “legally blind” when it comes to contracts, IP rights, and platform policies.

So, What’s the Big Deal About Legal Literacy?

If you’re freelancing, building your own software, or launching a startup, you’re automatically playing in the legal arena—whether you know the rules or not. And in Nigeria, it’s especially important to understand how our local laws intersect with global expectations.

Today’s Focus: Business Law + IP Basics (Nigeria)

I focused on two main areas:
• Foundations of Nigerian Business Law
• The ABCs of Intellectual Property (IP)

Let’s break that down.

⸻

What is Nigerian Business Law?

Nigerian business law governs how individuals and organizations can form and operate businesses legally in the country. It covers everything from:
• Business Registration (via CAC – Corporate Affairs Commission)
• Types of Business Structures (sole proprietorship, partnership, LLC, etc.)
• Obligations under Contracts and Statutes
• Regulatory Compliance (e.g., tax, NDPR)

If you’re offering tech services and haven’t legally registered your business, you’re taking risks—both financially and legally.

Intellectual Property 101

Here’s what I learned about the three big categories of IP that affect tech folks:

a. Copyright
• Protects creative works: code, designs, articles, music, etc.
• In Nigeria, copyright is automatic once a work is created and fixed in a tangible form (e.g., your codebase).
• You can register with the Nigerian Copyright Commission, but it’s not compulsory.

b. Trademarks
• Protects brands and logos (think your startup name or app icon).
• Must be registered through the Trademarks, Patents and Designs Registry under the Federal Ministry of Industry, Trade, and Investment.

c. Patents
• Protect inventions and technical solutions.
• If you’ve built a novel algorithm, machine, or process, patenting might be the right move—but it’s complex and costly.

Quick Tips I Took Away
• Always read the fine print—from NDAs to platform terms.
• Register your brand as a trademark if you’re planning to scale.
• If you’re writing code for clients, clarify who owns the IP after delivery.
• When in doubt, Google isn’t a lawyer—but awareness is a start.

Tools & Resources I Found Useful
• Nigerian Copyright Commission
• Trademarks, Patents and Designs Registry
• Nigerian Law School Notes on Business Law

What’s Next?

Tomorrow, I’ll be diving into Contracts 101—the parts of a valid contract, common pitfalls, and what every freelancer should look out for.

Have you ever had an IP or legal issue in your freelance journey? Let’s talk in the comments.

Hello Dev.to, I’m Here to Build & Learn!

Goodluck Igbokwe — Wed, 05 Feb 2025 07:54:44 +0000

👋 Hey Dev.to Community!

I’m super excited to finally join this amazing space where developers share, learn, and grow together. My name is Goodluck Igbokwe, and I’m a backend-focused full-stack developer with a passion for building scalable applications, APIs, and solving real-world problems with code.

🚀 My Tech Journey

Like many self-taught developers, my journey started with @cs50_harvard_, where I got my first deep dive into programming. From that moment, I knew tech was where I belonged. I gradually transitioned into backend development, working with:

✅ Python (Django, Flask, FastAPI)
✅ PHP (Laravel & WordPress)
✅ RESTful APIs & Database Management
✅ Git, CI/CD, and Deployment Strategies

Over time, I’ve worked on projects ranging from web apps to API integrations, and I’m constantly learning and improving.

💡 What You Can Expect from My Blog

I’ll be sharing:
• Insights & Lessons from my journey as a backend developer.
• Hands-on tutorials on Django, Fask, FastAPI, and Laravel.
• Debugging & problem-solving strategies (aka the things I wish I knew earlier).
• Real-world backend development experiences from internships & projects.
• Tips on freelancing & career growth in tech.

🌍 Let’s Connect!

I’d love to engage with fellow devs, exchange ideas, and learn from you all. Feel free to drop a comment, connect with me, or suggest topics you’d love to see! 🚀

🔗 Follow me on Twitter:
🔗 GitHub: (https://github.com/mantle-bearer/)
🔗 LinkedIn: (https://www.linkedin.com/in/mantle-bearer)

Let’s build, debug, and grow together! 💻🔥 #dev #learn #unlearn #relearn