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

Published 4 Oct 2025

In late 2024 I have conducted a 10-week-long survey on 105 developers recruited from social media platforms (e.g. LinkedIn, Reddit), professional forums (e.g. HackerNews), and various software development communities. This allowed me to capture a wide range of backgrounds, including differences in experience level, technology stacks, team sizes, and organizational types.

My goal was simple: validate the anecdotal advice and see first-hand what has real impact on developer productivity.

TL;DR — Jump to key findings.

More than 77% participants were under the age of 35, indicating that the survey mostly reached a relatively young segment of the industry. Age can influence familiarity with technologies and preferences for communication styles.

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, indicating that 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. Most frequent choices are back-end & front-end development and DevOps, and were predominantly made by developers having more than 2 years of experience in the industry. Developers with less experience seem to be significantly underrepresented, therefore it wouldn't make sense to analyze junior developers in the survey.

Only 6% of respondents report to work 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 work mostly remotely. This may reflect a prioritization of work-life balance, especially for those with families.

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. Most likely individuals have specialized skillsets, and any absence of expertise or tooling can cause major bottlenecks.

Medium-sized teams show a more balanced distribution of obstacles, with scope creep and unclear requirements being consistently present. 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 under 30 minutes, but around 30% mention they need an hour or more. Developers with longer deployment times often mention manual checks and gating processes, leading to decreased velocity.

Comments from respondents suggest that manual steps create extra stress and slow the momentum of each release. However, it's not always possible to fully automate everything. 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 appear as main obstacles to meeting deadlines. Hidden complexity (technical debt, legacy code) and CI/test-related problems rank lower 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 and how calendar, calls, and chat are consolidated in one place to avoid distractions. 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 received praise for being lightweight & quick to setup. Minimal clutter, easy adoption, and low friction 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. Some respondents noted its limitations: lacks powerful slash commands or robust thread management. In some cases accessibility is lacking: browser/extension incompatibilities, especially for text-based browsing.

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 assess 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", putting their work constantly under scrutiny without providing actual support, consisting of purely checking boxes and rarely involving any 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)".

This aligns with participants' answers to open-ended questions regarding their experiences with code reviews:

• 🟢 Timely and constructive feedback boosts developers' confidence. Even small acknowledgments of good coding practices or improvements helps them grow.

• 🟢 Collaborative approach and supportive, discussion-based review culture makes developers feel recognized and reduces impostor syndrome by showing that their work has real value.

• 🟢 Learning opportunity is an integral part of valuable code reviews. Respondents who praised them often viewed them as mentorship moments, where suggestions help them grow.

• 🔴 Prolonged wait times increase stress and force context-switching, undermining developers' flow and leaving them uncertain about the quality of their prior work.

• 🔴 "Rubber-stamped" reviews leave developers feeling underappreciated (lack of achievement acknowledgment) and provokes impostor syndrome, as they never receive substantial validation or guidance.

• 🔴 Minimal praise and unclear expectations isn't found helpful by developers, who rather want to understand why something is correct or praiseworthy. In the absence of valuable insight, they are unsure about their competence.

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 boiled down to the accumulated cost of suboptimal or quickly implemented code that can 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. While debt is present, regular backlog management keeps it from getting out of control.

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.

Practical recommendations on smoothing everyday processes:

The most durable improvements come from reshaping team culture and re-defining technical foundations: