What really matters in software developer productivity: a 105-dev survey

Published 21 Oct 2025

In late 2024 I surveyed a 105 developers over 10 weeks with the help of social media platforms (e.g. LinkedIn, Reddit), professional forums (e.g. HackerNews), and other programming communities to capture a wide range of experiences, with respondents varying in experience level, technology stacks, team sizes and more.

My goal was simple: to better understand developer productivity and to see what impacts it.

TL;DR — Jump to key findings.

Over 77% participants were under 35, so the survey mostly reached a relatively young part of the industry.

Around 85% respondents were male.

Female respondents accounted for around 12% of the responses. According to SlashData's 2023 Developer Nation survey performed on 8380 developers, the share of female developers oscillates around 23% globally, so this study might base on a sample that's underrepresenting the female part of the industry, therefore performing analysis between genders would make little sense and possibly introduce bias.

Around 86% of respondents reported being directly involved in development and engineering. Another 8% were also involved, but on a higher level (conceptual work, architecture and technical leadership). Remaining 6% were site administrators, support engineers or other roles.

I have reached developers with wide ranges of experience levels, useful factor to compare later. Expertise areas were a multi-choice field. Developers experienced in back-end, front-end and DevOps having over 2 years of experience dominate the survey group. Less experienced developers seem to be significantly underrepresented, therefore it wouldn't make sense to analyze that segment in the survey.

Only 6% reported working in simple projects involving predictable tasks, few dependencies, and straightforward requirements.

Project scale impacts the complexity and types of challenges teams face, with larger projects requiring more coordination and resources.

34% of participants are engaged in small teams of 3 to 5 members, while 44% operate within medium-sized teams consisting of 6 to 15 members. Making a comparison between these two team sizes is an opportunity to understand how team composition influences other measured factors.

Physical work environment

Work environment is not only the physical space where developers work (remote, on-site, hybrid). It also includes the mental environment: team culture, motivation factors, stress levels.

First, to compare work environments (remote, hybrid, on-site), appropriate scales were introduced so that higher values == "better".

Hybrid developers often report more frequent achievement recognition, whereas on-site developers seem to suffer more frequently from impostor syndrome yet report lower stress overall, suggesting social interaction might reduce stress but also provoke negative self-assessment.

Summarizing by calculating the area of respective polygons indicates that hybrid developers generally report better well-being than on-site developers:

Some open answers reveal that an in-office environment sets better boundaries between personal and professional life, and remote workers often find it hard to "switch off", as one respondent notes:

If you're not careful, working at home means you never truly leave 'the office.'

Other respondents cite the need for better recognition and manager appreciation:

[...] how do we give the work done by developers the appropriate value and reward? I think that would improve productivity greatly.

Who the developer is matters more than anything. Want more productive people? Show them they matter to you. Treat people well and get out of their way.

There are even more differences in how developers experience remote-only work.

Remote teams enjoy flexibility and asynchronous work but risk more alignment calls, digital interruptions, and self-discipline hurdles. Onsite/hybrid teams benefit from rapid in-person collaboration yet face noise and social intrusions.

Youngest developers are far more likely to be working in hybrid or onsite roles. It might reflect post-pandemic company policies that expect developers to be present in the office.

In contrast, developers over 35 generally work remotely, which can be a symptom of different work-life balance.

Planning and resources

Let's see how developers perceive their own momentum and ability to deliver on time.

On average, participants manage to deliver mostly on time.

Surprisingly, the average self-reported deadline meeting frequency slightly decreases with experience. It might be caused by the fact that junior developers have well-defined tasks, whereas senior developers usually have very vast tasks across many moving parts.

With increased expertise, many experienced developers set a higher standard for defining a task as "done", introducing a possible self-critical bias when answering the survey.

Senior team members frequently wear multiple hats: mentoring, product coordination, production support. These extra responsibilities might cause additional overhead, delaying their own coding tasks and leading to missed deadlines.

Overall, this does not necessarily imply that senior developers are less productive. Rather it suggests they may face more complex challenges, as one senior respondent noted in a separate comment:

A few days' delay on a major architectural change may feel more serious than a small missed deadline on an isolated ticket.

Developers lacking resources and developers complaining about unclear requirements were the group least effective in reaching deadlines. Let's explore this by comparing team sizes.

Scope creep appears universal across all team sizes, highlighting that no matter how large the team is, changing requirements and additional features remain a main threat to on-time delivery.

Smallest teams were often subject to lack of resources (e.g. insufficient team members or missing tools) as a primary reason for missing deadlines.

Medium teams have a more balanced distribution of obstacles, but are still subject to scope creep and unclear requirements. They typically have enough staff to handle various tasks but may face communication overhead or shifting priorities.

Very large teams also reported lack of resources, which might seem counterintuitive at first. A possible explanation is that in big organizations, specialized resources are sometimes tied to specific departments, or bureaucratic processes slow down obtaining the right tools or staff.

Smallest workplaces frequently struggle with unclear requirements and rapid pivoting, which can make hitting deadlines more challenging. Their focus on speed and experimentation might overshadow formal planning.

Medium-sized workplaces tend to have more stable processes, so they rather report scope creep or internal dependencies instead of constant requirement changes.

Larger enterprises show a spread of different challenges: some mention hidden complexity in legacy systems. Even though they have more established procedures, the slow decision-making and multiple layers of management can slow progress.

The data indicates only minor differences in how often teams of various sizes manage to meet deadlines.

No single team size clearly guarantees timely delivery. Instead, coordination, clarity of requirements, and resource availability seem to matter more than raw headcount.

Smallest workplaces are the most prone to missing deadlines, likely because they rely on quick pivots, minimal processes, and sometimes underdeveloped planning strategies. One survey respondent captured this perfectly:

I would start by improving the management, making it mandatory for them to be organized and to give requirements in a planned way. [...]

Some big organizations still cope with heavy bureaucracy that can slow delivery, despite having more resources. As one respondent from a large workplace notes:

"Less bureaucracy in a large company."

It seems apparent that as developer gains experience, unclear requirements become less of a problem. They likely learn how to manage this properly. However, scope creep is a universal challenge across all experience levels.

Deployments and CI/CD

Most respondents can deploy changes in less than 30 minutes however 30% mention they need an hour or more. Those with longer deployment times often complain about manual checks or gating processes.

Manual steps create extra stress and slow the momentum of releases. However, it's not always possible to automate everything as some teams deal with hardware dependencies or environment constraints that make continuous delivery hard. But for pure software teams, many see automation as a major boost to daily productivity.

Teams with automated deployment show a slightly faster average deployment time. While automation alone might not fix every bottleneck (e.g. compliance processes), generally those with automation in place achieve quicker, more predictable releases.

Time spent on coding

Lack of resources, organizational bottlenecks, and unclear requirements are main obstacles to meeting deadlines. Hidden complexity in the form of technical debt or legacy code and CI/test-related problems are minor problems in this analysis. Perhaps developers manage to correctly estimate them.

Legacy code and CI-related challenges are rarely deadline blockers. While legacy systems can be time-consuming, they are relatively predictable once developers understand the codebase. On the other side, unclear requirements can constantly shift, causing repeated rework. Their unpredictability creates far more serious risks to the schedule.

Communication tools

Developers rarely have the freedom to choose their preferred communication tool, it is rather a requirement of the employer. Let's examine how satisfied they are with them.

Microsoft Teams seems to be the leader in big corporations, perhaps these companies already use the Microsoft Office suite, so it's a natural choice to opt in with Teams for additional integrations as they are already deep into the ecosystem.

Other choices included Discord, Mattermost, internal tools and plain emails. They will not be extensively covered further.

Slack's threading & organization was praised: many highlighted threaded conversations, flexible channel architecture, lightweight feel for daily tasks and advanced search. Developer workflows were easier to build thanks to integrations with GitHub/GitLab, slash commands.

Microsoft Teams was appreciated for its integration with Outlook, corporate auth (AD/SSO), and the Office ecosystem. However, it received negative feedback for being resource-heavy & bloated. Several respondents called it "slow", "clunky" or prone to random sign-outs, buggy screen-sharing issues. Teams forced to migrate from Slack reported negative morale and criticized poorer integration capabilities compared to Slack.

Google Chat is seen as lightweight, quick to setup and easy to adopt if the team already uses Gmail or Google Docs. Perfect for basic messaging and smaller teams. Meeting links or simple file-sharing are easy to use. As of 2024 it lacked slack commands, thread management, compatibility with accessibility tools.

Given Microsoft Teams' tight integration with Outlook, and Google Chat's integration with Gmail, it's unsurprising that these platforms might push more message or calendar alerts into developers' daily flow.

Code reviews

Peer code reviews are a common practice in software development teams. It's a means of finding errors and logical mistakes. However, extended review cycles can delay merges and cause bottlenecks, especially in busy teams. Let's discover how that impacts developers.

Respondents can be naturally categorized depending on their impression on code reviews. Code reviews are fast if performed within 24h, otherwise they are delayed.

Additionally, developers were categorized based on the perceived impact of receiving code reviews: helpful if code reviews are rated 4-5, unhelpful otherwise.

Developers were grouped on these categories to compare how they rated their well-being.

When feedback is considered unhelpful and arrives late, developers report the highest average stress level across all groups.

The exact opposite is observed if the feedback is helpful, regardless of being delayed: developers report the lowest stress levels on average. Most likely good feedback gives a sense of support and helps to celebrate achievements.

Another group to consider is the one considering code reviews fast, but unhelpful. This group reports high levels of impostor syndrome and rarely report receiving recognition. It's possible they find feedback inconstructive or purely "nitpicky", feeling their work is constantly investigated without providing actual support, and rarely involving praise.

Shared ownership

In addition to timeliness and quality, some respondents highlighted the value of sharing ownership, and even distributing "blame" through collaborative code review practices:

"Blame on bugs plays a big role in software development. If the blame is spread across the team by Code Reviews and team tasks, I believe the team is healthier and happier".

"[...] You can achieve a great result by having the right team leadership, great team culture or sharing team responsibilities (the more responsibility you have the more you care about product/project)".

Participants also had a chance to describe their experiences with code reviews in open-ended answers.

Some developers reported that timely and constructive feedback boosts their confidence. Even small acknowledgments of good coding practices or improvements helps them grow. Collaborative approach and supportive, discussion-based review culture makes them feel recognized and reduces impostor syndrome by showing that their work has real value. Some respondents even saw some code reviews as mentorship moments, where received suggestions help them grow.

However, prolonged wait times increase stress and force context-switching, interrupting their flow and leaving them uncertain about the quality of their prior work. If these code reviews are simply rubber stamps without insight, developers report feeling underappreciated which can provoke impostor syndrome, as they never receive meaningful validation.

Junior developers tend to positively rate code reviews with longer wait times, a counterintuitive finding. Due to the minimal number of junior respondents, this is considered non-representative.

Mid-level developers appreciate code reviews less when forced to wait longer. Timeliness seems crucial to maintaining flow and momentum in their daily tasks. Several respondents in this group reported fast reviews but described the feedback as unhelpful: describing the feedback as "contradictory", "purely nitpicking", or effectively nonexistent.

Senior developers show a higher tolerance towards slight delays (it might be a sign of extensiveness). Some respondents indicated that very long waits often result in no actual review, or solely a neutral/box-ticking process. Another respondent reported a mismatch in team expertise, where they receive minimal feedback from junior colleagues.

Technical debt

Technical debt can be understood as the accumulated cost of low-quality code with a tendency to slow down future development. While technical debt is often introduced for temporary reasons (e.g. meeting short-term deadlines or rapidly prototyping), it slows development down if left unaddressed. Many respondents mentioned legacy code, missing documentation, and poorly structured modules as factors slowing daily work.

It seems apparent that teams spending the most time on tech debt rarely reach deadlines, and at the same time report the highest number of deployments per month.

Respondents spending more than 75% of their time paying tech debt are experiencing stress more often.

Open-ended feedback on tech debt

Respondents had the possibility to explain how tech debt impacts their productivity.

Developers reporting negative impact of tech debt on their productivity see technical debt as an ongoing struggle. They regularly fight blockers whenever they try to implement new features.

Many mention inherited undocumented systems that slow all tasks. Old code bases appear hard to work on, so each change risks new bugs or confusion.

Respondents working solo or under tight deadlines rarely have opportunities for refactoring. Because no formal time is allocated, they only fix issues when absolutely necessary. Since higher-level leaders do not care about code quality, prioritizing quick feature delivery instead, over time the codebase becomes messy.

Developers perceiving tech debt as positive don't claim zero debt: rather they have practical control over it. Some schedule refactoring or "technical debt tickets" each sprint. Debt is present, but is taken into account in the backlog and regularly addressed.

Conclusion

The survey results present a common problem: most problems with developer productivity aren't caused by lack of talent, but rather friction in processes.

Team size alone didn't move the needle, as differences in delivery on time were minimal. Hybrid office policy had a slight positive impact.

But most of all: clarify scope, keep code reviews helpful and address tech debt to increase throughput without people burning out.