5 min read
Naming things is the whole job, sometimes
Most codebases don't have a naming problem — they have a thinking problem that shows up in their identifiers.
← All writing
Software engineering20 posts
Software engineering
Full-stack engineering lessons from real builds — error messages, code review, databases, structure, and the habits that keep codebases alive.
Written by Nzubechukwu Cyprian — Pharmacy student at UNN, full-stack developer and AI builder.
5 min read
Your README is your first interview
Before anyone judges your code, they judge your README. What a good one actually contains, from someone who reads a lot of them.
4 min read
The bug that taught me to read error messages properly
A three-line error sat in my logs for a week. It told me exactly what was wrong. I just never read past the first line.
5 min read
CSS taught me more about engineering than I expected
Specificity, inheritance, and the cascade are systems thinking in disguise. Understanding CSS made my other code better.
5 min read
How I review my own code (and why you should too)
The cheapest code review available: you, twenty minutes later, with a checklist and no ego. It catches more than you'd think.
5 min read
Version control is a time machine — most people use it as a filing cabinet
Commits that tell a story, branches that hold experiments, and the confidence to delete things. Git rewards the curious.
4 min read
The environment variable that cost me a day
It worked on my machine, failed in production, and the difference was one missing string. Now I fail fast on purpose.
6 min read
Databases: the four mistakes I made so you don't have to
No indexes, no transactions, timestamps without timezones, and deleting without a backup. A field report.
6 min read
Learning a new framework in 48 hours
The method I use when a project demands a stack I don't know yet: transfer the concepts, skim the docs, build the smallest thing.
5 min read
Write code like the next reader is exhausted
The person debugging your code at 2am will be tired, under pressure, and possibly you. Optimise for that reader.
5 min read
The API design mistake that haunts every version
I leaked my database shape through my API, and now every internal change is a public breaking change. Don't do this.
6 min read
Why I stopped optimizing too early — a story in three builds
Build one: over-engineered and late. Build two: naive and fine. Build three: actually measured, actually fast where it mattered.
5 min read
Debugging with rubber ducks and logs: a solo developer's toolkit
No teammate to brainstorm with? These are the techniques that substitute: structured logging, bisection, and the duck.
5 min read
The case for boring technology in student projects
Your project's novelty budget is small. Spend it on the product, not the infrastructure — especially when exams exist.
6 min read
How I structure a Next.js project so it doesn't rot
Content as data, components as functions of data, and a folder layout that answers questions instead of raising them.
4 min read
What code review taught me about writing prose
Same skills, different medium: clarity, structure, knowing your reader, and killing your favourite sentence.
4 min read
The one-file rule for keeping side projects alive
If a side project can't be understood from one file after three months away, it's already dead. Design for your returning self.
5 min read
Types are documentation that can't rot
Comments drift, wikis gather dust, but a type error fires the day reality changes. TypeScript changed how I document.
5 min read
Deploying on Friday: a risk framework, not a superstition
'Never deploy on Friday' is a slogan. What you actually need is reversibility, monitoring, and an honest blast radius.
6 min read
Everything I know about software I first learned in a pharmacy lab
Precision, procedure, verification, and respect for failure modes: the lab is a systems engineering course in a white coat.