The Questions I Wish I Asked Before I Start Coding
How understanding your data early saves time, money, and rework
When I first started building systems, I had a very simple mindset:
“Just make the feature work.”
So I did.
After one sprint, I built a table that displays data from an API. It worked. I felt great.
Then the next sprint came.
“Hey, the columns need to be dynamic.”
Alright—no problem. I refactored it. Still felt good.
Next sprint:
“Oh, by the way, this dataset is also used by another tool.”
Okay… now I had to rethink things. I ended up creating a working copy—users edit that, then merge it back into the original. More work, but still manageable.
Then, near the end of the project, things started slowing down.
Some datasets took forever to load.
At this point, I couldn’t just “fix it.” Most of the logic was already baked into the UI. Changing it meant major rework.
And then came another issue—saving data took too long.
So I added background processing.
At this point, I realized something.
None of these problems were random.
They were all predictable.
And I had been reacting to them… one sprint at a time.
The real problem?
I didn’t understand the data.
If I had known the data was dynamic, I would’ve designed the table that way from the start.
If I had known the data would be shared across tools, I would’ve planned for a safer editing flow—like a working copy.
If I had known the data would grow large, I wouldn’t have pushed all the logic into the UI. I would’ve used server-side pagination early on.
If I had known saving would involve large operations, I would’ve designed it with background processing from day one.
Instead, I learned all of this the hard way:
Through rework.
Through delays.
Through “quick fixes” that weren’t actually quick.
So if you’re building something right now, here’s a simple mindset shift:
Don’t just ask, “How do I build this feature?”
Ask:
“Is the data dynamic?”
“Who else uses this data?”
“How big can this get?”
“Will users perform bulk updates?”
Because features can be built in many ways…
But your understanding of the data will determine whether your system scales—or breaks later.
If there’s one thing I’d tell my past self, it’s this:
You’re not just building features.
You’re designing around data.
And the earlier you understand it, the less you’ll have to rebuild later.
A good software engineer isn’t just great at building features—it’s someone who knows how to ask smart questions.
The kind that seem simple at first, but when you think about them deeply, reveal hidden complexity.
Those questions are where the real value is—because they save you time, reduce rework, and prevent wasted resources.