What things tend to slow a developer down?

Please try to refrain from posting answers that:

closed as not constructive by Eric Wilson, Walter, ChrisF May 4 '11 at 20:44

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by World Engineer Jun 26 '13 at 4:48

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. See the help center for guidance on writing a good question.

Read more about locked posts here.

  • @Mark Trapp: Huh?! That's not a duplicate at all... :-S – Tamara Wijsman Sep 10 '10 at 17:54
  • 1
    If the question doesn't turn out useful I'll remove it in the near future, people are listing distractions which is already covered by another question from me. So I tend to look for non-distracting things... TheLQ and Bill are good example answers. – Tamara Wijsman Sep 10 '10 at 18:02
  • Huh, the URL got mangled. The duplicate is What distractions can happen during programming? – user8 Sep 10 '10 at 18:13
  • Chosen to leave the question open because it's about things that aren't distractions... – Tamara Wijsman Sep 15 '10 at 16:38
  • 11
    Stackoverflow, SuperUser, Programmers...yeah, basically sites like this :) – bedwyr Oct 22 '10 at 15:51

29 Answers 29


Oh this ones easy:

  1. Meetings
  2. More Meetings
  3. Meetings about the last meeting
  4. Meetings to prepare for the upcoming meeting
  5. Developing a power point presentation for a meeting
  6. Developing a power point presentation for a meeting discussing features that haven't been implemented, shouldn't be implemented, and for whatever reason that guy from sales will jump all over. I can't predict what document you want displayed in the app based upon your current location without an internet connection or access to your hard-drive. No really, just give up asking for it too.
  • 4
    in short: management? ;o) – n1ckp Oct 22 '10 at 14:38
  • 11
    @n1ck No, no. Good management can speed up a developer. Poor scheduling of a programmer's times (i.e. one aspect of being a manager) can really slow down development. – wheaties Oct 22 '10 at 14:51
  • 3
    what kills me is when my company does this: Meetings, More Meetings, Meetings about the last Meeting, Meeting to prepare, Meeting to discuss why we can't get anything accomplished. Why can't we get anything accomplished? You've got fourty devs sitting in a room listening to you!! – Mike M. Oct 22 '10 at 18:07
  • 2
    Please note that this answer would almost fit on a Powerpoint slide. – user1249 Jan 5 '11 at 11:29

A slow computer

  • Same problem here – pramodc84 Jan 5 '11 at 6:39
  • 1
    I'd buy myself a laptop ASAP and work on that if I was in that situation, assuming the company allowed it ofc. – adamk Jan 5 '11 at 16:00
  • Slow computers tend to be the root cause of a distraction. Everytime the programmer waits they might enter into distraction mode and won't come back to the program until some time later. – edA-qa mort-ora-y May 3 '11 at 12:21
  • They replaced my computer a couple of weeks ago. It's less powerful than the 4-year old one it replaces. Nice. – MetalMikester Nov 23 '11 at 11:24

Anything that causes context switching.

  • Like typing on the keyboard? – user1249 Mar 4 '11 at 11:37

StackOverflow, programmers.stackexchange.com, etc. :)

  • 4
    Disagree! StackOverflow helps to solve issues, so it speeds up development! – Wizard Sep 13 '10 at 22:50
  • 3
    Offensive silliness. For every minute I've 'wasted' on SO, it has bought me back 20. – MIA Sep 15 '10 at 15:07
  • 11
    +1. not offensive at all. SO is very good for procrastination. It's my new facebook. :) – back2dos Oct 22 '10 at 14:49
  • @back2dos Please don't compare SO's awesomeness with the piece of.. that is facebook. – adamk Jan 5 '11 at 16:01

I would say burnout.


Any attempt to follow a process that is not suited to the task at hand.

This can be all sorts of things, but common ones I see include:

  • testing methodologies that do not fit the code being tested
  • processes that are dramatically more agile or traditional than the deliverable(s) warrant
  • guidelines that are meant for a different toolset than the selected toolset
  • design principals that are out of scale with the project's needs
  • using a toolset that is not suited to the task

All of these things can be immensely worthwhile on some projects or in some situations, but some organizations try to do everything one way and that leads to poor fit on other projects which often is productivity death.



eg: When more than one person owns the requirements (or worse, two different vested interests), and they make competing and conflicting changes to the requirements whilst development is underway.


Conversations of others

and noise in general

Many answers talk about context-switching and getting out of the zone, and noise, especially conversation, is one of those things that leads to those for me.

In my cubeworld, I'm surrounded by noise and conversation on all sides. One row over, the mainframe team holds constant planning meetings in the cube row. Sometimes, they'll meet with consultants in an office along the wall, and that tends to lead to loud hootin' and hollerin' and laughin' and I have to go over and ask them to close their doors.

On the other side, the web team conference table is on the other side of my west cube wall, so I am part of every meeting, like it or not. There's also a printer on the other side of the south cube wall, and that's always good for chit-chat from people hanging out waiting for their printouts.

The immediate and obvious answer of "Can't you just get noise-canceling headphones" doesn't help when what you want is silence.

Sometimes for code reviews, I take my stack of papers to the lunchroom (at non-lunch times, of course), but there's a TV in there that's usually blaring. I'll turn it off if no one is watching. Otherwise, I'll go find an empty cube in an other department in another part of the building.

If you want your programmers to do the work they need to do, which is predominantly thinking and pondering and considering, they need an environment where they can do it.

  • Sometime's it gets too quiet where I'm at. I start focussing on everyone's mouse clicks and people breathing heavy, etc... It's like laying in bed and hearing a cricket. – kirk.burleson Jan 5 '11 at 12:27

Writing too many lines of code without adequate tests.

  • This is the number one cause of things grinding to a halt in my experience. – Paddyslacker Sep 19 '10 at 17:13
  • 1
    @Paddyslacker: more test = more productive? Huh? Only for people who shouldn't be in programming in the first place. Test can be useful but "the number one cause of things grinding to a halt"? Are you serious? – n1ckp Oct 22 '10 at 14:41
  • 1
    @n1ck: Yes, I'm serious. The code gets into an unmaintainable state and the lack of tests and testability of the code base means that each new feature becomes more & more difficult to add. I find it amusing that you think that you think people who write more tests "shouldn't be in programming in the first place." So Roy Osherove, Michael Feathers, Uncle Bob, Kent Beck etc. shouldn't be in programming then? – Paddyslacker Oct 22 '10 at 15:13
  • @Paddyslacker: I don't know. Never saw them code. Maybe they should be better in management from your description? And why do code get unmaintainable because of lack of test exactly? Test make poor code great by some kind of magic maybe? – n1ckp Oct 22 '10 at 16:24
  • 1
    @n1ck, tests do not pay of when writing the code initially, but makes an enormeous lot of difference when having to maintain the code later. – user1249 Oct 22 '10 at 17:59

Lack of high quality coffee.

  • Or lack of good soda. I miss so much decaffeinated diet cherry coke! In my country I can get only diet coke, or decaffeinated coke, and not cherry coke at all :-( – Wizard Sep 13 '10 at 22:52
  • 1
    @Wizard - I use to work for a company that provided Diet Cherry Coke. Not sure why I left. If feel your pain. – JeffO Sep 15 '10 at 14:59
  • 2
    @Wizard: just buy a jar of maraschino cherries and add some of the syrup to your drink. Now you can make it as strong as you like... (same trick for vanilla: real vanilla coke is far superior to the pre-mixed stuff) – Shog9 Sep 15 '10 at 15:01
  • @Mr. C: The problem is that I need diet+decaf coke, a combination that is not available in my country. – Wizard Sep 16 '10 at 17:30

having to make perfect estimates that must not be veered from once development begins, it's a chicken-egg scenario in my opinion

  • If you run into that a lot, I would suggest spending some non-trivial time studying up on estimating. Then you can respond "if it's an estimate, it is by definition not the amount of time it will actually take". – MIA Sep 15 '10 at 15:15
  • oh I've used that one before, the response is always that I'm bad at estimating, if it can't be broken down into visible 2-4 hour tasks then I'm doing it wrong apparently – MetaGuru Sep 15 '10 at 23:47

Fixing someone else's broken build

  • sounds like someone is not mentoring well his co worker. – Display Name Jan 5 '11 at 14:14
  • @bold: it can happen naturally from asynchronicity. Let's say the daily build cutoff time is 5am, and you checkout the latest version at 9am. (In other words, you can't stop people from coming to work early.) – rwong Jan 16 '11 at 22:04

Meetings with no agenda.

A slow machine.

Lack of a second monitor.

An old mouse that has a ball instead of the nice new ones.

Lack of internet access on the machine, making querying MSDN/stackoverflow/etc a bit of a pain.

  • Related to the no agenda meeting is the meeting hijacker. You know... you put it on the calendar for an hour but even if the topic is wrapped up in 20 minutes, there's that guy goes on to find other topics to fill out the 20 minutes. I would upvote you, but then I'd have to downvote you on the "lack of a second monitor" as a slow down. It's is convenient, but not having it on occasion hasn't slowed me down. – MIA Sep 15 '10 at 15:09

Spent too much time programming

Even if you really like programming, spent too much time on it will eventually burn you out...


Avoid everything that gets you out of "the zone". That means your email inbox, your twitter popup application, your corporate chat, etc.

Having a quiet working condition means avoiding that desktop noise too.


Any change request that would have been easier to implement if you knew about it before hand.

  • "Walking on water and developing software from a specification are easy if both are frozen" – back2dos Oct 22 '10 at 14:50
  • 1
    Silly quote. Walking on ice is not always easy. – Peter Boughton Oct 22 '10 at 15:09
  • 1
    @Peter Boughton: If we choose a scale, where developing software from fluctuating specs is hard and from frozen ones is easy, then walking on ice is always easy. You can teach a 6 year old to do that. But I suppose you know that, you just take pleasure from smart assing. – back2dos Oct 23 '10 at 10:38
  • And you can teach a six year old to work from fluctuating specs, too. It's not being smart-assed, it's irritation at the overuse of quotes like that, which are not helpful. Frozen specs are not easy to develop from if they're wrong (since they can't be fixed), and changing specs are fine if you know in advance which parts are in flux (as you can cater for it). – Peter Boughton Oct 23 '10 at 14:12

Poor code.

Having to rewrite the part of someone else who could have done the job right in the first place is the biggest time sink I can imagine.


The Much That Slows You Down is a good blog post for this.


Many projects repeat core infrastructure-level features over and over, slowing that business down in delivering features that differentiate the business from its competitors.


It is inevitable that products and innovations will help reduce the time developers spend on non-differentiating tasks. The question is what form those services and tools will take.


  • +1: Great answer. I left a job because the company was unwilling to commit time to reduce technical debt. Developers were forced to "repeat core infrastucture-level features over and over." – Jim G. May 3 '11 at 16:20

Well lately the biggest slow down is because we are developing several things simulatneously that should have been done in a specific order. So I'm waiting until (names changed to protect the innocent) John finishes his component that I need for my SSIS package and Harry is slowed down waiting for me to import records because he needs some data to see to test his export (ever try to write a complex export report when there is no data in any of the tables?) and everybody is slowed down because design isn't done and the database tables we need to do our tasks haven't been created yet and may not even end up being what they said they were going to be, etc.

  • 1
    It sounds like you're talking about bottlenecks caused by spreading work too thinly across team members. – MIA Sep 15 '10 at 15:12
  • 1
    It's not so much the team is spread thinly but that management didn't think about dependencies in assigning projects. And somethings that were assumed to be ready at the point the other peolpe got assigned to the project were not once people tried to actually use them. – HLGEM Sep 15 '10 at 15:30

Answering questions on stackexchange.com, like this one.

  • You may consider improving your touch typing skills, then. – user1249 Mar 4 '11 at 11:38

Even though you asked not to list distractions, they can be a big factor. Look at their work environment, check to see if they're being interrupted frequently or asked to do other things that aren't related to the project.

Sometimes, a developer might get stuck because they're doing something they've never done before, and they don't know where to look for help. If it's a small team or individual, it can be even more difficult. We tend to be somewhat prideful and dont like to admit when we dont know how to do things. Also, we dont like asking others for help. There's no easy way to get a developer to admit this, except maybe to ask if they can meet the deadline, or what they need to meet the deadline, and then hope they'll be honest. You may need to offer to bring in other help, or find someone that can help them.

Lack of clearly defined requirements, which leads to them having to figure things out or make decisions.

  • Having to wait about 15 minutes for the PC to boot into a usable state
  • Waiting for the PC to switch applications
  • Being the only person in the office who has to make his own tea/coffee.
  • A broken keyboard (fixed!)
  • Working outside the Managing Director's (US CEO) office (and not in an office, either), with only a partition in between (especially when there is a meeting)
  • The boss is only reachable by email, but everybody else is in the building
  • Not being allowed to use a VCS — apparently it should be in my brain
  • Small screen
  • Not allowing time for breaks other than lunch
  • Having to do remote server backups despite having a sysadmin in the building
  • Being told to do said backups manually.
  • Being forced to use a stupid time management system that is needlessly complicated
  • Only just getting a vague idea of the requirements two months into the job

I could go on, but it's Friday and I want to forget about work.

  • Sounds like you need to get out of there! – adamk Jan 5 '11 at 16:06
  • Lack of documentation (System, Company, etc.)
  • Lack of commented code
  • An incomplete understanding of the system
  • Politics (i.e unnecessary meetings, paperwork, obstacles by management...)
  • Incomplete requirement documentation
  • Facebook!
  • Too much sleep?

Too many people on the project.

Seen it several times where the management decides based on no real data that they need to add more people to the project. That ends up in the ppl who know what's going on needing to stop everything to hold the hands of people who know little about what's going on. I've seen more than one project mushroom in size and then go in the toilet quickly from there whereas before it was going along fine, although maybe a little slow.

So you go from being a month late because of not enough velocity/too much to do to not delivering at all because you totally blew the budget on all those extra people.


Apart of the things mentioned by others, the long way between deciding to compile&run your code and getting a positive/negative result. Ideally, this RTT would be just a second, but I've seen an example of hours. BTW, unit testing tries to deal with this problem.

Another related this is a general latency of your working environment. Imagine you'd need to work over remote desktop connection to the computer on the other side of the world, over a creepy connection. I've been there. I've hated this.

  • Excessive paperwork

  • Having a dependency on someone who's never around (such as your boss - if you need to ask a question but he's always in meetings)

  • Inadequate tools & equipment.

  • People shoving their oar in for no reason (any UI-visible change is subject to this) or just arguing the toss about trivial stuff.

  • Broken coffee machine

  • Being assigned the wrong tasks


The air conditioning failing to work.

So the temperature in the office gets up to 40 degs in the summer of -5 in the winter.

The -5 not good for typing, as i can't wear gloves and type. The 40, just slows my thinking down.


This is a highly personal and perhaps controversial opinion, but planning and thinking too much about design up-front or writing "quality" code all the time. There's a saying that "weeks of coding can save you hours of planning" that might be true in some cases.

However I often see programmers try to sketch out a good design before starting coding. I find myself that it's easier to just "get going", as you program you will learn more about your problem and solution which will allow you to refactor your solution rapidly into a good design. Most of the issues arising are pretty much unknowable at the start of coding (atleast to my feeble mind) so wasting a lot of time designing up front is just a waste of time.

This is also why I don't like TDD, you waste too much time writing tests which makes you either less likely to refactor or takes up a lot of time to rewrite the tests. Unit Tests are great for some cases and some stages of a project, but the beginning of one isn't one of them IMHO :)

Get something working quickly and improve it.

  • -1 I can understand your thinking, but the point of the design stage is to limit the need to refactor. It also facilitates unit testing which is great all the time for making sure something that was working doesn't get broken and released. If you don't do any planning, you will make everyone elses jobs harder when they have to try to maintain what will inevitably be poorly architectured code. – adamk Jan 5 '11 at 16:12
  • Who says it'll be poorly architectured? I'm just saying that you don't want an excessive design phase and need to do lots of refactoring and re-architecturing during a project to arrive at quality code. On the other hand, for this to work you have to have clearly deliniated code responsibilities where different people aren't mucking around in each other's code. – Homde Jan 6 '11 at 6:55
  • Experience says that it'll have poor architecture. Flying by the seat of your pants and cowboy coding are probably the worst things you can do during development. Having a design phase that will last a week, will save you months of programming and will lead to code that does what it's supposed to the first time around. The idea behind TDD is that you don't change the tests. Those tests are meant to emulate real-world usability, and if your code can't finish the test, then your code is wrong. – Mike S May 3 '11 at 15:06
  • My experience says otherwise, but I guess it depends on the cowboy and the team :) I've learnt more by one week of coding and have done some code to show for it. Of course you'll have poor architecture if you don't do extreme and continuous refactoring and have a team/cowboy that's agile enough to keep up. Thinking you can do a "design phase", learn everything and do it right the first time is simply naive. The real value of a prototype are the lessons you learn, the you throw it away and do it right. Do that multiple times and fast :) – Homde May 3 '11 at 19:46

Programmer's Block: Unlike other slow downs, this one is harder to resolve.

Not the answer you're looking for? Browse other questions tagged or ask your own question.