Engineer First focusing on what really matters in software development

A reflection on priorities in software development

I’d like to share a thought I’ve been having about software engineering, how tech companies prioritize tasks, and how I would do things if I could decide.

The current pace: rushing, with little room for technical excellence

It’s no secret that building software has turned into a rush of code. What matters is having it running and shipping more and more features. The role of a software engineer often comes down to opening and closing tasks. Teams rarely have time to think about quality or technical excellence. There’s no time to implement a proper testing pyramid or build a solid solution. Teams just do what they can within the time they have.

Does this really create value?

The core of a tech company is the software, but my impression is that most companies don’t really care about the software itself. I don’t know if there are studies on this, but I keep wondering how much a new feature really attracts new users or retains existing ones. Is this rush really worth it?

What I believe is a healthier path

I believe that a well-built, well-tested, technically solid, smooth and bug-free product gets much more attention than one with a bunch of average features.

The model I’d follow: Engineer First

If I had the chance to decide, I’d adopt an “engineer first” model, where the focus would be on engineering, architecture, and quality above all. Features would always be delivered with technical excellence, even if it took more time. Engineering would have a stronger voice in setting priorities and deadlines. Product features would only be considered priority 0 if they were truly urgent.

A view that goes against the grain

This might go against what most companies believe today, but in my opinion, it’s a much more mature, sustainable, and efficient model.