DEV Community: Chizurum Chidimma Enyinnaya

How to Turn Your Technical Knowledge Into Content That Gets You Noticed

Chizurum Chidimma Enyinnaya — Sat, 15 Aug 2026 19:34:19 +0000

The overlooked skill that separates engineers who stay invisible from the ones who become industry references

Technical skill has never been the scarce resource. Every year, thousands of developers, engineers, data scientists, and technical specialists graduate, get certified, or teach themselves enough to become genuinely good at what they do. What's scarce is the ability to take that knowledge and make it visible to the people who need it. I've watched brilliant engineers get passed over for opportunities that went to people with half their skill but twice their visibility, and it took me a long time to understand why that keeps happening.

The truth is uncomfortable but simple: nobody can hire you, fund you, follow you, or trust you for expertise they don't know you have. Your GitHub commits don't speak for themselves to a hiring manager who never opens GitHub. Your production incident that you fixed at 2 a.m. doesn't build your reputation if the only people who know about it are your team. Knowledge that stays locked inside your head or buried in internal documentation is knowledge the market can't reward.

Content is the bridge between what you know and what the world can see. But most technical people either avoid writing about their work entirely, or they write in a way so dense and jargon-heavy that only five people on earth understand it, and none of them are hiring managers, potential clients, or future collaborators. This article is about closing that gap: turning the things you already know how to do into content that actually gets you noticed, without dumbing yourself down or turning into someone you're not.

Why Technical People Struggle With This More Than Anyone Else

There's an irony in technical fields. The people with the most valuable knowledge are often the least equipped, psychologically, to talk about it in public. A few reasons show up again and again.

First, technical training rewards precision over communication. You're taught to write code that compiles, not paragraphs that persuade. Nobody grades you on how relatable your explanation of a caching strategy is. So when the moment comes to write publicly, the instinct is to default to precision at the cost of accessibility, and the result reads like documentation nobody asked for.

Second, there's a quiet fear of being wrong in public. Technical fields have sharp edges. Someone will always know more than you about some subset of what you just explained, and the internet is full of people ready to point that out. So many skilled people stay silent because the risk of a correction feels heavier than the reward of visibility.

Third, and this one matters more than people admit, technical people often assume their knowledge isn't special. If you've spent years around other engineers who all know the same things you know, it's easy to believe the whole world already knows it too. It doesn't. What feels basic to you is a revelation to someone three years behind you on the same path, and that person is exactly who your content should be reaching.

I think about this a lot because I work with founders and technical professionals who have genuinely rare expertise sitting completely dormant, simply because they never learned that explaining what you know is its own skill, separate from and just as valuable as knowing it in the first place.

Start With What You Actually Struggled With

The instinct when turning technical knowledge into content is to write about what you've mastered. That's backwards. The content that gets noticed almost always comes from what you struggled with, not what came easily.

Think about the last hard problem you solved. Maybe it was a race condition that took three days to trace. Maybe it was migrating a legacy system without downtime. Maybe it was explaining a technical tradeoff to a non-technical stakeholder who kept pushing back. Whatever it was, the struggle is the story. The mastery is just the resolution.

People don't connect with your competence directly. They connect with the journey toward it. A post that says "here's how caching works" is a tutorial competing against a thousand other tutorials. A post that says "I spent two days debugging a cache invalidation issue that turned out to be a single misplaced TTL value, and here's what I learned about assuming your abstractions are correct" is a story with a lesson, and stories get remembered in a way that pure information doesn't.

This is where personal voice earns its place. Not by manufacturing a dramatic narrative around something ordinary, but by being honest about the version of the problem you actually lived through. I've noticed that the technical writers who build the strongest followings aren't the ones with the most impressive resumes. They're the ones willing to say "I got this wrong before I got it right," because that's the sentence that makes a stranger trust you.

Translate, Don't Simplify

There's a difference between simplifying your knowledge and translating it, and confusing the two is where a lot of technical content goes wrong.

Simplifying often means stripping out the substance until what's left is so generic it could apply to anything. Translating means keeping the substance intact while changing the language it's wrapped in, so a wider audience can actually follow the logic without losing the value.

If you're writing about a distributed systems concept, simplifying might mean reducing it to "computers talk to each other and sometimes it's hard." That's not useful to anyone. Translating means keeping the actual mechanics, the actual tradeoffs, the actual reasons things break, but explaining them through an analogy or a story instead of through pure jargon. You're not removing the technical truth. You're building a ladder so more people can climb up to it.

One habit that helps enormously here is writing two versions of the same explanation in your head before you commit words to the page. First, explain it the way you'd explain it to a colleague who already knows the field. Then explain it the way you'd explain it to a smart friend who has never touched the technology. The content worth publishing usually lives somewhere between those two versions: rigorous enough that your peers respect it, clear enough that outsiders can follow it.

This matters because your audience is rarely just other experts. Even in deeply technical fields, the people making hiring decisions, funding decisions, or partnership decisions are often adjacent to the technical work, not embedded in it. A recruiter reading your post about system design doesn't need to reproduce your architecture. They need to walk away thinking, "this person clearly knows what they're talking about, and I understood every word of it." That combination, credibility plus clarity, is what gets you remembered.

Use Your Actual Work as Raw Material

You don't need to invent content ideas. Your actual work, the tickets you close, the bugs you chase, the decisions you argue for in meetings, is already full of material. The problem isn't a shortage of ideas. It's that most technical people don't recognize their daily work as content-worthy because it feels too ordinary to them.

Every code review you've done contains an opinion about how software should be built. Every architecture decision you've made contains a tradeoff someone else is currently wrestling with. Every time you've had to explain a technical concept to a non-technical person, you've already done the translation work that content requires; you just didn't write it down afterward.

Start keeping a running list, even a rough one, of moments from your actual work that made you think something worth sharing. Not polished insights. Just raw moments: the time you disagreed with a teammate about a design pattern and later realized you were wrong, the time a "quick fix" took down a service for twenty minutes, the time you finally understood why a senior engineer kept pushing back on your approach. These moments, written honestly, become some of the most compelling content you can produce, because they're specific in a way that generic advice never is.

Specificity is what makes technical content credible. Anyone can write "communication is important in engineering teams." Almost nobody can write the exact conversation where a miscommunication about API contracts cost a team three days, and what changed in how they wrote documentation afterward. The second version is the one people share, because it proves you actually did the thing you're talking about.

Pick a Format That Matches How You Actually Think

Not every technical person should be writing long threads on X, and not every technical person should be publishing long-form essays. Part of getting noticed is choosing a format that lets your natural way of thinking come through, rather than forcing yourself into a shape that feels foreign.

Some people think in systems and sequences. If that's you, long-form writing, where you can build an argument step by step, will probably feel more natural than short-form content that demands you compress everything into a single punchy insight. Others think in sharp, isolated observations. If that's you, threads or short posts that deliver one clear idea at a time will likely serve you better than trying to stretch a single observation into 2,000 words it doesn't need.

There's also the format of teaching directly: tutorials, breakdowns, walkthroughs. This works particularly well for technical people because it plays directly to existing strength. You already know how to explain a process step by step; you do it constantly for junior engineers, for documentation, for onboarding. The only shift required is doing it publicly instead of internally, and being willing to add your own perspective on why the process works the way it does, not just the mechanical steps.

Whatever format you choose, consistency matters more than perfection. A slightly rough post published every week will build more recognition than a polished essay published once every three months. Visibility compounds. One piece of content rarely gets anyone noticed. Twenty pieces of content, consistently showing the same thread of expertise, absolutely will.

Let Your Opinions Show

This is the part most technical people resist, and it's the part that matters most.

Technical writing is often trained to be neutral. Present the facts, list the options, let the reader decide. That instinct serves documentation well. It kills content. Content that gets noticed almost always has a point of view embedded in it, even when it's teaching something objective.

If you're writing about two competing approaches to a technical problem, don't just list their pros and cons and walk away. Say which one you'd choose and why. Say where you think the industry consensus is wrong. Say what you'd tell a junior engineer who came to you with the same question. The opinion is what makes the content yours instead of a repackaged version of the documentation anyone could have written.

I've noticed this pattern over and over: the posts that spread furthest are rarely the most technically exhaustive ones. They're the ones with a clear, sometimes slightly provocative stance that a large number of other technical people either strongly agree with or strongly want to argue against. Both reactions spread the content. Neutral, hedge-everything writing doesn't spread, because there's nothing in it worth reacting to.

This doesn't mean manufacturing controversy for its own sake. It means being willing to say what you actually think, based on what you've actually seen work and fail, rather than retreating into "it depends" every time a real question comes up. "It depends" might be technically true. It's also the fastest way to make your content forgettable.

Show the Thinking, Not Just the Answer

One of the most underused techniques in technical content is showing your reasoning process instead of just presenting the final conclusion. Most tutorials and explainers jump straight to the solution: here's the code, here's the config, here's the answer. What they skip is the part that actually builds trust, which is how you got there.

When you show your thinking, the false starts, the assumptions you had to abandon, the moment you realized you were solving the wrong problem, you're giving readers something far more valuable than the final answer. You're giving them a working model of how an experienced person approaches a problem. That's the thing junior professionals are desperately trying to learn, and it's the thing that senior professionals recognize and respect when they see it done well.

This also happens to be one of the fastest ways to differentiate yourself from AI-generated content, which is becoming harder and harder to tell apart from human writing at the level of pure information. A clean, correct explanation of how something works is something a language model can produce fairly convincingly now. A messy, honest account of the specific moment you were wrong, and the specific reasoning that got you to right, is much harder to fake, because it requires having actually lived through a real problem with real stakes.

Don't Wait Until You Feel Like an Expert

There's a belief that quietly stops a lot of good technical content from ever being written: the idea that you need to be an expert before you're allowed to talk about something publicly. This belief is almost always wrong, and it's worth examining closely because of how much damage it does.

Expertise is not a fixed threshold you cross and then unlock permission to speak. It's a spectrum, and the honest truth is that people find value in content from across the entire spectrum, not just from the top. A beginner explaining what they just learned is often more useful to other beginners than an expert's advanced take, because the beginner remembers exactly what was confusing and can explain the confusion in a way the expert, who's forgotten what it was like not to know this, can't replicate.

If you wait until you feel like a definitive authority before writing anything, you'll likely wait forever, because the feeling of being enough of an expert rarely arrives on its own. It arrives, if it arrives at all, after you've already been writing and teaching for a while and other people start treating you like an authority before you've fully accepted the label yourself.

The content that gets someone noticed is rarely the content of someone claiming to be the top voice in a field. It's the content of someone clearly further along than the reader, sharing honestly what they've learned along the way. That's an accessible position for almost anyone with real experience, regardless of how many years they've put in.

Build a Body of Work, Not a Single Viral Moment

It's tempting to chase the one post that blows up. Some technical professionals get lucky and one piece of content does put them on a much bigger stage overnight. But building recognition through a single viral moment is fragile, because algorithms reward it once and then move on, and the audience that found you through it often has no context for who you are or what you actually know.

What actually gets people noticed in a durable way is a body of work. A recognizable thread running through everything you publish, so that when someone stumbles onto one piece of your content, they can trace it back to a dozen others and start to understand the shape of your expertise. This is what turns a single reader into a follower, and eventually turns a follower into someone who recommends you to their own network without you ever having to ask.

Building a body of work requires patience most people underestimate. It means publishing when you don't feel like it, publishing pieces that get almost no engagement, and trusting that the pattern matters more than any individual post. The engineers and technical professionals who eventually become recognized names in their field almost never got there through a single breakout moment. They got there by showing up consistently long enough that their name became attached to a specific kind of insight, and that association is worth infinitely more than any single viral post.

The Real Shift

Turning technical knowledge into content that gets you noticed isn't about becoming a different kind of person, someone louder, more polished, more performative. It's about recognizing that the knowledge you already have is valuable enough to be worth sharing honestly, and that sharing it well is a skill separate from the technical skill itself, one you can learn the same way you learned everything else you're good at.

The engineers and technical professionals who get noticed aren't necessarily the smartest people in their field. They're the ones who decided their knowledge was worth putting into words, and then did the work of learning how to write those words in a way other people could actually understand and connect with. That's not a talent you're born with. It's a practice, built one honest, specific, opinionated piece of content at a time.

7 Things I Wish Someone Told Me Before I Started Working in Tech

Chizurum Chidimma Enyinnaya — Sat, 15 Aug 2026 19:30:25 +0000

A slightly late memo to my younger self, written from the other side of the learning curve

I walked into tech thinking competence was the whole game. Learn the tools, ship the work, get better every quarter, and the rest would sort itself out. Nobody handed me a manual for the parts that actually shape a career: the politics, the pacing, the quiet erosion of confidence that happens when you compare your rough draft of a career to everyone else's highlight reel. So this is the manual I didn't get. Some of it will sound obvious once you read it. It didn't feel obvious while I was living through it.

1. Being good at the work is not the same as being valued for it.

I used to believe that if I just did excellent work, recognition would follow naturally, like gravity. It doesn't work that way, and it took a few painful cycles of watching less rigorous work get louder applause before I understood why. Visibility is a skill. Communicating your impact is a skill. Advocating for your own contributions in a room where everyone else is doing the same is a skill. None of that is dishonest or self-serving; it's just how organizations actually function. People are busy, attention is limited, and nobody is tracking your effort as closely as you are. If you don't narrate your own value, someone else will narrate it for you, usually poorly, usually briefly, usually forgotten by the next quarterly review. I had to learn to write the update nobody asked for, to say "here's what this project actually solved" in a meeting instead of assuming the solving spoke for itself. It felt uncomfortable at first, almost like bragging. It wasn't. It was translation.

2. Imposter syndrome doesn't disappear with experience. It just changes outfits.

I thought imposter syndrome was a beginner's problem, something you'd age out of once you had enough years and enough proof behind you. What actually happens is that the bar keeps moving. You stop doubting whether you can do the junior version of the job and start doubting whether you can do the senior version, then the leadership version, then the version where you're the one making calls nobody can double check for you. The discomfort doesn't vanish. It relocates. What changed for me wasn't the feeling; it was my relationship to the feeling. I stopped treating self-doubt as proof I didn't belong and started treating it as a fairly reliable sign that I was doing something that mattered enough to be scary. Comfort and growth rarely show up in the same room.

3. Your technical skills have a shelf life. Your judgment does not.

Tech moves in a way that can feel disorienting if you tie your entire identity to a specific tool, framework, or platform. I watched people who were once considered irreplaceable experts in a technology scramble when that technology quietly fell out of favor, and I watched people who had built their reputation on judgment, on knowing how to ask the right questions, diagnose the real problem, and make sound decisions under uncertainty, remain valuable no matter what the landscape did underneath them. Learn the tools. Get fluent in them. But invest even more in the underlying muscle: how to think clearly when the information is incomplete, how to weigh tradeoffs, how to know which problem is actually worth solving. That muscle transfers. The specific software rarely does.

4. Burnout doesn't always look like exhaustion. Sometimes it looks like numbness.

I had a picture in my head of what burnout would look like: crying at your desk, dreading Monday, physically depleted. What I actually experienced was quieter and, in a way, more dangerous. I stopped feeling anything about the work at all. Projects that used to excite me became tasks to clear off a list. I was still performing well by every external measure, still hitting deadlines, still showing up on time, but something underneath had gone flat. It took me longer than it should have to name that as burnout because it didn't match the version I'd been warned about. If you find yourself going through the motions competently while feeling almost nothing, that's worth paying attention to. Numbness is not the absence of a problem. It's often the body's way of managing a problem it doesn't yet have the resources to feel.

5. The people you work with matter more than the mission statement on the website.

Every company will tell you about its culture during the interview, and almost none of that language will predict what your actual day-to-day experience is like. What predicts it is your manager, your immediate team, the handful of people you talk to most. A brilliant mission with a manager who doesn't advocate for you is a miserable place to work. A modest, unglamorous project with a team that trusts you and has your back can be one of the best professional seasons of your life. I stopped weighing job offers primarily by brand name or by how exciting the product sounded and started asking sharper questions about the actual humans I'd be reporting to and working alongside. That single shift in what I prioritized changed the quality of my working life more than any raise ever did.

6. Saying no is a career skill, not a character flaw.

Early on, I said yes to almost everything, convinced that agreeableness was the fastest route to being seen as a team player. What actually happened was that I became the person everyone routed extra work to, precisely because I never pushed back. Saying yes to everything doesn't make you indispensable. It makes you available, which is a different and much less valuable thing. Learning to say "I can take this on, but it means this other thing slips" or simply "that's not something I can prioritize right now" didn't damage my reputation the way I feared it would. If anything, it sharpened it. People started trusting my yes more, because they knew it wasn't automatic.

7. Nobody is coming to hand you a five-year plan. You have to write your own.

I spent my first couple of years waiting for some external structure to tell me what came next: a formal path, a mentor with a map, a manager who would lay out the next five moves for me. That structure rarely exists, and where it does exist, it's usually built around the company's needs, not yours. The people I've watched build genuinely fulfilling careers are the ones who took ownership of their own direction early, who asked for the stretch project instead of waiting to be offered it, who treated their career as something they were actively authoring rather than something happening to them. Nobody else is going to care about your trajectory as much as you do, and once I accepted that fully, I stopped waiting for permission and started building the plan myself.

If I could hand this list to the version of me who was nervous on her first day, unsure if she belonged in any of the rooms she was walking into, I think it would have saved her some unnecessary suffering. Not all of it. Some lessons only land when you've lived through the version that hurts. But maybe it would have shortened the distance between struggling silently and understanding that almost everyone around her was navigating some version of the same uncertainty, just quietly, just alone, just like she was.

AI Coding Is Easy. Knowing What to Build Is the Hard Part.

Chizurum Chidimma Enyinnaya — Sat, 15 Aug 2026 08:12:51 +0000

The real bottleneck was never syntax. It was judgment.

I spent an entire weekend last month watching someone build a fully functional app in about four hours. Authentication, database, clean UI, deployed and live before dinner. A year ago, that same build would have taken a small team two weeks and a lot of arguments about architecture. Now it takes an evening and a decent prompt.

This is the part of the AI coding story that gets repeated everywhere: the barrier to entry has collapsed. Writing code, once a skill that took years to develop, can now be outsourced to a model that spits out working functions in seconds. And that part is true. But it's also the least interesting part of what's actually happening.

Because after watching dozens of builds like that one, I noticed something. The bottleneck never moved to the code. It moved to something upstream of the code entirely. It moved to the question nobody was asking clearly enough before they started typing: what, exactly, are we building, and why?

The New Skill Isn't Technical

For most of software's history, the scarce resource was execution. If you had an idea, the gap between idea and working product was measured in months, sometimes years, and filled with people who understood compilers, frameworks, and the thousand small decisions that turn a concept into functioning software. That scarcity shaped everything. It shaped who got to build things (mostly people with years of training), how ideas got validated (slowly, expensively, often too late), and what got built at all (whatever survived the gauntlet of technical feasibility).

AI coding tools didn't just make that process faster. They removed the gate entirely. Someone with zero programming background can now describe an app in plain language and watch it materialize. This is genuinely remarkable, and I don't think enough people sit with how strange it is that this is normal now.

But removing the execution gate didn't remove the need for judgment. It just exposed how much judgment mattered all along, because now it's the only thing standing between a good product and a fast, confident, well-built version of the wrong product.

What "Knowing What to Build" Actually Means

This phrase gets thrown around so often it's started to sound like a platitude, so let me be specific about what it actually involves, because it's not vague vision or "having a great idea."

It's the ability to sit with a vague, itchy problem long enough to understand its actual shape before reaching for a solution. Most problems people bring to a build session aren't the real problem. They're a symptom wearing the real problem's clothes. Someone says "I need a dashboard" when what they actually need is a decision made faster once a week. Someone says "I need an app for my community" when what they actually need is a way to stop losing track of who paid dues. The dashboard and the app are downstream of a need that was never interrogated.

It's the discipline to define what "done" looks like before building, not after. Vague success criteria produce vague products. If you can't say what the thing needs to do, for whom, and how you'll know it worked, no amount of AI assistance will save the build. The model will happily generate exactly what you asked for, which is often not what you needed.

It's the willingness to say no to features that sound useful but dilute the core function. This used to be a natural filter, because every feature cost real engineering time, so scope stayed tight by necessity. Now that features are nearly free to generate, that natural filter is gone. Nothing stops a build from sprawling into a dozen half-useful directions except a person deciding, deliberately, what the product is not.

It's understanding the person on the other end of the product well enough to predict what they'll actually do with it, not what they say they'll do with it in a survey. This is the part no model can do for you, because it requires sitting with real humans, watching how they behave, and noticing the gap between their stated preferences and their actual habits.

None of these are coding skills. They're closer to journalism, or therapy, or product strategy. They involve listening, questioning assumptions, and tolerating ambiguity long enough to find the real shape of a problem before rushing to solve it.

Why This Feels Personal to Me

I've spent years in a different craft that runs on the exact same principle, and it's part of why this shift doesn't surprise me at all.

Writing looks, from the outside, like the hard part is putting sentences together. It isn't. Anyone can string words into grammatically correct sentences, and now AI can do that faster than any of us. The actual work of writing, the work that makes something worth reading, happens before a single sentence gets typed. It's figuring out what the piece is actually trying to say. It's knowing which of the seventeen interesting angles is the right one for this audience, this moment, this purpose. It's having enough judgment to cut the parts that sound smart but don't serve the piece.

I've watched people mistake "I can produce a lot of text quickly" for "I know how to write well," and the gap between those two things is enormous. It's the same gap now opening up in software. Producing code quickly is not the same as knowing what code deserves to exist.

What strikes me most is how familiar this feels. The tools change. The underlying skill that actually separates good outcomes from mediocre ones doesn't move an inch. It just gets more exposed, because all the old excuses (I don't have time, I don't have the technical skill, building this would take too long) have been stripped away. What's left is a clearer view of whether someone actually understood the problem they were solving.

The Uncomfortable Part

Here's what nobody wants to say out loud: a lot of people are going to build a lot of things very quickly over the next few years, and most of it will be built with more confidence than clarity. Speed doesn't correct for a bad premise. It just gets you to the wrong answer faster and with better production values.

I've seen this already. A founder builds an entire onboarding flow in a day, beautifully designed, technically solid, and completely wrong because nobody spent thirty minutes talking to an actual user first. A team ships a feature nobody asked for because the AI made it trivial to add, not because anyone checked whether it solved anything. The tools didn't fail. The judgment upstream of the tools did.

This isn't an argument against using AI to build. I use these tools constantly and I think anyone avoiding them at this point is making a mistake. It's an argument for taking the thinking part more seriously now, not less, precisely because the building part demands so little friction anymore. When something is hard to do, the difficulty itself forces a kind of discipline. You think twice before committing two weeks to a build. Remove that friction and the discipline has to come from somewhere else. It has to come from you, deliberately, before you open the tool.

What This Actually Rewards

The people who will get the most out of this moment aren't the ones who learn to prompt the fastest. They're the ones who get sharper at the questions that come before any prompt gets typed. What problem am I actually solving. Who is this for, specifically, not generally. What does success look like in a way I could measure, not just feel. What am I choosing not to build, and why.

Those questions were always the hard part. They were just easier to skip when the technical work absorbed all your time and attention anyway. Now there's nothing left to hide behind. The thinking is the whole job.

AI made building fast. It didn't make knowing what's worth building any easier, and honestly, I don't think it ever will. That part was never about tools. It was always about paying close enough attention to the actual problem, and having the patience to sit with it before rushing toward a solution.

Why Every Developer Should Learn How to Write

Chizurum Chidimma Enyinnaya — Sat, 15 Aug 2026 08:09:12 +0000

The best code in the world means nothing if you can't explain what it does

I have spent years editing technical writing for founders, engineers, and product teams who build genuinely brilliant things and then struggle to describe them in a way anyone outside their own head can follow. This is not a rare problem. It is the default state of most technical teams, and it costs them more than they realize: slower onboarding, confused stakeholders, documentation nobody trusts, and code reviews that turn into arguments because nobody wrote down the reasoning in the first place.

Writing is not a soft skill bolted onto engineering as an afterthought. It is a core part of the job, and the developers who treat it that way tend to outpace the ones who don't, even when their raw technical ability is identical.

The gap between knowing and explaining

Every editor who has worked with technical clients has a version of this story: a developer sends over documentation for a feature they built themselves, and the writing is nearly incomprehensible. Not because the developer is careless. Because building something and explaining something are two entirely different cognitive tasks, and most engineering education spends all its time on the first one and almost none on the second.

When you write code, the compiler or the interpreter forces precision on you. Skip a semicolon, misname a variable, forget to close a bracket, and the thing simply does not run. You get immediate, unforgiving feedback. Writing has no compiler. You can produce a paragraph that looks complete, that took real effort, and that says almost nothing useful to the person reading it. Nothing stops you from shipping unclear writing the way something stops you from shipping code that won't build.

This is exactly why the skill has to be learned deliberately. It will not develop as a side effect of getting better at engineering. I have watched senior engineers with a decade of experience write commit messages and pull request descriptions that are genuinely worse than what a junior engineer produces, simply because nobody ever told them writing was something to practice.

What writing actually does for a developer

Writing forces you to think in a straight line. When you're deep in a codebase, your understanding of a system can be tangled, associative, full of context that lives only in your head: the three failed approaches you tried before landing on this one, the edge case you remembered from a bug two years ago, the tradeoff you made without fully articulating it even to yourself. Code doesn't require you to untangle any of that. It just requires the final logic to work.

Writing does require you to untangle it. A clear paragraph forces you to decide what actually matters, in what order, and why. Engineers who write regularly, whether that's documentation, design docs, or even just detailed commit messages, tend to think more clearly about their own systems, because the act of writing keeps exposing the parts of their reasoning that were fuzzy.

I have edited enough design documents to know the moment when a writer realizes, mid-sentence, that the architecture they were about to defend doesn't actually hold together. That realization almost never happens while coding. It happens while writing, because writing is where hidden assumptions get dragged into daylight.

The documentation nobody reads and why that's a writing problem

Bad documentation isn't usually bad because the writer didn't know the subject. It's bad because the writer wrote for themselves instead of for the reader. This is the single most common failure I see in technical writing: a document that makes perfect sense to the person who already understands the system, and almost no sense to anyone else.

Good technical writing requires imagining a reader who does not share your context. It requires deciding what to explain and what to assume, and getting that judgment right is genuinely hard. Too much explanation and experienced readers feel patronized and skim past the parts that actually matter. Too little and newer readers are lost by paragraph two. Developers who write well have usually built an internal sense for this balance, and it shows up not just in their docs but in their code reviews, their Slack messages, and the way they onboard new teammates.

I've built a career around helping people say clearly what they actually mean, and the pattern I keep running into with technical clients is a kind of quiet frustration. They know their subject better than almost anyone. They've solved hard problems. And then they sit down to write about it and the words come out stiff, defensive, over-explained in the wrong places and rushed in the right ones. It's not a confidence problem. It's that writing is a distinct craft, and craft takes deliberate repetition, the same way debugging or system design does.

What strikes me every time is how fast this improves once someone actually treats it as a skill instead of an afterthought. Not months of practice. A few genuine attempts at rewriting something with a specific reader in mind, and the improvement is visible. The barrier isn't ability. It's that almost nobody tells developers this is worth their deliberate attention, so it stays in the category of things they'll "get better at eventually," which in practice means never.

Where this shows up beyond documentation

The developers who write well have an advantage that extends past their commit history. Pull requests get approved faster when the description actually explains the reasoning instead of just listing the diff. Bug reports get resolved faster when they're written with enough precision that someone else can reproduce the issue without three follow-up questions. Promotion cases, especially at companies that value written communication, often come down to whether an engineer can articulate their impact in a document, not just point at a dashboard.

There's also a less obvious benefit: writing well makes you a better reader of other people's code and documentation. Once you've had to make hard choices about what to include and what to cut, you start noticing those same choices, good and bad, in what other people write. You get faster at spotting the design doc that's hiding a real problem behind vague language, or the code comment that's technically accurate but explains the wrong thing.

How to actually get better at it

This isn't about becoming a novelist. It's about a handful of habits that compound.

Write the plain-language version first. Before writing a technical explanation, try writing one sentence that describes what the thing does as if to a smart colleague on a different team. If you can't do that, you don't yet understand the thing as well as you think you do.

Read your own writing out loud. Awkward sentences reveal themselves fast when spoken. So do sentences that are doing three jobs at once when they should be doing one.

Cut the sentence that explains how you feel about the problem and keep the sentence that explains the problem. Technical writing gets weighed down by hedging and justification. State what happened, why it matters, and what to do about it.

Ask someone outside the immediate context to read a draft. Their confusion tells you exactly where you skipped a step in your own head without noticing.

Treat commit messages and pull request descriptions as real writing, not throwaway text. They are read more often than almost anything else you produce, usually by people trying to solve a problem under time pressure, which makes clarity there worth more than it looks.

The actual case for learning this

Code communicates with machines. Writing communicates with people, and people are the ones who decide whether your code gets used, maintained, funded, or understood at all. A brilliant system explained badly gets misused, abandoned, or rebuilt from scratch by someone who never understood why it was built that way in the first place. A mediocre system explained clearly gets adopted, trusted, and improved by people who actually understand what they're working with.

Learning to write isn't a detour from engineering. It's the part of engineering that makes the rest of it matter to anyone but you.

Why Developer-Focused Content Still Needs Good Storytelling

Chizurum Chidimma Enyinnaya — Fri, 14 Aug 2026 14:45:58 +0000

The best technical writing doesn't just explain code. It makes readers feel something about the problem it solves.

I spent years believing that developer content had to be dry to be credible. Clean, clinical, stripped of anything resembling emotion or narrative flourish. If it read like a textbook, it must be serious work. If it made you feel something, it probably wasn't technical enough.

I was wrong, and it took a specific afternoon of reading two different API documentation pages back to back to understand why.

The first was a wall of endpoints, parameters, and status codes. Accurate. Complete. Forgettable within the hour. The second walked me through a real problem a developer had faced at 2 a.m., the wrong turns they took before finding the right pattern, and why the solution mattered beyond just making the error go away. Same technical depth. Completely different experience. I remembered the second one for months. I still reference it when I explain the concept to other people.

That contrast changed how I think about writing for technical audiences.

The Myth of the Purely Rational Reader

There's a persistent assumption in developer marketing and technical content circles that engineers and developers are immune to narrative. That they want facts, benchmarks, and code samples, and nothing else. That story is decoration for people who don't understand the technology well enough to explain it plainly.

This assumption misunderstands what storytelling actually does.

Storytelling isn't about adding drama to a changelog. It's about giving information a shape that a human brain can hold onto. Developers are still humans, even the ones who insist otherwise in their Twitter bios. They still forget information presented as disconnected facts faster than information presented as a sequence with cause and effect. They still trust a source more when it acknowledges the messy reality of building software instead of pretending every implementation goes smoothly on the first try.

I've edited enough developer-facing content to notice the pattern clearly. The pieces that get bookmarked, shared internally on Slack, and referenced months later almost always have one thing in common: they treat the reader's problem as a story with a beginning, a struggle, and a resolution, not just a list of steps.

What Storytelling Actually Looks Like in Technical Writing

This isn't about inventing fictional narratives around your API reference. Good storytelling in developer content usually looks like:

Starting with the failure state, not the feature. Instead of "Our SDK supports rate limiting," a stronger opening acknowledges the pain first: what happens when a team doesn't have proper rate limiting, what that failure costs them, and why it's a problem worth solving before introducing the solution.

Showing the decision, not just the outcome. When you explain why a piece of architecture works a certain way, include the alternative you didn't choose and why. That single addition turns a flat explanation into a case study. Readers learn more from seeing a decision made than from seeing only the decision's result.

Using specific, real scenarios instead of generic placeholders. "Imagine you're processing 10,000 events per second and your queue starts backing up during a traffic spike" lands harder than "when handling high volume." Specificity is a storytelling tool. It makes abstract concepts feel like something the reader has actually lived through, or fears living through.

Letting some tension exist before the resolution. A tutorial that says "this might not work the way you expect, and here's the exact moment it breaks" builds more trust than one that pretends the path was smooth. Readers know pain points exist. Naming them earns credibility.

None of this requires abandoning precision. The best technical storytelling is still exact about function signatures, still correct about edge cases, still rigorous about the details that matter to someone shipping code. Story and accuracy aren't in competition. They're doing different jobs in the same piece.

Why This Matters More as AI Tools Flood the Space

Something has shifted over the past couple of years that makes this conversation more urgent rather than less.

A huge volume of developer content now reads identically because a huge volume of it was generated the same way, with the same tools, prompted for the same structure. Feature explanation, code sample, closing summary. Competent. Accurate. Interchangeable with a thousand other pieces covering the same topic.

In that environment, the content that still has a distinct point of view, a human decision behind every choice, and a story that couldn't have come from anywhere else becomes disproportionately valuable. Not because it's less useful technically, but because it's harder to skim past and forget.

I've watched this play out with clients directly. The documentation, guides, and thought leadership pieces that get the most engagement now aren't the ones with the most comprehensive feature lists. They're the ones written by someone who clearly built the thing, broke the thing, fixed the thing, and is willing to walk you through that whole arc instead of just the polished ending.

I didn't come into content strategy through engineering. I came into it through editorial and storytelling work, which meant my early attempts at writing for technical audiences were, honestly, overcorrected in the other direction. I leaned so hard into narrative that I sometimes buried the actual technical substance a developer reader needed to trust the piece.

It took real feedback from developers themselves, blunt comments like "this is a nice story but I still don't know how to implement it," to find the actual balance. The lesson wasn't that storytelling was wrong for this audience. It was that storytelling has to serve the technical content, not replace it. A developer reading a guide wants to feel like someone who understands their specific frustration wrote this, and also wants to leave with working code. Both things have to be true at once.

That balance is harder to strike than pure technical writing or pure narrative writing on their own. It requires actually understanding the technology deeply enough to know which details matter, and caring enough about the reader's experience to shape those details into something they'll remember. Doing both well is rare, which is exactly why it stands out when someone manages it.

The Practical Case, Beyond the Emotional One

If the human argument doesn't move you, the business case will.

Content that developers remember gets referenced when they're evaluating tools, gets shared in team channels when a colleague hits the same problem, and gets cited in Stack Overflow answers and internal wikis long after publication. Content that reads like every other explanation of the same feature gets read once, if that, and forgotten by the time the reader closes the tab.

Developer trust is also earned differently than trust with other audiences. Developers are unusually good at detecting when someone is padding a piece with unnecessary jargon to sound credible, or oversimplifying to the point of being technically wrong. Storytelling done well signals the opposite: that the writer actually sat with the problem long enough to have opinions about it, made real decisions, and is being honest about what worked and what didn't.

That kind of honesty, delivered through a clear narrative arc instead of a flat list of specs, is what turns a piece of content into something a reader trusts enough to act on.

Where This Leaves Developer Content Going Forward

Technical accuracy will always be the floor, not the ceiling. Nobody trusts a beautifully written piece that gets the implementation wrong. But accuracy alone no longer differentiates anything, because accuracy is now table stakes that even automated tools can produce at scale.

What differentiates developer content going forward is the same thing that has always differentiated good writing in any field: whether it was shaped by someone who understood not just what to say, but why the reader needed to hear it in that particular order, with that particular tension, arriving at that particular resolution.

Good storytelling was never about making technical content less technical. It was always about making it land.

The Difference Between Technical Writing and Content That Actually Sells

Chizurum Chidimma Enyinnaya — Fri, 14 Aug 2026 14:42:14 +0000

Why knowing your subject isn't the same as knowing your reader

I once spent three days editing a piece for a SaaS founder who knew his product better than anyone alive. He could explain the architecture, the API integrations, the exact reason his tool outperformed six competitors on latency. The draft he sent me was technically flawless. Every sentence was correct. And every sentence was also a reason someone would close the tab.

That draft taught me something I now repeat to almost every client who hands me a brief: being right is not the same as being persuasive. Technical writing and content that sells look similar on the surface. Both use words. Both explain things. Both, in theory, want the reader to understand something. But they are built on different instincts, and confusing the two is one of the most expensive mistakes a founder, consultant, or coach can make with their content.

Two different jobs wearing the same clothes

Technical writing exists to remove ambiguity. A user manual, an API doc, a compliance guide, these all succeed when there is exactly one way to interpret them. The goal is precision. If a reader has to guess what a sentence means, the writer has failed.

Content that sells exists to move someone from indifferent to invested. It doesn't just inform, it makes a case. It has to survive contact with a distracted human scrolling on their phone at 11pm, half-convinced they don't need whatever you're offering. Precision alone won't do that. You need rhythm, tension, a reason to keep reading past the first line.

I think of it this way: technical writing answers the question "what is this?" Content that sells answers the question "why should I care?" A lot of smart people only ever learn to answer the first question, and then they wonder why their brilliant, accurate content gets zero engagement.

Where the confusion usually starts

Most of the founders and experts I've worked with over the years didn't grow up thinking of themselves as writers. They grew up thinking of themselves as engineers, consultants, operators, specialists. When it comes time to write a LinkedIn post or a newsletter, their brain defaults to the mode that got them through years of documentation, reports, and specs: be accurate, be complete, be neutral.

That instinct is not wrong. It's just misapplied. A pitch deck is not a spec sheet. A newsletter is not a changelog. When someone writes marketing content the way they'd write a technical brief, the piece ends up thorough and lifeless. It respects the facts and ignores the human reading them.

I've edited hundreds of drafts with this exact problem. The information is all there. The structure is logical. But there's no pulse. No moment where the reader feels something shift in them, curiosity, recognition, urgency. That pulse is the entire difference.

What content that sells actually does differently

It starts with a person, not a feature. Technical writing often opens with the object: "This platform offers three integrations." Content that sells opens with the person: their frustration, their late-night worry, their specific bad day. The feature shows up later, as the answer to something the reader already feels.

It uses tension on purpose. A spec sheet avoids friction. It states facts in order. Persuasive content creates a small gap, a problem named clearly enough that the reader recognizes it as their own, and then closes that gap with the solution. That gap is what keeps someone reading instead of skimming.

It sounds like a person, not a department. Technical writing is often written in a passive, institutional voice because that voice signals objectivity. But objectivity doesn't build trust with a stranger on the internet. Specificity does. A sentence with a real detail, a real number, a real moment, does more work than three sentences of polished generality.

It knows what to leave out. This is the one I have to teach most often. Technical writing tends to be exhaustive because completeness is the point. Content that sells is selective because attention is the scarce resource. Every sentence has to earn its place by moving the reader closer to caring, not just closer to being informed.

It has a shape, not just a structure. A technical document is organized by category. A persuasive piece is organized by momentum, an opening that hooks, a middle that builds, an ending that asks for something. Readers don't finish content because it's well organized. They finish it because each line makes them want the next one.

A personal admission

I'll be honest about something. Early in my writing career, I thought clarity was the whole job. If I explained something correctly, that should be enough. I used to hand in drafts that were clean, accurate, and completely forgettable, and I couldn't understand why clients kept asking for something with "more energy" or "more personality." I thought they wanted fluff. What they actually wanted was a reason to feel something.

It took years of editing other people's work, and getting brutally edited myself, to understand that clarity is the floor, not the ceiling. You need it. But it isn't what makes someone stop scrolling, or reply to a cold email, or buy a product they were on the fence about. What moves people is recognition. The sense that the person writing understands something true about their situation before making any kind of ask.

That shift changed how I write everything, from a two-line hook to a full ebook. I still care about accuracy. I still fact-check, still tighten sentences, still cut anything vague. But now every piece of content I write has to do two jobs at once: be true, and be felt.

Why this distinction matters more than ever

Content is louder and more abundant now than it has ever been. Anyone can generate a technically correct paragraph about almost anything in seconds. That means correctness alone has stopped being a differentiator. What still separates the content people remember from the content people scroll past is the same thing it always was: whether the writer understood the reader well enough to make them care.

This is especially true for founders, consultants, and coaches who are trying to build authority online. Their audience isn't reading to be educated in a vacuum. They're reading to decide whether this person is worth trusting with their time, their money, or their problem. A technically accurate post won't decide that. A post that makes someone feel understood will.

The real skill isn't writing well. It's translating well.

The best content sits at the intersection of the two. It's accurate enough to be credible and human enough to be felt. That combination is harder than either extreme on its own. Anyone can write dry and correct. Anyone can write emotional and vague. The rare skill is holding both at once, being right about the facts and right about the reader, in the same sentence.

If your content has been getting polite engagement but no real movement, no replies, no clients, no traction, it might not be a topic problem or an algorithm problem. It might be that you're writing like someone documenting a product instead of someone making a case for it.

If you want content that does both, holds up to scrutiny and actually moves people to act, that's the exact work I do every day for founders, coaches, and B2B companies who need writing that sells without sounding like a sales pitch. I've spent nearly a decade turning technically sound ideas into content people actually stop for. If you're ready for writing that works this hard for you, reach out at chizurumchidimma2000@gmail.com or connect with me on LinkedIn at linkedin.com/in/chizurumenyinnaya.

7 AI Coding Mistakes Developers Keep Making

Chizurum Chidimma Enyinnaya — Thu, 13 Aug 2026 16:44:07 +0000

Why the smartest tool in your stack still needs a skeptical human behind it

I review a lot of code that didn't start as code. It started as a prompt. And most of the time, you can tell. Not because the output is bad, AI assistants write clean, readable, often elegant code, but because of what's missing around it: the questioning, the edge case paranoia, the "wait, what happens if this input is empty" instinct that experienced developers build over years of getting burned.

AI coding tools have earned their place in the workflow. They compress hours of boilerplate into minutes, help junior developers ship faster, and turn debugging sessions that used to eat an afternoon into a five minute back and forth. But convenience has a way of dulling vigilance, and I keep seeing the same handful of mistakes surface across teams, projects, and skill levels. None of them are about the AI being bad at its job. They're about how developers use it. Here are seven worth paying attention to.

1. Treating AI Output as a Finished Product

AI generated code has a particular kind of confidence to it. It's formatted well, commented generously, and often runs on the first try. That surface polish is exactly what makes it dangerous to trust blindly.

A function can compile, execute, and pass a quick manual check while still failing on a null value, an empty array, or a timezone edge case nobody thought to test. The code looks done. It rarely is.

Treat every AI generated block the way an editor treats a first draft: a starting point, not a submission. Someone still needs to trace through the logic and ask whether it holds up outside the one scenario it was tested against.

2. Copy-Pasting Code Without Understanding It

There's a particular kind of risk in shipping code you can run but can't explain. It happens constantly: a developer pastes in a working solution, sees it succeed, and moves on without tracing through why it succeeded.

The cost shows up later, usually in production, usually at the worst time. If you don't understand the logic, you can't debug it efficiently when it breaks. You end up back in the chat window asking the AI to fix its own code, and sometimes it does, and sometimes it just layers a new guess on top of the old one, because the model doesn't remember why it made the original choice any better than you do.

Understanding the code you ship isn't a nice to have. It's the actual job.

3. Skipping Tests Because the Code "Looks Right"

AI generated code is persuasive. Clean syntax and sensible variable names create an illusion of correctness that has nothing to do with whether the logic is actually sound.

Developers who would never skip tests on hand written code will happily skip them on AI written code, because it feels like someone else already vetted it. Nobody did. The model generated the most statistically likely answer to your prompt, not a verified one.

Unit tests, edge case tests, and a quick manual walkthrough aren't extra steps for AI generated code. They're the minimum.

4. Feeding the AI Vague or Incomplete Prompts

Ambiguous input produces ambiguous output, and developers often blame the tool for a problem that started with the prompt. "Write a function to handle user data" invites the AI to guess at validation rules, error handling, data types, and edge cases, and it will guess, confidently, without flagging the uncertainty.

Specificity does the heavy lifting here: expected input format, what should happen on failure, what the function should not do. A vague prompt gets a vague answer wearing the outfit of a precise one.

5. Not Checking for Outdated or Deprecated Practices

AI models are trained on a snapshot of the past, and code that was best practice at that snapshot isn't always best practice now. Deprecated libraries, outdated security patterns, and abandoned framework conventions show up in generated code more often than developers expect, especially in fast moving ecosystems like JavaScript frameworks or mobile development.

Cross check anything touching security, authentication, or a library's public API against current documentation before it ships. "It worked" and "it's current" are different claims.

6. Ignoring Security Implications

AI assistants optimize for working code, not necessarily secure code, unless explicitly prompted to think about security. That gap shows up in generated code that concatenates SQL queries instead of parameterizing them, skips input sanitization, or hardcodes credentials in a config file meant for version control.

None of this happens out of malice. The model is answering the question it was asked, and "make this work" and "make this safe" are not the same question. Security review has to be a deliberate, separate pass, not an assumption baked into the first output.

7. Losing the Skill of Solving Problems From Scratch

This one is quieter than the rest, and slower to show up. Developers who lean on AI for every problem, including the small, solvable ones, start to lose the muscle memory of working through logic independently. It's the coding equivalent of never doing mental math because a calculator is always in your pocket.

The skill doesn't vanish overnight. It erodes gradually, in the gap between problems you could have solved yourself and problems you immediately outsourced. That erosion matters most in the moments AI can't help: an outage at 2 a.m., an interview whiteboard, a codebase with no internet access.

The fix isn't avoiding AI. It's staying deliberate about which problems you hand off and which ones you still work through yourself, on purpose, even when the shortcut is sitting right there.

AI coding tools aren't the problem. Passive trust in them is. The developers getting the most out of these tools aren't the ones using them least, they're the ones who never stopped reading the code, questioning the logic, and treating every generated line as a draft that still needs a second opinion. The tool got smarter. That's exactly why the human behind it can't afford to get lazier.

Why Your AI-Generated Code Keeps Breaking

Chizurum Chidimma Enyinnaya — Thu, 13 Aug 2026 16:38:19 +0000

The gap between "it works" and "it works reliably" is wider than most developers think

I spent an entire weekend last year debugging a script that an AI model had written for me in under ten seconds. The irony wasn't lost on me. What should have saved me hours ended up costing me more time than if I'd written the thing from scratch, and the worst part was I couldn't figure out why it kept failing in ways that felt almost random. One run it worked perfectly. The next run, same input, same environment, it threw an error I'd never seen before.

That weekend taught me something about AI-generated code that no tutorial had prepared me for: the code that looks correct and the code that actually is correct are not the same thing, and the distance between them is where most of your debugging hours go.

The illusion of completeness

AI models are excellent pattern matchers. When you ask for a function that sorts a list or a script that scrapes a webpage, the model draws on millions of examples of similar code and produces something that resembles a correct solution. The syntax is usually clean. The logic often looks sound. It compiles, it runs, it might even pass your first few tests.

But "resembles correct" and "is correct" diverge exactly where it matters most: at the edges. What happens when the list is empty. What happens when the webpage structure changes. What happens when two requests hit the same resource at the same time. These edge cases rarely appear in the training data the same way core logic does, so the model's confidence about them is often unearned. It will write handling for a null value with the same fluency it uses to write the happy path, even when that handling is wrong.

Context windows aren't memory

Here's something I didn't understand for a long time: an AI model doesn't hold your entire codebase in its head the way a human developer builds a mental model of a project over weeks. It sees what's in its context window at that moment, and nothing more. Ask it to modify a function in one file without showing it how that function is used in three other files, and it will happily make changes that break those other three files. It isn't being careless. It genuinely doesn't know they exist.

This is why AI-generated code tends to work in isolation and fail in integration. A snippet tested alone in a sandbox behaves differently than the same snippet dropped into a live system with existing state, existing dependencies, and existing assumptions about how data flows. The bugs that show up aren't usually about bad syntax. They're about broken assumptions the model had no way of knowing it was making.

Version drift is a silent killer

Libraries change. APIs deprecate methods. Frameworks release breaking updates. An AI model trained on data up to a certain point can confidently generate code using a method that was standard eighteen months ago and has since been replaced. The code looks fine. It reads like something a competent developer would write. It just doesn't work with the version of the library you actually have installed.

I've lost count of how many times I've seen a script fail with an error about a missing attribute, only to trace it back to a library update that happened after the model's training data ended. This isn't a flaw you can code around easily. It's a structural reality of how these models are built, and it means every piece of AI-generated code that touches an external dependency needs a version check before you trust it.

The confidence problem

What makes all of this harder to catch is tone. AI-generated code doesn't come with hesitation. There's no comment saying "I'm not fully sure this handles concurrent writes correctly" even when that uncertainty exists under the hood. The model presents a solution with the same fluency whether it's handling a trivial case or making an educated guess about something genuinely ambiguous.

Human developers, when unsure, tend to leave a trail: a comment, a TODO, a question in a pull request. That trail is often missing in AI output, which means the burden of finding the weak points shifts entirely onto whoever is reviewing the code. If you're not reviewing closely, you inherit the model's confidence without inheriting its blind spots.

What actually helps

None of this means AI-generated code is unusable. It means it needs to be treated as a first draft from a very fast, very well-read junior developer who has never actually run your specific project before. A few things have genuinely changed how much time I lose to this:

Testing edge cases explicitly, not just the obvious path, since that's where the model's pattern matching is weakest
Giving the model as much surrounding context as possible, including how a function is called elsewhere, not just what it should do in isolation
Checking library versions before trusting any code that imports something external
Reading the code line by line instead of just running it, because fluent syntax can hide faulty logic

The code breaking isn't usually a sign that the tool failed you. It's a sign of where the tool's limits actually sit, and once you know where those limits are, the debugging gets a lot less mysterious.

I Tried Building a Website With AI From My Phone

Chizurum Chidimma Enyinnaya — Wed, 12 Aug 2026 21:36:43 +0000

What happened when I decided a laptop wasn't a requirement anymore

It started on a Tuesday night, the kind where I was lying in bed with my phone propped against a pillow, scrolling through other people's beautifully designed personal sites and feeling that familiar itch. I didn't have a laptop with me. I had a phone, a data plan, and a growing impatience with the idea that "real" building requires a desk, a mouse, and hours of uninterrupted focus.

So I asked myself a question I hadn't taken seriously before: could I actually build a website, from scratch, using nothing but my phone and an AI tool to guide me through it?

I decided to find out.

The decision that felt small until it wasn't

I've spent years writing for other people, shaping their ideas into words that sell, persuade, and build trust. But my own website had been sitting in my head for months, half-planned, fully imagined, never built. Every time I thought about starting, I pictured myself hunched over a laptop for a weekend, wrestling with code I didn't fully understand.

That image kept the project stuck in "someday."

What changed wasn't a burst of motivation. It was smaller than that. I simply opened a chat window on my phone and typed out what I wanted: a warm, editorial site with a navy and gold palette, serif headings, clean body text, something that felt like it belonged to a writer who takes her work seriously but doesn't take herself too seriously.

I wasn't sure it would work. I half expected to hit a wall within the first twenty minutes.

The first real surprise

The first thing that struck me wasn't the code. It was how much the process resembled a conversation with a collaborator who happened to know things I didn't. I described what I wanted in plain language, the way I'd explain a vision to a designer over coffee. The AI translated that into structure: components, layout logic, color tokens, typography choices.

I didn't write a single line of code myself. I typed sentences. Full ones, with feeling in them. "I want the header to feel like the opening line of a good essay, not a billboard." And somehow, that instruction turned into something real on the screen.

Typing on a phone for something this technical should have been miserable. It mostly wasn't. Voice-to-text carried a lot of the weight, and when I did type by hand, the back-and-forth was short enough that my thumbs didn't rebel.

Where it got hard

I won't pretend it was seamless the whole way through. There were moments where what appeared on screen didn't match what I had pictured. A section that should have felt spacious came out cramped. A shade of gold that looked warm in my head rendered too loud on the small screen.

Each time, I had to do the thing I do professionally for other people but rarely do for myself: name exactly what wasn't working and why. Not "this looks wrong," but "this section feels too tight, give it more breathing room, and pull the gold back so it reads as an accent instead of a shout."

That precision mattered more than I expected. Vague feedback got vague results. Specific feedback, the kind I'd normally reserve for a client brief, got me exactly what I was picturing.

There was also the plain physical strain of building something visual on a six-inch screen. Previewing layouts, checking spacing, judging whether a heading felt balanced against the paragraph below it, all of that asked more of my eyes and patience than I expected going in.

The part that surprised me most

Somewhere around the third or fourth round of edits, I stopped thinking of this as a technical experiment and started thinking of it as an act of authorship. I wasn't managing software. I was directing something, the way I'd direct a piece of long-form writing, paragraph by paragraph, until the shape of it matched the shape in my head.

That reframing changed how I approached the rest of the build. I stopped asking "can AI build a website" and started asking "what do I actually want this space to say about me and my work." The tool was never really the hard part. Knowing what I wanted, clearly enough to describe it, was the actual work.

I think that's true of most creative collaborations, human or otherwise. The tool amplifies clarity. It doesn't manufacture it.

What it felt like when it finally looked right

There was a specific moment, late at night again, when the homepage finally matched what I'd been carrying in my head for months. Navy background settling into itself, gold catching the eye without overwhelming it, the serif headings giving the whole thing a quiet, literary confidence.

I sat with that for a while before doing anything else. Not editing, not tweaking, just looking at it. It felt less like I'd finished a task and more like something I'd been describing to people for months had finally stopped being an idea and started being a place.

I built that from my bed, in fragments, between other parts of my day, using a phone I also use to answer emails and scroll through news I probably shouldn't read before sleeping.

What I'd tell someone considering this

If you're waiting for the "right setup" before you start building something you care about, I'd gently push back on that instinct. The barrier was never really the laptop. It was the belief that building requires a certain kind of environment, a certain kind of expertise, a certain kind of permission.

What actually got the job done was clarity, patience, and a willingness to describe what I wanted in painfully specific terms instead of vague hopes. The phone was just the surface I happened to be holding when I stopped waiting.

I still don't think a phone is the ideal tool for this kind of work. There are moments where a bigger screen and a proper keyboard would have saved me real time. But it proved something I needed proving: the excuse of not having the "right" setup was mine to let go of, and I finally did.

The site exists now. Navy and gold, serif and quiet confidence, built in pieces from a bed I wasn't planning on leaving that night. Some things start smaller than you expect, and turn out bigger than you thought they could.

Can a Writer Build a Tech Career Without Becoming a Programmer?

Chizurum Chidimma Enyinnaya — Wed, 12 Aug 2026 21:24:58 +0000

Why the industry needs people who can translate, not just people who can code

I never learned to code. I tried once, years ago, working through a beginner's Python course at 1 a.m. because someone on Twitter said every serious professional should "at least understand the basics." I got through variables and loops before I gave up and went back to what I actually knew how to do: write sentences that made complicated things feel simple.

For a long time, I treated that as a gap in my resume. Like I was standing outside a building I'd never be let into, watching people in hoodies talk about APIs and deployment pipelines while I sat somewhere in the lobby with my notebook. It took years of actually working inside tech companies, not as an engineer but as the person who explained what the engineers built, to realize the lobby was never a lesser place to be. It was just a different room with a different job.

The Industry Runs on More Than Code

Every tech company, no matter how technical its product, eventually has to explain itself to a human being. A SaaS platform needs onboarding emails that don't sound like a terms-of-service agreement. A founder needs a LinkedIn post that makes their Series A announcement sound like news instead of a press release. An AI company needs someone to write the blog post that explains, in plain language, why their new feature actually matters to a person who has never heard of a large language model and doesn't care to.

That work is not adjacent to tech. It is tech. Products don't sell themselves on functionality alone; they sell on clarity, trust, and story, and those are things engineers are rarely trained to build. Somebody has to sit at the intersection of "I understand what this technology does" and "I understand what a human being needs to hear in order to care," and that somebody is very often a writer.

What Changed for Me

I started writing for tech and AI companies almost by accident. A founder needed a newsletter. Then another needed thought leadership content that made him sound less like a spreadsheet and more like a person with convictions. Somewhere in the process of ghostwriting for people who understood their product better than they understood their audience, I stopped thinking of myself as someone borrowing space in the tech world and started thinking of myself as infrastructure for it.

That shift mattered more than any technical skill I could have picked up. I learned enough about SaaS metrics, product launches, and AI capabilities to speak the language fluently, without ever needing to build the thing myself. I learned to read a product roadmap the way an editor reads a manuscript: looking for what's missing, what's unclear, what a reader will trip over. The technical fluency came from proximity and curiosity, not from a bootcamp certificate.

The Skills That Actually Transfer

A writer building a career in tech doesn't need to learn to code. What they need is the willingness to get uncomfortably specific about a subject they didn't grow up in. That means reading documentation even when it's dry. Sitting in on product meetings and asking the "dumb" question because if you don't understand it, the end user probably won't either. Learning the vocabulary well enough to use it correctly, even if you'll never write it into a codebase.

Curiosity does most of the heavy lifting. So does the discipline to turn complexity into something someone can read in under two minutes and actually retain. Tech companies are drowning in jargon and starving for translation. A writer who can sit between the engineering team and the end user, converting one language into another without losing meaning, is doing work that no LLM has fully replaced and no engineer particularly wants to do themselves.

The Insecurity Doesn't Fully Go Away

I'd be lying if I said the imposter feeling disappeared completely. There are still rooms where I'm the only person who can't speak to system architecture, and there's a specific kind of quiet that settles over me in those moments, the instinct to shrink a little, to qualify my opinions before I've even given them. But I've noticed something over time: the engineers in those rooms often can't write a sentence that makes a non-technical stakeholder care about their work. We need each other. Neither skill set is complete without the other.

The career I've built wasn't built by closing that gap between writer and programmer. It was built by refusing to see it as a gap that needed closing in the first place, and instead learning to stand in it, deliberately, as the place where the two worlds meet.

So, Can a Writer Build a Tech Career Without Becoming a Programmer?

Yes. Not despite being a writer, but because of it. The industry doesn't only need more people who can build the technology. It needs people who can explain why it matters, who can sit with an idea until it's simple enough to hold, and who can make a stranger on the internet feel like a piece of software was built with them in mind. That's not a lesser kind of tech career. It's a necessary one, and there's room in it for anyone willing to get specific, stay curious, and never stop treating clarity as a skill worth mastering.

You Don’t Need to Be a Developer to Contribute to Open Source

Chizurum Chidimma Enyinnaya — Tue, 11 Aug 2026 15:06:22 +0000

The people who make open source work aren't just the ones writing code. Some of them write the words that make the code make sense.

I spent years assuming open source was a closed door. Every time I opened GitHub, I felt like I'd wandered into a conversation being held in a language I hadn't studied. Pull requests, forks, issues tagged with words like "good first issue" that somehow still felt intimidating. I closed the tab more times than I can count, convinced that space belonged to people who could write functions, not people who could write sentences.

It took me longer than I'd like to admit to realize how wrong that assumption was.

The myth that keeps people out

Open source has a branding problem, and it's an ironic one for a movement built on collaboration. The public image is almost entirely code: commits, merges, terminals, lines of syntax scrolling past on a dark screen. That image is accurate, but it's incomplete. It leaves out the writers who make a tool's documentation actually usable. It leaves out the designers who turn a clunky interface into something people want to use. It leaves out the community managers who keep a project from imploding when a disagreement gets heated. It leaves out the translators, the testers, the people who write the first draft of a README at 11pm because nobody else got around to it.

If you've stayed away from open source because you don't code, you've been kept out by a myth, not a rule.

What non-developers actually do in these projects

Documentation is the most obvious entry point, and it's also one of the most needed. A huge number of open source projects are built by people who are excellent engineers and mediocre explainers. That's not a criticism, it's just a different skill. Someone can write brilliant code and still produce a setup guide that only makes sense to the person who wrote it. Projects need people who can sit with a piece of software as a genuine beginner would, notice where the instructions fall apart, and fix the gap in plain language.

Beyond documentation, there's a whole layer of work that rarely gets photographed for a conference slide. Bug triage, where someone reads through incoming issues, checks whether they're duplicates, and tags them so developers aren't wasting time sorting through noise. UX feedback, where someone walks through a new feature and reports honestly on where it confused them. Translation, which opens a tool up to entire regions of the world who were previously locked out simply because the interface only existed in English. Community moderation, which keeps a Discord or a forum from turning into a place people are afraid to post in. Project management, for the larger efforts that need someone tracking timelines and keeping contributors from working at cross purposes.

None of that requires a single line of code. All of it requires care, attention, and a willingness to show up consistently.

Why this work matters more than it gets credit for

I think about how many times I've abandoned an app or a tool because the documentation confused me, not because the product itself was bad. That's a loss for the people who built it, and it's a loss that a good writer could have prevented. Clear docs are often the difference between a project that grows a real community and one that stays a folder of code nobody outside the original team can use.

The same is true for design. A tool can be technically excellent and still fail because nobody thought about how a first-time user would actually move through it. And community management, maybe more than anything else, decides whether a project survives its own growth. Open source projects don't die from lack of talent nearly as often as they die from burnout, unclear expectations, and conversations that turned toxic because nobody was tending to them.

Every one of these problems is solvable by someone who has never opened a code editor.

How I actually started

My own way in was small and almost accidental. I found a project I genuinely used, a piece of open source software that had helped me with something in my own work, and I noticed its documentation had a section that was clearly unfinished. Half-written sentences. A step that assumed knowledge nobody starting out would have. I didn't ask anyone's permission first. I just wrote out what I thought the missing piece should say, opened an issue explaining what I'd noticed, and asked if a contribution would be welcome.

It was. The maintainer was, if anything, relieved. She told me later that she'd known the docs needed work for months but kept putting it off because writing wasn't where her strengths were, and every hour spent on documentation was an hour not spent fixing bugs. My small edit wasn't a grand gesture. It was maybe two hundred words. But it was two hundred words she didn't have to write herself, and that mattered more than I expected it to.

That was the moment the myth broke for me. I wasn't contributing in spite of not being a developer. I was contributing because I wasn't one. I saw the confusion a developer would have missed, precisely because I was reading it the way a stranger would.

Where to actually start, if you want to try this

Look for projects with labels like "good first issue" or "help wanted," but don't stop at the ones tagged for developers specifically. Many projects have separate labels for documentation or design work, and even more haven't bothered to label anything because nobody thought to ask.

Pick something you already use. This matters more than people expect. If you already understand what the tool is trying to do, you'll notice gaps faster and care more about closing them.

Start with something small. A typo fix. A confusing sentence rewritten. A missing step added to a setup guide. Small contributions build trust, and trust is what gets you invited into bigger work later.

Ask before you assume. Open an issue, describe what you noticed, and ask whether the maintainers would welcome help with it. Most will say yes immediately. Some projects even have contributor guides written specifically for non-coders, though you may need to dig for them.

Don't apologize for what you bring. I used to preface every offer to help with some version of "I'm not technical, but." I don't do that anymore. Being non-technical was the reason I could see the problem in the first place.

The part you don't know

Contributing to open source as a writer or designer or community person changes how you see the software you use every day. You stop seeing a finished product and start seeing a living, ongoing effort made by people, most of them unpaid, most of them doing it because they care. That shift in perspective is worth something on its own, separate from whatever you end up building or fixing.

It also changes how you see yourself. I no longer think of "technical" and "non-technical" as two separate worlds with a wall between them. I think of open source as one large, unfinished project that needs every kind of skill a person might bring to it. Somebody has to write the code. Somebody has to explain it. Somebody has to make it usable, welcoming, and clear enough that the next person doesn't feel the way I felt the first time I opened GitHub.

If that's you, closing tabs, feeling locked out, assuming the door was never meant for you, I'd just say this. The door was open the whole time. Nobody ever checked for a developer badge at the entrance.

5 AI Workflows That Can Save Developers Hours Every Week

Chizurum Chidimma Enyinnaya — Tue, 11 Aug 2026 14:57:59 +0000

Practical systems, not just prompts: how AI is quietly rewriting the developer's daily grind

I spent years watching talented engineers burn entire afternoons on tasks that had nothing to do with actual problem-solving. Writing boilerplate. Chasing down a bug that turned out to be a missing semicolon three files deep. Drafting the same kind of documentation for the fifth time that month. None of that is engineering. It's friction. And friction is exactly what AI tools have started to strip away, quietly and steadily, from the daily rhythm of software development.

What follows isn't a list of flashy AI gimmicks. It's a look at five workflows that developers are actually using right now to reclaim hours from their week, the kind of hours that used to disappear into repetitive, low-leverage work.

Code Review as a First Pass, Not a Final Judgment

Every developer knows the dread of opening a pull request with 40 files changed. Traditional code review means someone has to read every line, hold the entire logic of the change in their head, and catch subtle issues buried in the diff. That process is valuable, but it's also exhausting and slow.

AI-assisted code review tools now handle the first pass. They flag inconsistent naming, unused imports, missing error handling, and potential security issues before a human reviewer even opens the file. What used to take a senior engineer 45 minutes of careful reading can now take 10, because the obvious issues have already been surfaced. The human reviewer's time gets spent where it matters: architecture decisions, edge cases, and the kind of judgment calls a model still can't make reliably.

I think about this the way I think about editing written work. A first read for typos and structure is mechanical. The real value comes from the second read, the one focused on whether the argument actually holds together. AI has taken over the mechanical pass in code review, and that alone gives back hours every week.

Turning Vague Tickets Into Actionable Specs

Anyone who has worked on a product team knows the pain of a ticket that says "fix the login flow" with no other context. Developers used to spend half their morning tracking down the person who wrote it, asking clarifying questions, and reconstructing what the actual requirement was.

Now, AI tools can take a rough ticket, cross-reference it against existing documentation and previous related tickets, and generate a structured spec with acceptance criteria, edge cases to consider, and suggested implementation approaches. It's not perfect, and it still needs a human to confirm the details. But it collapses what used to be a 30-minute back-and-forth into a five-minute review. Multiply that across a sprint full of ambiguous tickets, and the time saved adds up fast.

Debugging With Context, Not Just Error Messages

Debugging has always eaten more time than developers like to admit. Pasting an error message into a search engine and sifting through outdated Stack Overflow threads used to be a rite of passage. It also used to waste hours.

AI debugging assistants now take in the actual context: the stack trace, the surrounding code, recent commits, even the specific framework version in use. Instead of generic advice, developers get a diagnosis that accounts for their actual codebase. Some tools go further, tracing the bug back through git history to identify the commit that likely introduced it. What used to be an afternoon of guesswork has, for a lot of teams, become a 15-minute conversation with a tool that actually understands the problem in front of it.

4 . Documentation That Writes Itself Alongside the Code

I'll be honest about this one, because it's the workflow that changed how I think about writing as a discipline separate from engineering. Documentation has always been the thing developers know they should do and rarely have time for. It gets postponed, then forgotten, then someone six months later is reverse-engineering a function because nobody wrote down why it exists.

AI tools that generate documentation directly from code, and update it automatically when the code changes, have quietly solved a problem that plagued software teams for decades. A function gets written, the tool drafts a clear explanation of what it does and why, and the developer edits rather than starts from scratch. That shift, from writing to editing, is where the real time savings live. Editing is almost always faster than staring at a blank page.

Test Generation That Covers the Cases You Forget

Writing comprehensive tests is one of those tasks every developer agrees is important and almost everyone under-invests in, usually because of time pressure. AI tools can now generate test suites directly from function signatures and existing code patterns, including edge cases a tired developer might not think to check at 6pm on a Friday.

This doesn't replace thoughtful test design. It replaces the tedious part: writing out the standard cases, the null checks, the boundary conditions. A developer can review and refine a generated test suite far faster than building one from nothing. Teams using this workflow report catching bugs earlier, simply because more edge cases get tested in the first place.

What This Actually Means

None of these workflows remove the developer from the loop. They remove the parts of the job that never needed a human mind in the first place. The pattern across all five is the same: AI takes the first pass, and the human brings judgment to what's left. That's a meaningful distinction, because it means these tools aren't replacing engineering skill. They're clearing the runway so that skill gets used where it actually counts.

I've watched people in creative and technical fields alike resist these tools out of a fear that using them means cutting corners. What I've noticed instead is the opposite. The developers saving the most hours each week are usually the ones who were already careful about their process. They just stopped spending that care on tasks that didn't need it.