Slashdot Mirror
Ask Slashdot: What Practices Impede Developers' Productivity?
nossim writes "When it comes to developers' productivity, numerous controversial studies stress the differences between individuals. As a freelance web developer, I've worked for a lot of companies, and I noticed how some companies foster good practices which improve individual productivity and some others are a nightmare in that regard. In your experience, what are the worst practices or problems that impede developers' productivity at an individual or organizational level?"
Meetings are how people who don't know what they are doing suck the productivity out the people who do.
Sent from my ENIAC
#1 visiting slashdot
...software patents?
When I get in the zone I want to write code. I had a job that made you RDP to a development network to use Visual Studio on a machine that didn't have access to the internet (only to source control and the database server) and there was no copy/paste or file transfer to your environment -- you had to get the IT group to move files for you. You couldn't last 'in the zone' for very long before needing someone else's help to do *something*
Hitting brick walls like that, and not being able to take care of your own needs seriously crushes developer productivity (and to a certain extent, morale).
Procrastination is the Number One Productivity Impeder (Not sure if right word, but spellcheck isn't getting me)
Anytime the process boils down to "if it's not a new feature or an emergency bug fix, you are not allowed to spend any time on it. And if you do spend any time on something like fixing spaghetti code so that implementing new features and emergency fixes don't take an act of God, we will refuse to promote it to production, as our policy is to not promote changes to anything that 'already works.'"
Also: any environment that promotes code ownership (either explicitly or, more often, implicitly) so that you can't make any changes without it almost immediately becoming an HR issue.
Nothing kills progress than having to create documentation that will never be read or updated.
Don't get me wrong - certain types of documentation are important (overall systems design, data models, for example). But unless you're going to continue to use the documentation after the project has been completed, don't bother creating it.
What most people seem to forget is that if you don't plan on maintaining all the documentation you create, you're wasting your time. Once a document is out of date, it no longer serves it's purpose. I'll expand on an adage: Outdated and incorrect documentation is worse than no documentation at all.
you're already having trouble meeting a deadline
Artfical deadlines imposed by management are a major suck of productivity.
I might be in a minority, but having a cube-less environment, where everyone is sitting in a huge room, behind a desk and can see and hear everyone else, is the worst. I feel like sitting in a 60's call center. The "goal" of this arrangement is "collaboration". The result is distraction and irritation.
It doesn't matter if we're talking about bouncing between meetings and coding, coding and documentation, or just coding too many unrelated modules -- every time there's a substantial context switch, it takes a little bit for you to get your bearings and get up to speed. Sort of like a vehicle making sharp turns all of the time.
Koans and fables for the software engineer
HOLY capital letters that was a LONG comment... I see where your COMING from but I don't TOTALLY agree. Meetings DO harm you as far as time is CONCERNED. Rarely are YOU exiting the meeting with a better UNDERSTANDING of what the meeting was SCHEDULED to resolve. Most of the TIME its so that some MANAGER can get the people who KNOW what they are DOING in one room to REACH a DECISION. Rarely are meetings beneficial to ALL parties involved which results in TIME loss and PRODUCTIVITY wasted. I'm using GRATUITOUS use of all caps like you HAVE in your response because I'm emphasizing my WORDS so you understand my intelligence level.
I'm not all the way into drinking the Agile koolaid, but to be fair the original idea of Scrum meetings was explicitly designed to avoid that problem. Scrum meetings are supposed to be led by a "Scrum-master", who is not supposed to be the manager or boss of the meeting participants. In fact the manager is not even supposed to be there. Scrum is supposed to be a way to facilitate communication within a team, so everyone knows what everyone else is working on. The scrummaster is just supposed to be another engineer on the team who facilitates the meeting so it moves along, and is not supposed to be someone who has any particular authority over the project or the participants.
Most companies have ignored that part, and the Scrum meetings are, as you say, run by the manager, as these daily "report your progress" checkins.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Some meetings are necessary obviously... I'm in my first senior developer position now and I've instituted hard limits on meetings because it frustrates me to no end when idiots discuss minutiae for valuable hours of my team's time.
Agreed, but the actual time spent in meetings exceeds the required time by a significant factor at some workplaces.
Then there's the pay structure. It's almost as if some places want to pay as much as possible for work (paid overtime for panic fixes) or intend it to take as long as possible (long unproductive unpaid overtime). A better approach would be to pay for results, and damn the work time spent to achieve them, provided they meet the schedule. A 20 hour week can be as productive as a 40 hour week, and more productive than a 60 hour week.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I've had managers that constantly try to shift my priorities to whatever has their attention that day. They want me to drop whatever I'm to focus on the most recent urgent pet project.
When it affects cash flow, I fully understand. We need to take care of a big advertiser or something like that, totally understandable. Pretty much everything that doesn't fit in that particular realm though, forces me to tell my boss it will have to wait so I can finish my other 10 urgent projects. The line "everything is top priority" also fits in this realm.
Pivotal Tracker is actually really helpful in this regard because there aren't task lists, there's a queue and something is at the top of it. That is what you work on. If a manager wants you to do something else you force them to de-prioritize your other tasks. It's fantastic in that regard because it forces managers to acknowledge they are slowing down their own requests.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
One company I worked for recently had a singularly interesting practice. They had no receptionist or phone answering service, so a call from an outside line or press on the door buzzer made every single fucking phone -- 25 of them -- in the open non-partitioned office ring until someone answered it. They would then have to ascertain who was calling, call the person they were trying to get through to (phone directory in word document on "intranet"), work out where that person was (notice system on "intranet"), take a message or let the person in. This included software developers, of course, who were sharing the open office with systems analysts, IT support staff, production support, and the kitchen area. Requests to work in other (quieter) parts of the building or at home were denied as it was deemed to be bad for team work or unmonitorable.
I had a similar thing going on with a clueless manager. He wanted an explanation why projects weren't getting completed on time. I suggested I could do one better and show him why. He agreed. I downloaded I think it was a sample SAT math test. Where ever I got it, it was one of those four or five hour timed math tests.
I gave it to my manager and told him it had to be completed that day. And that just a passing score wasn't acceptable. It had to be returned at 100 percent. No exceptions. But the good news, it was open book. When completed, at his discretion, he could go back over any or every answer and double, triple check, use Google or whatever he wanted. But that no matter what, 100% was needed.
I handed it to him and said your time starts now.
Then I continued taking and mentioned the two meetings we had scheduled. I also told him I'd be needing his help later that day solving an issue we had with a project that was also due that day, etc.
I said I'd be back at the end of the day to see how well he did accomplishing his basic minimum job requirements. I wished him good luck
My goal was to convey that programming is like taking a math test. A math test requiring 100% accuracy. A task requiring full, uninterrupted concentration. That checking every answer when finished was equivalent to testing the code. Even if it was similar to taking the 4 hour test several times. But along with that, meetings, telephone interruptions, being pulled off on unrelated tasks were all part of the job.
Did I mention he was a little clueless? By the end of the day he hadn't even started the math test. And yet he never seemed to 'get it'.
-[d]-