Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What things tend to slow a developer down?

Please try to refrain from posting answers that:

share

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. More info: help center.

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.

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. –  Tom Wijsman Sep 10 '10 at 18:02
11  
Stackoverflow, SuperUser, Programmers...yeah, basically sites like this :) –  bedwyr Oct 22 '10 at 15:51
show 3 more comments

29 Answers

up vote 49 down vote accepted

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.
share
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
show 1 more comment

A slow computer

share
1  
+1 -- this is the problem in my company! –  Wizard Sep 13 '10 at 22:49
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
show 3 more comments

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

share
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
show 1 more comment

I would say burnout.

share
add comment

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.

share
add comment

Politics

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.

share
add comment

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.

share
show 1 more comment

Writing too many lines of code without adequate tests.

share
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
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
show 14 more comments

Lack of high quality coffee.

share
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
show 2 more comments

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

share
show 2 more comments

Fixing someone else's broken build

share
show 2 more comments

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.

share
show 1 more comment

Spent too much time programming

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

share
add comment

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.

share
add comment

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

share
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
show 2 more comments

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.

share
show 1 more comment

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.

...

share
show 1 more comment

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.

share
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
add comment

Answering questions on stackexchange.com, like this one.

share
show 1 more comment

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.

share
add comment
  • 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.

share
show 1 more comment
  • 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?
share
add comment

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.

share
add comment

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.

share
add comment
  • 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

share
add comment

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.

share
add comment

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.

share
show 4 more comments

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

share
add comment

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