Narrative is a feature : Why engineers should care about storytelling
How the technical prowess works hand-in hand with the ability to translate it into the business side | ✨ Dev Shorts #17
A quick note before we dive in: This article was written in collaboration with Alexandru Dragoi, who is beginning his journey in copywriting. Alex transformed my ideas and experiences into this article, while I added my personal touch through the story from the second paragraph about the live search feature and the moment I couldn't explain my own code.
You'll probably see Alex's name on future articles too, as we'll be collaborating more. 😊
When I started learning programming, I was quickly introduced to lots of specific terms revolving around the industry - programming languages, UX/UI, frontend, backend, databases etc.
I began by reading their definitions and writing code, or, using the industry-specific tools - similar to what an online course would require their students as a starting point.
Pointing my focus solely on these areas, my technical skills improved a lot. The code performance increased, the UI became more appealing and I was starting to feel like a prodigy.
Little did I know that my code lacked notes, undocumented features and more importantly, I could not reproduce in words what the code did, when compiled.
If you’re thinking about what was missing, the response is simple - the narrative.
The technical part is important, but …
During the years, the technical architecture of an application remained it’s stepping stone.
It acts like a foundation, and similar to a house foundation, if not built properly, the whole structure will sustain damages, going forward.
Therefore, it is important to choose the correct technical stack and tools.
But here is where it gets interesting. The technical realm is full of flavors - different backend programming languages, SQL vs NoSQL databases or even eye-popping frontend frameworks. I have always found that the best technical stacks are the ones molded on the application’s concept design, in accordance to the business needs.
A solid stack will always outperform untested tools in performance, security, scalability and maintainability.
Choose the wrong stack, skip the planning, and the cracks show up later, usually at the worst time.
I still believe that. But I also used to think that was the whole job.
Get the architecture right, and the rest follows.
But it just doesn’t.
The feature that worked in the demo
I once built a live search feature for a table with millions of rows.
Every keystroke fired a request to the backend, searching server-side in real time. No debounce, no throttling - just search, immediately, on every character typed.
It worked when I tested it. Type a few letters, get a match, done.
What I hadn’t accounted for was what happens at that scale, under real usage. With no delay between requests, a single fast typer could fire off a dozen searches before the first one even returned. The backend queued up faster than it could respond. Responses slowed, then stalled, and the UI sat there waiting on all of it.
That was the first problem. The second one showed up separately, in pagination.
The results were paged using offset-based pagination - page 1, page 2, and so on, calculated fresh each time. But the underlying dataset kept changing while people searched and scrolled through it. Rows got added, rows got removed. A user paging through results could skip rows entirely, or see the same one twice, because the “next page” was never a fixed slice of data - it was a moving target.
Two different mistakes. One from not slowing down the requests, the other from not accounting for a dataset that doesn’t hold still.
Product and design needed to understand what was going on. I sat down to explain it.
And I couldn’t.
I knew what the code was doing. I didn’t know how to say, in plain terms, why typing faster made everything slower, or why two unrelated bugs were showing up in the same feature at the same time.
My manager stepped in and walked them through it in a way I hadn’t managed to.
That’s when I realized - knowing the code and being able to narrate it kept turning out to be two different skills, and I kept assuming the first one was enough.
Storytelling matters more
The narrative of an application creates the storytelling and is usually the answer to two questions: how does this work, and why does it exist.
It looks like a soft skill. In practice, it’s the thing that lets technical and non-technical teams stand in the same room and mean the same thing.
Without it, a product owner hears “the search doesn’t scale” and has no way to act on that. With it, they hear “every keystroke is hitting the backend, so past a certain number of rows we need to search differently - maybe debounce it, maybe move some of it client-side” - and now there’s a decision to make.
This led me to understand that translating the technical parts of an application into layman terms is truly important, but somehow still overlooked.
With the adoption of AI, an engineer’s storytelling and communication skills are vastly improved by interacting with it.
Whether presenting a new feature or explaining raw data, a good storytelling provides context and the stakeholders are presented justifiable and clear action paths.
Since AI lowers the technical burden, engineers will have to focus more on enhancing their story-telling skills, as project resources are increasingly harder to justify, while making themselves stand out from the competition, with a seasoned skillset.
Until next time,
Stefania
Articles from the ♻️ Knowledge seeks community 🫶 collection:
https://stefsdevnotes.substack.com/t/knowledgeseekscommunity
Articles from the ✨ Dev Shorts collection:
https://stefsdevnotes.substack.com/t/frontendshorts
Articles from 🚀 The Future of API Design series:
https://stefsdevnotes.substack.com/t/futureofapidesign
🗣️ If this article resonated with you
If this article resonated with you, consider recommending Stef’s Dev Notes to someone who might enjoy it.
This newsletter grows mostly through thoughtful readers sharing it with others in the industry and I really appreciate every recommendation.
 | A guest post by
|
That example with the search feature felt familiar.
I've found it's one thing to explain what the system does. Explaining why it behaves that way, especially to people making product decisions, is much harder.
During my early years on the team, it was mostly developers talking to developers. With all the technical jargon flying around, I often found myself struggling to make sense of the bugs being discussed.
That's when I realized how important storytelling is, even in engineering. It became a natural muscle to build. Being able to explain the problem, the context, and the "why" behind it saves everyone a lot of time. Otherwise, so much of the conversation is spent just getting everyone to the same level of understanding, especially when people come from different tech stacks or domains.