What can slow a developer down? [closed]

Question

What things tend to slow a developer down?

Please try to refrain from posting answers that:

• are slow now but useful in the feature. (TDD, Refactoring, ...)
• list a distraction.

Answer 1

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.

Answer 2

A slow computer

Answer 3

Anything that causes context switching.

Answer 4

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

Answer 5

I would say burnout.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

Writing too many lines of code without adequate tests.

Answer 10

Lack of high quality coffee.

Answer 11

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

Answer 12

Fixing someone else's broken build

Answer 13

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.

Answer 14

Spent too much time programming

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

Answer 15

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.

Answer 16

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

Answer 17

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.

Answer 18

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.

...

Answer 19

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.

Answer 20

Answering questions on stackexchange.com, like this one.

Answer 21

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.

Answer 22

• 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.

Answer 23

• 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?

Answer 24

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.

Answer 25

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.

Answer 26

• 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

Answer 27

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.

Answer 28

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.

Answer 29

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