Development

What Developers Actually Want to Learn (And What They’re Ditching)

Your team wants to adopt a new framework. Great, you think. Innovation is good. Then you discover that half your developers hate the same tool the other half loves.

This isn't unique to your team. A recent survey from bol.com (via techlab.bol.com) asked 25 developers and five technology leaders about their technology preferences. The results reveal disagreement—not just preferences, but outright abandonment of tools that others consider essential.

What the Survey Found

The study asked three questions:

  • What technologies are you eager to learn?
  • What technologies from last year should we adopt?
  • What technologies did you move away from?

The answers varied widely. Some developers expressed enthusiasm for tools that others were actively abandoning. When researchers grouped responses by theme, they found overlap—but also sharp divergence across six categories: programming languages and testing frameworks, application frameworks, Java runtimes, cloud and data storage, tools and libraries, and general practices.

Why This Matters

Technology choices affect productivity, hiring, and long-term maintainability. When your team disagrees on tools, three problems emerge:

Cognitive load.** Juggling multiple frameworks—or context-switching between legacy and modern approaches—drains mental energy better spent on product work.

Knowledge silos.** Specialists in abandoned technologies become harder to replace. When they leave, they take institutional knowledge with them.

Hiring friction.** Candidates evaluate tech stacks during job searches. Mismatched expectations create turnover.

The Trap of Tech Tribalism

Tech communities develop strong opinions. Framework advocates dismiss alternatives. Language enthusiasts treat other choices as inferior.

The problem: these opinions often reflect familiarity rather than objective assessment. A developer who's mastered one tool will naturally prefer it. That doesn't mean it's right for your team.

The better approach: evaluate technologies against concrete criteria. What problem does it solve? How steep is the learning curve? What does the ecosystem look like? How does it fit with existing tools?

Who Should Care

Team leads and engineering managers:** You arbitrate technology decisions. When your team splits on a tool, you'll need criteria beyond personal preference to make calls that stick.

Individual contributors:** Your strong opinions might reflect your background rather than objective fit. Before advocating for a switch, consider what problems you're actually solving.

Tech leads and architects:** You're responsible for long-term maintainability. Track which tools people want to abandon—and plan migration paths before those tools become liabilities.

What to Watch

Teams will face increasing pressure to evaluate new tools versus deepening existing skills. The developers who adapt quickly may gain productivity advantages, but only if adoption doesn't create the fragmentation the survey reveals.

Key takeaways

  • Developer technology preferences vary widely, even within the same team.
  • Technology disagreements create cognitive load, knowledge silos, and hiring friction.
  • Evaluate tools against concrete criteria rather than community opinions.
  • "Best practice" is context-dependent—what works for others may not work for you.

Frequently asked questions

What did the bol.com developer survey reveal about technology preferences?

The survey of 25 developers and 5 technology leaders found significant variation in which technologies people wanted to learn versus abandon. Even popular tools had detractors who were moving away from them.

Why do development teams often disagree about technology choices?

Developers tend to prefer tools they're familiar with. Strong opinions often reflect personal experience rather than objective evaluation of what works for a specific team or context.

How should teams evaluate new technology choices?

Assess specific problems the technology solves, learning curve requirements, ecosystem maturity, and fit with existing tools. Avoid adopting technology based solely on community enthusiasm.

What challenges arise when teams have mixed technology preferences?

Mixed preferences create cognitive load from juggling multiple tools, knowledge silos when specialists leave, and hiring friction when candidates evaluate mismatched stacks.

Related