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.
What things tend to slow a developer down?
Please try to refrain from posting answers that:
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.
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.
Oh this ones easy:
Anything that causes context switching.
StackOverflow, programmers.stackexchange.com, etc. :)
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:
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.
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.
Writing too many lines of code without adequate tests.
Lack of high quality coffee.
having to make perfect estimates that must not be veered from once development begins, it's a chicken-egg scenario in my opinion
Fixing someone else's broken build
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.
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.
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.
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.
Answering questions on stackexchange.com, like this one.
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.
I could go on, but it's Friday and I want to forget about work.
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.
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.
Programmer's Block: Unlike other slow downs, this one is harder to resolve.