The 3 Hardest Decisions I Make as a Dev (That Have Nothing to Do with Code)

Source: Dev.to

Deciding Which Problem to Solve (The Product Dilemma)

There is an inconvenient truth that haunts any programmer who loves their craft: we love writing code, but writing code isn’t always what the product needs.

The first major decision I learned to make was to put technical choices in the background. In the beginning, the temptation is always to solve the most technically interesting problem—refactoring a legacy module, implementing an ultra‑complex architecture, or optimizing a function that runs in milliseconds. In the real world, the hardest decision is looking at the backlog and asking:

“Does this bring real value right now?”

Sometimes the right decision is to do something technically “boring” or simple to validate a business hypothesis quickly. Accepting that product vision must lead technical passion is painful, but necessary.

Lesson

Code is just a means to an end. The decision not to program the perfect solution, but rather the necessary solution, separates juniors from seniors.

An Important Distinction

Delivering a solution that isn’t “perfect” does not mean falling into basic engineering errors, like writing bad code or creating complex, unreadable logic. Actually, the simplest solution is often the hardest one to find. This ability to simplify while maintaining long‑term quality distinguishes developers with vision from those without it.

Deciding When to Ask for Help (Balancing the Ego)

This is a daily and treacherous decision. When you get stuck on a complex task, the clock starts ticking against you. There is a fine line—almost invisible—between being persistent and being stubborn.

• Ask too soon: it can look like you didn’t try hard enough or that you are “desperate.”
• Wait too long: you burn the company’s money and procrastinate delivery.

The decision to raise your hand and say “I’m stuck” requires swallowing your pride. I learned to make this decision based on timeboxing: I give myself a fixed amount of time to crack the problem; if there is no progress, I ask for help.

It’s not about incompetence; it’s about efficiency. Knowing how to ask for help the right way—explaining what you’ve already tried and what your hypothesis is—turns a moment of weakness into a demonstration of responsibility.

Deciding “How Long Will This Take?” (The Art of Estimation)

Perhaps the most dreaded question in any stand‑up or planning meeting: “How long will this task take you?”

Answering this is not a guess; it is a decision of commitment. In the beginning I set deadlines based on a perfect scenario—no bugs, no interruptions. Spoiler: that scenario never exists. The decision here involves managing expectations by including a safety margin for the unknown.

Deciding on a deadline is, in reality, deciding on the level of quality and scope you can deliver in a given time. I learned that it is better to promise a longer deadline and deliver early than to try to impress with a short deadline and have to explain a delay later.

Conclusion

These were my three biggest decisions. What are yours?