The best engineers I have seen are not just fast typers or framework experts.
They are good at reducing ambiguity.
That can mean different things depending on the situation:
- clarifying what the product actually needs,
- narrowing down the source of a bug,
- defining a clean API contract,
- or deciding what not to build.
Why this matters
Ambiguity slows teams down more than hard code does.
Once the real problem is clear, implementation usually becomes much easier. That is one reason I enjoy end-to-end work so much: it gives me more context, which makes ambiguity easier to remove.
What it looks like in practice
On Qifa, the product owner had a rough idea: a platform for salons. That description could mean hundreds of different things. Before writing a line of code, I had to work out: what does the order flow actually look like? Who accepts first? When does the user pay? What happens if the shop doesn’t respond in time?
Answering those questions was as much engineering work as building the features themselves.
Same with Open RTMS. “Real-time monitoring” sounds clear until you ask: real-time for whom? What latency is acceptable? Does detection need to run on the device or can it hit a server? Those answers changed the entire architecture.
The habit
I try to write the question down before starting. If I cannot write the question clearly, I do not fully understand the problem yet.
That sounds slow. In practice it saves far more time than it costs.