Ask Slashdot: What Practices Impede Developers' Productivity? 457
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?"
The Number One Impediment is MEETINGS (Score:5, Insightful)
Meetings are how people who don't know what they are doing suck the productivity out the people who do.
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
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.
And then there's the PAY (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
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.
I'm pretty sure that's how the higher-ups think it works. That is, they have a project they want done and believe it can be done by Date X. They then hire/assign the appropriate number of people, such that 40-hour weeks will result in success. But they are horribly, horribly bad at estimating productivity.
Under a pay-by-hour model, the cost of poor estimates is on the company. Under a pay-by-piece model, the cost of poor estimates is on the programmer. ie, if you underestimate the time it will take to
Re:And then there's the PAY (Score:5, Insightful)
Yeah, nothing like not knowing how much your pay check will be for or getting some shitcan job you are doomed to fail at.
Pay a good salary, motivate the team, listen to them when they tell you a project is doomed from the start and set realistic goals. Works for me.
Re:And then there's the PAY (Score:5, Insightful)
Or people start getting the idea that if you can finish work in 20 hours, they can thus give you double the work.
Re:And then there's the PAY (Score:4, Insightful)
That already happens to the people who can finish their work quickly.
Re: (Score:3)
Or people start getting the idea that if you can finish work in 20 hours, they can thus give you double the work.
And they want the documentation to be done in an hour. Whether it is right or wrong. Delivered!! Points scored
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
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.
The issue isn't meetings, it's bad meetings. Each meeting should have a set agenda and a time limit for each topic. When I was a senior developer, I would have a weekly status meeting with my team. The meeting always started off with basic status reports (what did you do, what are you stuck on, what do you need help with), followed by project updates from other teams (where pertinent) and finally a free topic session to discuss any issue. If something took more than a couple minutes to discuss, we'd table it for a separate meeting with only the people that needed to be there. Meetings should exist to make sure everyone's on the same page and so people who need something have a forum to ask for it. Without a firm agenda (which is aggressively held to) meetings lower productivity.
Re:The Number One Impediment is MEETINGS (Score:5, Insightful)
Re:The Number One Impediment is MEETINGS (Score:4, Insightful)
The alternative, scheduling meetings at the beginning or end of the day, misses people who arrive and depart early or those who arrive and depart late. Core hours with meetings scheduled during that time is about the best you can do, if you want to give everyone some flexibility in working hours. Of course, you could have people attend meetings at both ends of the day (as those of us working with overseas teams have come to love), but I'm pretty sure that wasn't the solution you were looking for, either.
Bad meetings? (Score:3)
When I was a senior developer, I would have a weekly status meeting with my team. The meeting always started off with basic status reports (what did you do, what are you stuck on, what do you need help with), followed by project updates from other teams (where pertinent) and finally a free topic session to discuss any issue.
Okay, just to be clear.
In your meetings, everyone waits while one person tells his status, then everyone waits while a 2nd person tells his status, and so on.
How is this more efficient than everyone composing a 1-paragraph summary and sending it around in E-mail? How is this more efficient than the boss visiting everyone one-at-a-time, taking notes, and typing up a summary E-mail?
How is a "free topics" meeting with everyone better than "targetted topics" meetings with only the people involved? Aren't improp
Re: (Score:3)
Using email for everything can have a very negative effect. I've seen arguments that became holy wars in email chains completely dissipate in a meeting. I know some developers work in those conditions, successfully, but it is situational. It is often helpful to periodically just make sure you don't forget that those whom you are talking to over email are actually humans like you are.
I agree that many meetings are pro forma BS, but they do have their uses.
Re:Bad meetings? (Score:4, Interesting)
Person 1) All is going well, notice this is part is x% slower than expected and their other part is x% faster than expected based on our last discussion
Person 2) Nothing here, all is well
Person 3) I'm stuck on this one part, this is what's going on, this is what I researched, this is how I'm thinking of attacking the problem
Ideas tossed around, move on
Most meetings around here aren't of managers, but of senior developers, architects, and engineers.Some times a manager or two will sit in and listen, but they tend not to say much, but that's more like once per month.
Re:The Number One Impediment is MEETINGS (Score:4, Insightful)
I second this.
Meetings are a big waste of time. Take each person's topics, multiply the time by the number of people, and soon enough you realize that for most people at the meeting, they are wasting 1 / (n-1)*T of the meeting time (T), with n-people.
I'd rather send out an email, "Working on module X, starting connection to module Y" and keep working. Yeah, there's value in keeping up with your peers' work, but this is not worth an hour a day, for example. I can go spend that time with the specific people that I am working with and get a lot more out of that than their piece in a meeting.
Other runners up for wastes of time: Power point presentations of nearly any sort, design reviews with non-technical folks, and repetitive "because it's in the contract" presentations.
Re:The Number One Impediment is MEETINGS (Score:5, Funny)
Yeah, there's value in keeping up with your peers' work, but this is not worth an hour a day, for example. I can go spend that time with the specific people that I am working with and get a lot more out of that than their piece in a meeting.
Or, more accurately, you can spend that extra hour of time reading slashdot.
Re:The Number One Impediment is MEETINGS (Score:5, Interesting)
But the money part is, charge the meetings to another department. When finance calls for a meeting to check on progress, bill back the time spend preparing for and attending the meeting to finance. When they see $10,000 hit their budget for a one hour meeting, they'll never call another meeting. If they are all internal IT meetings, then the "fix" is to replace the CIO/director/manager, so you live with it.
And Slashdot (Score:4, Funny)
Trolling Slashdot generally eats up 50% to 80% of my work day.
The rest of the time in meetings or organizing meetings for later.
Re:The Number One Impediment is MEETINGS (Score:5, Interesting)
Right now I'd say that Scrum is the biggest source of unnecessary meetings in this industry. I think the principles of agile development are great, but Scrum is a bad way to do it.
Weekly planning meetings, demos, retrospectives, and worst of all: daily standups at a rigid morning time. Not good for night owl engineers who want to sleep in or for early birds who get to work too soon before the meeting because it introduces a big context switch.
Instead of all these meetings, why aren't there more companies that just solve their accountability problems with tooling? My solution: Git + Bugzilla eliminates the need for all these meetings except the occasional demo.
Here's how:
Want to put a feature on the release calendar? File a bug. Want to prioritize features/bugs for an upcoming release? Fiddle with the bug priorities. Need input from an engineer about whether or not the priorities make sense based on dependencies? Meet with one or two senior engineers privately just on that topic. There goes all those massive planning meetings.
Want to know what someone is working on? Make all developers work in their own git branches. Ask developers to name their branches after the bug number they're working on. Ask the developer to commit their code daily, whether it's finished or not. That way anyone can check on their progress. When the developer finishes his task, merge the branch into master and close the bug. There goes all those redundant daily standups.
Re: (Score:3, Insightful)
I'm going to politely disagree with you on some points.
Agile and Scrum (in theory) are wonderful tools, but once you get away from the blessed toolset and modify it for your usage it becomes a nightmare.
Case in Point: My team started having daily 10 minute status meetings. Some of us learned how to manage expectations in the meeting and kept our updates under 30 seconds. Others spend several minutes communicating to the entire team about something that could/should be taken offline (or to a subgroup). No
Re:The Number One Impediment is MEETINGS (Score:5, Informative)
One of the points of the "scrum master" role is to keep the meetings a reasonable length. The correct response to "someone is always too verbose" is for them to corrected by that person until they stop. If you're going to claim you follow this method, you cannot ever let the time boundary expand to fit however much people want to say. The feedback loop doesn't go in that direction; it goes toward adjusting the inputs until the length is on target.
Re: (Score:3)
The long duration ones are taking even longer.
In that case, whoever's running the meeting isn't doing their job.
One team I worked on used to pass a 2-minute timer around the meeting; it worked wonders.
Re: (Score:2)
When you're "online" having a meeting, pushing a discussion out of it is taking that part "offline". It's not a great way to have co-opted the term, but it's so standard now it's right at the start of the wikipedia entry on online/offline [wikipedia.org].
Re: (Score:3)
I'm no fan of Scrum, but I wouldn't presume that it can be replaced entirely by some accountability tools. The "What have you done since yesterday?" part of the meeting can certainly be replaced with a scan of commits, and letting that part of the meeting go on far too long is a problem at a lot of places. Replacing "storytime" with a bug entry that's actually a feature description is also more useful than most ways to save that information. It helps integrate bugs and features into one view of the devel
Re:The Number One Impediment is MEETINGS (Score:4, Informative)
Not that I love Agile, but as someone who was trained as a Scrum Master let me just state that the standups are only there to remove obstacles. If your Scrum Master is letting people drone on and on, they need to be noting the issue and telling them to take it up outside of the meeting. In no way should a standup be some sort of general status meeting or a bitch session. It's just there so that you can inform, in bullet point shortness, the Scrum Master of those obstacles and so that the rest of the team is aware of them. That's it. If they last 20 minutes, that's probably 15 minutes too long.
And no, Agile or not, meetings are necessary and there's really no substitute for a face to face in a team setting. That said, meetings easily become time sinks because moderators have no idea how to run them. A good moderator has an agenda, a set of goals to take away, and keeps things on track firmly.
The reason why meetings are almost universally seen as time wasters is that meetings are almost universally run by people who have no idea how to run meetings.
Re: (Score:3)
yes.
but try to implement this - and every person has their own "favorite" bug-tracker and source-control system. (not bugzilla and git). And good luck to you trying to integrate dozens of bug-trackers rcs's into the rest of your org's infrastructure. (not to harp specifically on rcs's and bug-trackers, but it seems to be one of the real sore points that developers can't agree on. . . tools-wise. - - - oh, I guess we all like to agree-to-disagree on IDE's as well. . . . )
Re: (Score:2)
Just remember, if you want to avoid meetings, you shouldn't start complaining that you were left out of the loop for anything new.
Re: (Score:2)
Because meetings are the only way to let people know about something new, of course.
Re: (Score:3)
Meetings themselves are not really the problem, they are a useful tool for discussion. I have found the bigger issue is different people not respecting varying priorities and needs of others. Often people do not take into account when meetings that benefit their needs are cutting into the time of people for whom they are not and then fail to make it worth their while (or at least ackn
Re: (Score:2)
Required reading:
Read This Before Our Next Meeting [amazon.com]
It costs $5 - everyone should get a copy. Seriously, this completely changed the way I work.
Re:The Number One Impediment is MEETINGS (Score:5, Funny)
Re: (Score:3)
What a developer thinks, but not what managers who actually sees the forest through the trees think.
The guy who knows what he is going off and does his thing. No one meets or talk. Developers later finds out someone else was doing the same thing or solved the same problem.
Meetings can increase productivity if they have a point, use some kind of software to manage work originating from (like Trello), and have general rules.
You can take my daily standup meeting from my cold dead hands.
Bad meetings are just th
#1: dumb developers (Score:2)
The #1 impediment to developer productivity is developers writing code that does the wrong thing. #2 is writing code that doesn't work.
Blame meetings all you want, but realistically speaking most developers are totally clueless.
Even this question is dumb. It's basically asking "how do we write bad code faster?"
Re:Beg to differ & WHY... apk (Score:5, Funny)
I wanted to "FOE" you... (Score:2)
but you're an Anonymous Coward. Dammit.
Re:SCRUM (Score:5, Informative)
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.
fix it later (Score:5, Interesting)
Re: (Score:3)
Re:fix it later (Score:5, Insightful)
you're already having trouble meeting a deadline
Artfical deadlines imposed by management are a major suck of productivity.
Re: (Score:3, Interesting)
Many deadlines are not artificial but are imposed by the physical world you live in. Crops are sown and harvested on nature's deadline, you don't do it right you can lose your farming business.
Airlines and all other shipping businesses have deadlines, mining operations have deadlines, retail has deadlines, etc.etc. These are often tied to natural seasons but also to fiscal seasons, to interest payments, to loan terms renegotiations, business deal renegotiations, etc.
To you many things may seem arbitrary b
Re: (Score:2)
Often getting paid improves productivity.
If you try to get your product perfect, you run the risk of releasing an obsolete product, as well the cost of the development operation is running in debt until you can start selling the product.
Re:fix it later (Score:5, Insightful)
Not to your customers ... shitty bug ridden releases which should have spent more time in DEV and QA are a nuisance.
And usually either mean management are lousy at setting release dates, or the developers are lousy at living up to them.
Your customers don't want to QA your code for you.
Re:fix it later (Score:5, Funny)
"I'll fix that bug later" is legit when you're already having trouble meeting a deadline, better to meet it with a buggy product and fix it during QC than not deliver.
...
Ballmer, is that you?
Ducks to avoid flying office chairs
Re: (Score:3)
"I'll fix that bug later" is legit when you're already having trouble meeting a deadline, better to meet it with a buggy product and fix it during QC than not deliver.
This is an example of the kind of bad idea that slows developers down. Would you rather be a day late getting the product to QA, or 10 days late getting the product to the customer? Fixing the bug now, when it is right in front of you, saves time compared to waiting for it to get to QC.
Re:fix it later (Score:4, Insightful)
Re:fix it later (Score:5, Insightful)
Your post is an excellent example of how a bad culture encourages bad decisions by developers. The company culture rewards the just mash out the code with known bugs for QC to find approach, then sliding the fix in when someone else "catches" it. A better culture would be to enter the bug in tracking yourself if the code is needed immediately and you don't have time to fix it before a drop dead deadline.
Re:fix it later (Score:5, Insightful)
There are two strategies to deal with bugs; i'll fix it now or ill fix it later.
Cost for i'll fix it now'
X number of hours of developer time.
Cost to fix it later.
Time for QA to find bug.
Time for QA to document bug in replicatable manner.
X number of hours to fix bug
y number of hours to re-equant with code surrounding the bug.
QA time to test bug and verify it is fixed.
In effect by not fixing a known bug while trying to meet a deadline all you are ensuring is that the next stage will be late and the whole project will be even later. There is no time saved a a lot of time wasted. There is an applicable saying "you can pay me a little now or a lot later". Burying issues is never a good idea.
#1 visiting slashdot (Score:5, Insightful)
#1 visiting slashdot
Re: (Score:2)
Re: (Score:3)
And replying to slashdot articles and comments.
Re:#1 visiting slashdot (Score:5, Funny)
Actually, going on available data from my years of reading Slashdot, hearing everybody bitching about every conceivable IDE, dev tool, library, language, storage system, network, computer, smartphone, and compiler, plus the fact that anyone who has anything good to say about any of those is an obvious shill, I'd say the thing that impedes software developer productivity the most is software development.
Wouldn't that be...... (Score:5, Insightful)
...software patents?
TPS reports and other BS paper work / time tacking (Score:2)
TPS reports and other BS paper work / time tacking / ect...
Benefit of TPS (Score:2)
Stuff that makes a developer wait. (Score:5, Interesting)
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).
Re: (Score:2)
42 (Score:5, Interesting)
Re: (Score:2)
That, and free booze.
Re:42 (Score:5, Funny)
Yeah, I've been meaning to stop doing that.
Easy answer; (Score:3, Funny)
Institutionalized Waterfall (Score:4, Interesting)
Management who believes that every project must be analyzed, then designed, then coded, then tested. The IIC in our company has never written a line of software yet has built an organization that prevents anyone else from doing it efficiently, either. Since we have no development teams, just handoffs of work products, there isn't even a chance to get the right people together to do agile or even iterative work.
If we were even 5% as efficient as the rest of you developers, I would be absolutely amazed.
Re:Easy answer; (Score:5, Interesting)
No, not at all. Remember the Dilbert Principle: The dumbest people in your organization should be promoted to where they do the least damage, i.e. management.
Lawrence J Peter described the same phenomenon as "Percussive Sublimation", and mentioned one film company that practiced this on a grand scale: They built a new Head Office, hundreds of miles from any studio or camera, and promoted all the useless people to work in the Head Office, where they busily ran around conferring with one another and otherwise wasting time, while the useful people happily worked in the studios making films.
So that's the point of management: Remove useless people from the code repo.
Re: (Score:3)
I'm sorry, but do you think they're going to leave the howler monkeys alone, unattended, and not check up with them?
The walls would be covered in feces, the coffee would be all gone, and everybody would be playing video games or surfing porn instead of doing any actual work.
Even when I was a developer it was fairly obvious that without adult supervision nothing would get done. The developers would be writing cool features nobody wants, optimizing code which is
Another Big Impediment (Score:5, Insightful)
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.
Re:Another Big Impediment (Score:4, Interesting)
as our policy is to not promote changes to anything that 'already works.'
If this policy is in place, it's because management doesn't trust you. You need to do some introspection, is there a reason they don't trust you? Are you capable of making those changes without adding new bugs and causing problems? If then answer is no, then there's a good reason they don't trust you.
If you are capable of making changes, then you can train them. Start by making small changes and not adding bugs. After a while you'll be able to convince them to let you make bigger changes, because there haven't been any horrific bugs that have gotten through in a while, and they'll forget why that policy existed in the first place.
TFS (Score:2, Interesting)
Too Much Documentation (Score:5, Interesting)
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.
Re:Too Much Documentation (Score:5, Insightful)
I have never, ever, in my life seen too much documentation. I have rarely seen anything that was even close to sufficiently documented.
Re: (Score:3)
Too much documentation doesn't imply sufficient documentation.
Places that do too much documentation tend to document the most useless details possible, not the usefull large picture vision.
Lack of flexibility; misaligned communication (Score:5, Interesting)
Imagine a manager who asks you about what helps you be productive, and what is slowing you down, then works to change your working environment, schedule, hours, etc. to maximize your quality of life & productivity....
Naturally, it's not common, because instead managers assume their developers won't know the first thing about their own work habits (and what improves/degrades them), and instead blindly tries to establish top-down processes that will make "the team" more productive.
Sometimes it'll work out; but to be sure, people are individuals, the best developers are *already* thinking about these things (and how to hack their own lives), and the ones that aren't will become better if they're encouraged to think about how they actually work.
One thing that applies to everyone, at a general level -- getting the level (and kind) of communication right.
Some people can't get difficult tasks done unless they can retreat into a silent bubble for days on end, free from distractions and completely focused. Most people, however, need at least some level of communication along the way, to intercept them (and help) if they're getting bogged down, getting lost and attacking the problem via brute force, or getting tangled up in their own perfectionism and spending way too much time polishing the first step when they have 19 steps of the solution still to go.
So they need regular (but short and very focused) communication where they're comfortable honestly discussing where they are and where they're going. (Hint: it's hard to avoid triggering ego traps in these kinds of discussions, but if you do, you'll quickly make the whole relationship completely dysfunctional, and useless).
Other people thing best in conversation, and will work best when more-or-less permanently paired with someone else (with similar needs, of course... don't pair them with the solo deep thinker!) -- together they can be far more clever and productive than they could possibly be separate.
Re: (Score:2)
The phone (Score:4, Insightful)
Having to answer the phone is a big one, I find. First is the interruption of the ringing phone itself, then the interruption in your thought process because you have to shift gears to answer someone's question, then the scramble to try and remember what you were doing before you were interrupted.
For me, it's a distracting environment (Score:5, Insightful)
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.
Re:For me, it's a distracting environment (Score:4, Insightful)
That is bad, but I think much worse is a geographically dispersed "team" (like some people on US east coast, some west coast, some Asia, some Europe). Come in at 9AM, need to ask a question of another team member who won't be at work for another 12 hours, wait a whole day for a simple response, repeat as needed.
The Number Two Time-Waster is "REPLY-ALL" (Score:5, Insightful)
It should really be renamed the I'M-COVERING-MY-ASS button.
As has been covered on /. before, this button is increasingly being disabled within corporations, and only to good effect.
Offshoring (Score:5, Insightful)
Multitasking between unrelated activities (Score:5, Insightful)
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.
Re:Multitasking between unrelated activities (Score:4, Insightful)
How about a team lead that text, calls or drops by every 30 minutes like clockwork? How am I supposed to get anything done when he interrupts my train of thought 15 times a day?
Libraries and Documentation (Score:3)
Constant new "Top Priorities" (Score:5, Informative)
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.
So, now even posters don't RTFA? (Score:2)
From the Summary:
(Emphasis mine)
From TFA, first fucking paragraph:
This study's results have been misinterpreted to a completely ridiculous degree. They found that environment, i.e. level of noise, "population density" of the office, etc., was the deciding factor. Please read the stud
The most stupid company (Score:5, Interesting)
Requirements and Replacements (Score:3)
The biggest hit to my productivity is bad requirements, which usually comes directly from the lack of empowerment of the developers. We know bad requirements when we see them, but rarely do we have the ability to push back. However, we all know, without good requirements you can't deliver a good product without unnecessary iterations, much less design for future usage and so on. The best you can do is make a series of somewhat-related mediocre guesses about what needs to be done. Then wipe half of it out when the team comes back because they were smoking meth during the planning phase.
The second biggest hit to my productivity at any given job is when it's implied or expected that any programmer can and will wear every hat associated with every piece of network or computer hardware and software. That they're some sort of universal replacement for every skilled job that includes computers.
If I write Java code, why would you expect that I'm the right person to install SAP? What about writing a file parser indicates I know how to make complex custom graphs in excel, can administer 250 windows servers, will fix the toner cartridge on the printer, will crawl under desks to track down a bad network cable, or should be troubleshooting a customer's firewall configuration, or building a QA test environment?
Even when I do have those skills, it is not very efficient for me to be multitasking on an hour-to-hour basis. Hard to get into, and stay in code-mode with constant context switching.
Generally, interruptions (Score:5, Informative)
Interruptions and a poorly designed work environment that encourages them. Right outside my cubicle is a BIG OPEN AIR MEETING ROOM with included MEDIA CENTER.
OK, so BIG OPEN AIR MEETING ROOMS are bad. Very bad.
Other bad things:
Speakerphones. Damn things should be destroyed on sight. There is no reason for anyone not in an office to have a speakerphone on their desk. Any "manager" who says developers in cubicle farms need speakerphones should be fired. Don't allow speakerphones on the same *floor* as the development team, except inside of small, well-sound-isolated offices.
Not enough meeting rooms. Encourages people to do what I'm hearing right now, which is stand around between cubes and have loud conversations.
Phones in general. The only people who call me are recruiters or customers who got lost in our phone system and got me by mistake. Which of those 2 groups do you want me to talk to?
Bad climate control. Too hot in the summer, too cold in the winter.
Requirements to be on email or messenger at all times are counterproductive. They let managers feel important, but that's the only benefit they have.
Cell phones with obnoxiously loud ringers left on desks. I tell my team "in your pocket or on silent" is the rule for all cell phones. Anyone in violation of this rule that receives a call returns to their desk to find their phone turned off and the battery removed if possible. If they find their phone at all. I've hidden them in the ceiling before.
Here's a list of the seating assignments I've been given in buildings:
Share a conference room with other developers.
Re: (Score:2)
Re: (Score:2)
Years ago at another job, one of the only vacant cubicles was smack dab in the middle of all of the developers (and ONLY developers).
One day a visiting idiot decided to put his speaker phone on so he could listen to a con-call, and work while he was muted.
Eventually I walked over and hung up the phone on him -- naturally, he was shocked and thought I was being rude. I
Having to deal with freelance web developers (Score:2)
Nothing more annoying than trying to come up with verbiage and staged photos for the Freelance Wed Developer' hired by management to invade every office and try to get a "broad picture" of what your section does on a day to day basis for some fluff piece in the Who We Are section for the 27th rewrite of the corporate web site.
And woe be to any department head that sends the web developer packing for interrupting actual WORK, after the whiny pimple faced kid reports back to management that they are getting r
Chit chat (Score:2)
Don't get me wrong. He's a nice guy. Friendly. Smart. But he's gregarious, while I want nothing more than to retreat to my cube and get back to work. The guy just can't take a hint that the conversation is over and it's time to leave. Show any
Strong typing (Score:3)
Strong typing. LOL
Working environment (Score:5, Insightful)
You want me to be productive as a developer? OK, here's what I need to do that:
A comfortable workspace. Give me a good solid desk with drawers and shelving to store reference and work materials. A phone with a headset so I can hold a conversation and work on the computer at the same time. A comfortable chair. Not one of the $99 specials from Office Depot, something high-end that's rated for 8 hours of continuous use. If what you're providing for an office workspace isn't at least as good as what I can afford personally at home, there's probably something wrong.
A good computer. It needs to have enough CPU horsepower and enough memory and disk for the software you expect me to be using. And it needs to be better than the minimum spec, I can't be productive when my tools are barely limping along. Good monitors too, and more than one. I'm going to regularly be pulling up digital reference materials and I'll have a lot of work on my screen, I need the screen real-estate to have all of it available without constantly having to shuffle windows to the top. You want to understand why, try doing your work with only one sheet of paper visible at a time and if you need to refer to 2 reports at once you have to lay one on top, read it, pull the other one out and lay it on top to read it, lather rinse repeat. If you don't think you can be productive working that way, why should you expect me to be?
Give me the reference materials and tools. If you expect me to work with tools or systems, give me all the documentation on them. It doesn't have to be physical, but it has to be available and up-to-date. If you want me to work on something, give me the tools to work on and with it. IDEs, editors, file comparison tools, merge utilities, it's possible to not skimp without going overboard. If you want me to work on software that accesses a database, give me a database client and access to those databases and a personal database I can play with to test things before I break the world for everybody else. If you want me to work on a system, set it up so I have my own installation I can put changes into to test. And for crying out loud, give me documentation on how to set it up and configure it and use it so I'm not completely lost going in.
Give me the ability to work uninterrupted. I know open-plan offices are all the rage, but you're expecting me to do work that requires high concentration for hours at a time. I can't do that with every conversation in the office distracting me, or everybody coming over randomly with questions or conversation. Same for phone calls. People should not be calling developers directly unless the developer's asked them to. If you need to, hire a receptionist to field calls and route them where they need to go (as opposed to where the caller wants them to go).
Let me work on my projects. I have a priority list. I use it to decide what things I should focus on now. But it doesn't do me any good if the priorities are constantly changing. I know, I know, the old saw about responding to business needs. Think a minute: maybe the problem isn't that I need to respond, but that business needs to start thinking more than a few days ahead? If requirements for a new project are constantly changing, perhaps you just don't have a good enough idea of what you want to start actual work on it yet. One of the worst ways to kill my productivity is to give me just enough time to get a handle on a project and start work, then make me drop it and start on a completely different project, and keep doing this repeatedly. When you pull me away from project A to work on B, it costs project A more than just the time I was working on B. The distraction will make me forget some of the details of what I was working on for A so when I get back to it I won't be able to just pick up where I left off, I'll have to backtrack and spend time remembering my train of thought and reconstructing all those details before I can start working again. So try to settle the priority lists down so they're not changing on a daily b
Re: (Score:3)
Give me the ability to work uninterrupted. I know open-plan offices are all the rage, but you're expecting me to do work that requires high concentration for hours at a time. I can't do that with every conversation in the office distracting me, or everybody coming over randomly with questions or conversation. Same for phone calls. People should not be calling developers directly unless the developer's asked them to. If you need to, hire a receptionist to field calls and route them where they need to go (as opposed to where the caller wants them to go).
I recently switched to an office and I'm not sure single person offices are the trick, I feel my productivity has gone down rather than up. I'd rather go with team rooms - if you're working on the same project/area, you sit together but under no circumstances more than 2x4 people islands and no mixed rooms. However, this requires you to have a bit of headroom so you can leave seats idle and don't need to do a full reshuffle or knock down/put up walls all the time. Also small discussion rooms you can ad hoc
bad Junior Developers (Score:2)
Checking in buggy code that wastes QA's time and blocks me from working on something.
Working for weeks on a file without doing an update and then end up overwriting my changes and breaking them.
Math Test (Score:5, Interesting)
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]-
Noise (Score:5, Informative)
I program better when I am in a quiet environment.
I have been amazed how hard it is to get work done in cube farms, especially when there are people nearby whose job it is to talk on the phone often.
A few gigs like that made me invest in these. They work as well as ear plugs but without the inconvenience of roll and stuff them:
http://tinyurl.com/cw33u3x [tinyurl.com]
There is this popular article about research that shows that quiet and solitude boosts productivity, including for developers
http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all&_r=0 [nytimes.com]
If an org will not pay for real offices they should consider separating people with noisy jobs ( phone use ) from others and make some rules about noise levels
Boy, where to start... (Score:5, Interesting)
I think the biggest thing is probably "assuming that the same practices are good or bad for everyone". Consider "face time"; this ranges from essential to disruptive depending on the people involved. If you don't make sure that your socially-oriented developers are getting the human contact they need to be engaged, you are crippling them. If you don't keep your non-socially-oriented coworkers free from disruptive enforced socializing, you are crippling them. So if you pick a policy, and use it for everyone, you're likely hurting productivity.
Honestly, though, the biggest thing I've seen, by far? Blame. When I have worked places where there was a focus on identifying fault and trying to punish failure, it meant that the bulk of effort in responding to issues was spent on identifying or avoiding blame. Where I work now, the corporate culture is that we all know we make mistakes (although I like to think I make more of them than anyone else; I have a spectacular track record in that regard), and we also know that in nearly every case, any of several people could have prevented something. If code goes in that breaks something, and I reviewed it, I don't say "oh, there's no way I could have known that would happen", I say "whoops, my bad, I reviewed that one".
And that means that, when something goes wrong, we have the best information we can have about what went wrong and how as soon as possible, and we can focus on fixing it. And "fixing it" doesn't mean "sitting around waiting for the person who screwed up to be around to fix it", it means "best fit of availability and schedule". I will fix mistakes I didn't make, other people fix mistakes I make, and we get stuff done.
I basically laugh when people ask me whether I'm looking for work. :)
Comment removed (Score:4, Insightful)
Constant interrup-interupt-interuptions. (Score:3)
I love this one. One of my bosses loves to tell everyone to leave her devs alone; the switching cost is too high. Five minutes later she'll yell across the room and ask a question that completely derails said developer and then can't understand why it takes so long to get things done. "You were able to switch to answering my question, why can't you switch back?" Fuck.
Re: (Score:2)
Well that was a link fail on my part. I had intended to post this:
Nuff said. [thedailywtf.com]
Re: (Score:2)
Re: (Score:2)
Nothing more unproductive than continually changing requirements/specs
Isn't "continually changing specs" another term for "Agile"?