DEV Community

Cover image for The 3 Hardest Decisions I Make as a Dev (That Have Nothing to Do with Code)
William Trindade
William Trindade

Posted on

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

Why trendy technology matters less than professional maturity

I've been a programmer since 2019. On the technology timeline, this might seem like little to some or an eternity to others. But in these years, I've seen the landscape change dramatically: the cryptocurrency hype, the rise and fall of "revolutionary" frameworks every six months, and now, the AI explosion.

However, looking back and analyzing my trajectory, I notice something curious: the most critical decisions I made had nothing to do with the tech stack.

It wasn't about choosing between React or Vue, nor about using Python or Go. The decisions that truly defined my career and the quality of my work were, in fact, mindset shifts. They were moments when I needed to set aside the "passionate coder" to make room for the "product professional."

Here are the three biggest decisions I constantly have to make that shaped who I am as a developer.

1. Deciding which problem to solve (The Product Dilemma)

There's an inconvenient truth that haunts any programmer who loves what they do: we like writing code, but writing code isn't always what the product needs.

The first major decision I learned to make was putting technical choices in second place.

In the beginning, the temptation is always to solve the most interesting technical problem: refactor that legacy module, implement an ultra-complex architecture, or optimize a function that runs in milliseconds. But 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 postpone the ideal architecture or choose the most straightforward solution to quickly validate a business hypothesis. Accepting that product vision should lead technical passion is painful but necessary — as long as "simple" means clear and maintainable, not sloppy.

The lesson: Code is just a means to an end. The decision not to program the perfect solution, but rather the necessary one, is what separates juniors from seniors. And here's the paradox: simplicity doesn't mean sloppiness. The simplest solution is often the hardest to find — it requires technical mastery to avoid obvious pitfalls while resisting the temptation of unnecessary complexity. Long-term vision is knowing when to be pragmatic without being negligent.

2. Deciding when to ask for help (The Ego Balance)

This is a daily and treacherous decision. When you get stuck on a complex task, the clock starts ticking against you.

There's a fine line — almost invisible — between being persistent and being stubborn.

  • If you ask for help too early, it seems like you didn't try hard enough or that you're "desperate."
  • If you wait too long, you're burning company money and procrastinating on 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 rack my brain. If there's 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 — transforms a moment of weakness into a demonstration of responsibility.

3. Deciding "How long will this take?" (The Art of Estimation)

Perhaps the most dreaded question in any daily standup or planning: "How long will this task take you?"

Answering this isn't a guess; it's a commitment decision.

In the beginning, I decided on deadlines based on the perfect scenario, where no bugs would appear and I wouldn't be interrupted. Spoiler: that scenario never exists. The decision here involves managing expectations. It's deciding to include a safety margin for the unknown.

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

Conclusion

Technologies change. The language we use today might be obsolete in 2030. But the ability to prioritize the product, the humility to manage your own time by asking for help, and the responsibility to make realistic commitments are future-proof skills.

These were my three biggest decisions. What are yours?

Top comments (0)