Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: What Practices Impede Developers' Productivity?

Soulskill posted about a year and a half ago | from the mitten-mondays dept.

Programming 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?"

cancel ×

457 comments

Sorry! There are no comments related to the filter you selected.

The Number One Impediment is MEETINGS (5, Insightful)

Press2ToContinue (2424598) | about a year and a half ago | (#42560753)

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 (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42560867)

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 (5, Insightful)

AliasMarlowe (1042386) | about a year and a half ago | (#42561089)

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:And then there's the PAY (1)

Anonymous Coward | about a year and a half ago | (#42561337)

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.

That would work for me provided nobody gave me any shit for going home after I've done 40 hours worth of work in 20 hours....

Re:The Number One Impediment is MEETINGS (5, Insightful)

schlesinm (934723) | about a year and a half ago | (#42561289)

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 (0)

Anonymous Coward | about a year and a half ago | (#42560883)

Meetings where somebody demands to know when I will deliver something they farted up while updating their linkedIn profile.

Re:The Number One Impediment is MEETINGS (3, Insightful)

gnu-sucks (561404) | about a year and a half ago | (#42560899)

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 (5, Funny)

Anonymous Coward | about a year and a half ago | (#42561121)

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.

And Slashdot (4, Funny)

Anonymous Coward | about a year and a half ago | (#42560913)

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:And Slashdot (1)

cod3r_ (2031620) | about a year and a half ago | (#42561145)

beat me to it. If slashdot went away we could probably solve our debt crisis..

Re:And Slashdot (0)

Kergan (780543) | about a year and a half ago | (#42561187)

And if email was away as well, we could probably solve our economic crisis.

Beg to differ & WHY... apk (-1)

Anonymous Coward | about a year and a half ago | (#42560983)

#1 - Code reviews are GREAT meetings (they make the TEAM stronger) - not enough companies DO them! They HELP the rookie coders/noobs KNOW what they're doing, stop them from being fearful of saying "guys I need help, I don't KNOW how to do this!" & that makes a WORLD of difference... stress? KILLS!

#2 - Those people you CLAIM "don't know what they're doing", as in users I assume? DO, especially in accounting, finance, shop floor & more!

---

I.E.-> THOSE ARE WHO KEEP YOU WORKING & IN A JOB & usually are FAR MORE EXPERT than you are as a developer - by far on ALL levels, not just their particular discipline, but also the process and sometimes, even WHERE TO GET THE DATA (saving nagging the DBA or Business Analyst for example).

Including me too - & I've actually GOT a B.S. in Business Administration with an MIS concentration/minor to go with my AAS in CS!

Meetings with the users an app's intended to empower?

HEY- it's helped ME understand what they want, BETTER - since they also know the BUSINESS PROCESS often quite perfectly but just don't KNOW HOW TO AUTOMATE IT THEMSELVES (& initially? I doubt you do as a coder!)

---

* Lastly: KEEP THIS IN MIND - This is ME, speaking from 18++ yrs. of professional development in business systems!

(From tiny departmental reporting apps, all the way up thru "mission-critical"/"enterprise class" distributed systems that were also many times, cross-platform... as well as doing well in freeware/shareware & even COMMERCIALLY SOLD CODE 1996-present day that bears my name from a certified MS partner (that reviewed great in Windows IT Pro (then Windows NT/2000 magazine) as well as placing as a FINALIST, 2 yrs. in a ROW, @ MS Tech Ed 2000-2002, in its hardest category: SQLServer Performance Enhancement for code AND how to apply it, for up to a 40% boost in speed!).

APK

P.S.=> I've worked with devs like you before - you're a FOOL for believing that meetings "harm you"...

Since again: IF anything?

Meeting with the folks YOU WORK FOR (not they for you, as a dev., you are a TINY COMPANY inside the company, nothing more, & there to help enable those "dumb users'" do a BETTER JOB!) - helps!

Code review meetings even MORESO...

... apk

Re:Beg to differ & WHY... apk (5, Funny)

gabereiser (1662967) | about a year and a half ago | (#42561075)

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.

Re:Beg to differ & WHY... apk (-1)

Anonymous Coward | about a year and a half ago | (#42561321)

This guy is a long time troll. He's a known psychopath, who lives with his mother and has been on record to abuse women. Just Google for "Alexander Peter Kowalski" and you will see what I mean. He really does need help.

I wanted to "FOE" you... (1)

Press2ToContinue (2424598) | about a year and a half ago | (#42561133)

but you're an Anonymous Coward. Dammit.

SCRUM (1)

Anonymous Coward | about a year and a half ago | (#42561013)

These are daily meetings which are designed to coerce engineers to report progress. That may work for some things, but not others. Can you imagine C and Unix being developed if Bell Labs had hired a random manager (and most managers are random) to conduct scrum meetings on Thompson's and Richie's lab?

Re:SCRUM (5, Informative)

Trepidity (597) | about a year and a half ago | (#42561085)

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.

Re:The Number One Impediment is MEETINGS (2)

gabereiser (1662967) | about a year and a half ago | (#42561015)

more specifically, the meetings about scheduling meetings about a meeting that just took place that required a meeting to discover what the resolution to the last meeting is and hold a meeting about the results. STOP WITH THE MEETINGS!

Re:The Number One Impediment is MEETINGS (5, Interesting)

Kethinov (636034) | about a year and a half ago | (#42561019)

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:The Number One Impediment is MEETINGS (3, Insightful)

Anonymous Coward | about a year and a half ago | (#42561197)

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). Now we've gone to 2x/week meetings that are at minimum 30 minutes long. The 30 second developers are still reporting in 30 seconds. The long duration ones are taking even longer.

Re:The Number One Impediment is MEETINGS (1)

jellomizer (103300) | about a year and a half ago | (#42561179)

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:The Number One Impediment is MEETINGS (2)

jythie (914043) | about a year and a half ago | (#42561201)

Unless of course it is a meeting where the developer is getting information they want or addressing concerns they have....

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 acknowledge the cost to them).

Re:The Number One Impediment is MEETINGS (0)

Anonymous Coward | about a year and a half ago | (#42561261)

No, no no.

The number two impediment is meetings.
The number one impediment is reading and posting to Slashdot.

Re:The Number One Impediment is MEETINGS (2)

dgrotto (2588895) | about a year and a half ago | (#42561343)

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.

source control "tokens" (0)

X0563511 (793323) | about a year and a half ago | (#42560781)

  Filter error: You can type more than that for your comment.

Re:source control "tokens" (1)

X0563511 (793323) | about a year and a half ago | (#42560785)

Well that was a link fail on my part. I had intended to post this:

Nuff said. [thedailywtf.com]

fix it later (4, Interesting)

phantomfive (622387) | about a year and a half ago | (#42560793)

Saying, "I'll fix that bug later" or "QA will catch anything I miss." The sooner you fix a bug, the less time it will take you. Spending an extra 5 minutes now to verify the documentation for a function you call can save days later on.

Re:fix it later (2)

Synerg1y (2169962) | about a year and a half ago | (#42560889)

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

Re:fix it later (5, Insightful)

sunderland56 (621843) | about a year and a half ago | (#42560991)

you're already having trouble meeting a deadline

Artfical deadlines imposed by management are a major suck of productivity.

Re:fix it later (4, Insightful)

gstoddart (321705) | about a year and a half ago | (#42561047)

better to meet it with a buggy product and fix it during QC than not deliver.

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 (4, Funny)

CanHasDIY (1672858) | about a year and a half ago | (#42561077)

"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:fix it later (2)

phantomfive (622387) | about a year and a half ago | (#42561259)

"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 (1)

Anonymous Coward | about a year and a half ago | (#42561303)

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

Have you gotten your customers' opinions on that topic?

Are you a gamer? Do you prefer your games late and polished or rushed and buggy?

Re:fix it later (0)

Anonymous Coward | about a year and a half ago | (#42560925)

lol, unless (like me) you work in a company where fixing a bug (regardless how big it is -- one char or half of app) always takes few weeks. In this case you say 'I am going to fix it later' and never return to it unless directly ordered by manager.

Re:fix it later (0)

Anonymous Coward | about a year and a half ago | (#42560951)

"I'll fix that later" is often what a product team's incomplete stories require the developer to do.

Health and Safety meetings. (1)

Anonymous Coward | about a year and a half ago | (#42560797)

Nothing I like less than spending three hours being told the correct way to use a keyboard by a failed art history student that can't type.

#1 visiting slashdot (5, Insightful)

Nadaka (224565) | about a year and a half ago | (#42560805)

#1 visiting slashdot

Re:#1 visiting slashdot (1)

Capt.DrumkenBum (1173011) | about a year and a half ago | (#42560911)

I have been thinking about blocking Slashdot. I bet even my own productivity would go up.

Re:#1 visiting slashdot (2)

Dishwasha (125561) | about a year and a half ago | (#42560949)

And replying to slashdot articles and comments.

Re:#1 visiting slashdot (5, Funny)

Anonymous Coward | about a year and a half ago | (#42561241)

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...... (5, Insightful)

3seas (184403) | about a year and a half ago | (#42560809)

...software patents?

TPS reports and other BS paper work / time tacking (1)

Joe_Dragon (2206452) | about a year and a half ago | (#42560823)

TPS reports and other BS paper work / time tacking / ect...

Benefit of TPS (1)

tepples (727027) | about a year and a half ago | (#42560979)

How does a test procedure spec (TPS) impede developers' productivity? An effective test procedure helps a developer know whether his work is close enough to correct to be releasable.

Woosh (0)

Anonymous Coward | about a year and a half ago | (#42561099)

How does a test procedure spec (TPS) impede developers' productivity? An effective test procedure helps a developer know whether his work is close enough to correct to be releasable.

Woosh

Stuff that makes a developer wait. (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42560827)

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:Stuff that makes a developer wait. (1)

tepples (727027) | about a year and a half ago | (#42561005)

Did you try logging the total amount of time that you spent waiting for the IT group to transfer files as a percentage of your work day?

42 (5, Interesting)

Jetra (2622687) | about a year and a half ago | (#42560829)

Procrastination is the Number One Productivity Impeder (Not sure if right word, but spellcheck isn't getting me)

Re:42 (1)

rve (4436) | about a year and a half ago | (#42560903)

That, and free booze.

Re:42 (0)

Anonymous Coward | about a year and a half ago | (#42561107)

One anonymous tech organization wanted mandatory attendance at meetings with free beer.

I could never understand how they planned to accomplish anything. I think it helped they specialized in technical support. I never submitted my resume.

Re:42 (0)

Anonymous Coward | about a year and a half ago | (#42561025)

Procrastination, the primary impediment to productivity.

captcha: audited.

Re:42 (5, Funny)

Anonymous Coward | about a year and a half ago | (#42561053)

Yeah, I've been meaning to stop doing that.

Procrastination getting a bad rap (Was:42) (1)

Anonymous Coward | about a year and a half ago | (#42561117)

Procrastination is the Number One Productivity Impeder (Not sure if right word, but spellcheck isn't getting me)

If you took computer science, you know that procrastination has its place in productivity enhancement.

If you know (for certain) that you have to do something, then do it as soon as possible.
If you don't know if you need to do something, then delay doing it until it is certain that you need to do it.

For example, there is no sense computing every value in a huge lookup table because a single value on that table is referenced once. By procrastinating on the other table values, you hope the programs ends before they are needed. It then saves the CPU for something the user actually wants to do (i.e.: boosts productivity).

Posting on Slashdot... (0)

Anonymous Coward | about a year and a half ago | (#42560835)

When you should be working.
That means you "Soulskill," or should I say Matt.

Also, you're fired.

Re:Posting on Slashdot... (0)

Jetra (2622687) | about a year and a half ago | (#42560897)

If you're really his boss, kudos to you.

Easy answer; (2, Funny)

Stumbles (602007) | about a year and a half ago | (#42560841)

Anything that involves a person in management.

Institutionalized Waterfall (3, Interesting)

plover (150551) | about a year and a half ago | (#42561031)

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; (4, Interesting)

dkleinsc (563838) | about a year and a half ago | (#42561115)

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.

Another Big Impediment (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42560849)

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 (3, Interesting)

phantomfive (622387) | about a year and a half ago | (#42561307)

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.

There are plenty (0)

Anonymous Coward | about a year and a half ago | (#42560863)

what are the worst practices or problems that impede developers' productivity at an individual or organizational level?

Having to put up with Agile bullshit. The "certified Scrumm master"' wasting your time waving their dicks around.

poor problem descriptions (0)

Anonymous Coward | about a year and a half ago | (#42560893)

I remember finishing a task that was well-defined, only to have the manager want to iterate on it instead of tell me the whole problem for development. I finally told him that I'm a problem solver, and not hired to be a data processor.

Too Much Documentation (5, Interesting)

andawyr (212118) | about a year and a half ago | (#42560915)

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 (1)

Anonymous Coward | about a year and a half ago | (#42561003)

Too little documentation, no overview of a complex system which even the original creators don't understand, no comments, etc. This is usually due to everyone being rushed to get out the next feature. I think it adds a stacking overheard to every change which eventually slows down changes to a crawl.

Z

Re:Too Much Documentation (1)

The Joe Kewl (532609) | about a year and a half ago | (#42561199)

Wish I had mod points to give you. Not the exact same, but still documentation:
I was just forced into wasting an entire day "documenting" what has been done for a project so far because the manager was too lazy just to ask me what had been done, and why it isn't working yet.

Probably never read the doc, and will end up asking me about it anyways...

Lack of flexibility; misaligned communication (4, Interesting)

JavaRob (28971) | about a year and a half ago | (#42560945)

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.

When they start... (1)

Anonymous Coward | about a year and a half ago | (#42560973)

Responding to Ask Slashdot questions.

The phone (3, Insightful)

PhxBlue (562201) | about a year and a half ago | (#42560995)

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.

Re:The phone (0)

Anonymous Coward | about a year and a half ago | (#42561231)

I learned to turn the volume way down and not answer the phone at all. People do learn that the best way to get in touch is via email or instant message. I've also learned to ignore instant messages from certain people as well. You become a lot more productive when you learn that these things are just distractions and you aren't required to respond to them. Now, as a technical lead for my team I do need to be available to help them. Fortunately we are lucky enough to be located all on the same hallway so they can just walk over and chat in person (and get an ergo-break since we have software that enforces them anyway).

For me, it's a distracting environment (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42560997)

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.

The Number Two Time-Waster is "REPLY-ALL" (4, Insightful)

Press2ToContinue (2424598) | about a year and a half ago | (#42561011)

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 (4, Insightful)

mrquagmire (2326560) | about a year and a half ago | (#42561023)

Offshoring any part of the development process.

Using rails (1)

elcheesmo (646907) | about a year and a half ago | (#42561039)

Every time there's a minor version update or security patch released, I spend a day trying to migrate to it.

Chaning the specs (0)

Anonymous Coward | about a year and a half ago | (#42561043)

The worst projects I've worked on are the ones where the developer is given specs/features to implement and then, after those are in place, the spec changes. I've been on projects that have been written and re-written and even re-written again because management couldn't make up their minds as to what their direction should be.

inheritance (0)

Anonymous Coward | about a year and a half ago | (#42561055)

nothing wastes more time than 5 people in a room arguing about the potential abstractive gains of various
inheritance patterns

once the grand new architecture is argued out and all the useless boilerplate written, it turns out
that the design needs to be thoroughly refactored and the process starts again

Summary (0)

Anonymous Coward | about a year and a half ago | (#42561061)

Let me summarize what the typical ./ crowd will say: 1) Meetings; 2) Slashdot; 3) Management;

Multitasking between unrelated activities (5, Insightful)

QilessQi (2044624) | about a year and a half ago | (#42561063)

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 (3, Insightful)

PRMan (959735) | about a year and a half ago | (#42561269)

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?

Inconvenient work situations (0)

Anonymous Coward | about a year and a half ago | (#42561065)

This is a real pet peeve of mine:

"Hey, this old spyware-ridden machine is going to be your computer to check mail and handle time sheets, etc.. Oh, what's that? You want something you can actually work on? Well we have a machine in room X but people come in and use it every once in a blue moon for Y, so that's off limits. However, there's this computer sitting on a 4 foot high table on the other side of the building JUST FOR YOU! It's not connected to the Internet though, so come in with everything you'll need to know in advance. Good luck! Just ask Joe McTenure if you need to get in the office where the machine is located."

Re:Inconvenient work situations (0)

Anonymous Coward | about a year and a half ago | (#42561181)

Haha wow, I know how that is.

Management indecision (0)

Anonymous Coward | about a year and a half ago | (#42561067)

The inability of management to make choices between competing technologies because they fear hurting the feelings of who ever wrote the loosing solution. Sooner or later you will be dealing with a system with mutually redundant parts, each only covering a subset of the relevant use cases. Developing against that kind of thing is just a drag *and* you end up spending much of your time debating which parts should be removed from the system. Ironically that will also hurt the feelings of other developers even more than a straight decision would have done.

Also consider this: One person having to rework something because he or she made a poor choice is the waste of one person's work. But if that one person is a team lead, the poor choice results in wasting all the work of a whole team. If the person is a higher level management type with lots of other managers and their teams below him or her, the waste is going to be enormous. And, IMO, the worst possible choice is often to *not* make a choice.

Context switching (0)

Anonymous Coward | about a year and a half ago | (#42561071)

Switching from one task to another eats up time.

Libraries and Documentation (2)

Jmc23 (2353706) | about a year and a half ago | (#42561081)

Not sure how it is at the corporate level. I just know that I waste way too much time finding out what's available and trying to figure out the documentation. Almost 90% of the time I would have spent less time writing the part I needed. Only exception is CLX.

What is productivity? Not kLoC, please! (1)

Karljohan (807381) | about a year and a half ago | (#42561091)

Number one impediment to productivity is to measure it by the number of lines of codes produced. Alternatively to the quality of the product.

Productivity measure FTFA, if anyone wonders)

My 2 cents worth... (0)

Anonymous Coward | about a year and a half ago | (#42561093)

First, to get it out of the way: the 10x rule understates the case. Somewhere around 40% of the "developers" out there should never write anything more challenging than FizzBuzz, and they may or may not manage that on the first try. Perhaps 10% of the developers out there are really, really good. The difference between then is not a factor of 10, but is infinity, because the lousy developers are incapable of advanced programming.

Ok, external factors:

1. The job of technical project management is to protect the developers. To keep them out of meetings, away from direct customer contact, away from stupid inquiries by upper management. Lots of companies don't get this.

2. Environment. Small offices with only a few people in them, all developers, with an enforced policy of quiet. If you get a phone call, take it out of the office. If you need to meet with two other people, go to the conference room.

Ridiculously inconvenient setups (0)

Anonymous Coward | about a year and a half ago | (#42561111)

"Hey, this old spyware-ridden machine is going to be your computer to check mail and handle time sheets, etc.. Oh, what's that? You want something you can actually work on? Well we have a machine in room X but people come in and use it every once in a blue moon for Y, so that's off limits. However, there's this computer sitting on a 4 foot high table on the other side of the building JUST FOR YOU! It's not connected to the Internet though, so come in with everything you'll need to know in advance. Good luck! Just ask Joe McTenure if you need to get in the office where the machine is located."

Getting Old (1)

flatass (866368) | about a year and a half ago | (#42561137)

No, not the age of the developer, but rather the topic of "If only my workplace conformed to my every whim and just let me work my way I do best, what a invaluable and productive developer I would be!" There is a reason that the unfortunate stereotype of developers being Prima donna's exists. /rant

Constant new "Top Priorities" (5, Informative)

MillerHighLife21 (876240) | about a year and a half ago | (#42561141)

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.

Being too available to the help desk (0)

Anonymous Coward | about a year and a half ago | (#42561151)

Support people want answer from development/engineering when their customers are on the phone with them, but being able to go and pester the engineering staff (like in my company) just results in disrupting the engineer's concentration.

Likewise, expecting engineers/developers to help with support calls when the queues become full really screws productivity way out of proportion to the time spent actually on the phone.

Simple (0)

Anonymous Coward | about a year and a half ago | (#42561167)

There is no project so trivial that a sufficient number of meetings cannot render it impossible.

Open Office Environments (0)

Anonymous Coward | about a year and a half ago | (#42561185)

The idea behind the open office environment is ease of problem solving and brainstorming. From what I've seen, it's more of a distraction than anything.

10 Woes of the Code Monkey (1)

RedHackTea (2779623) | about a year and a half ago | (#42561221)

  1. 1. Not being able to drink beer and/or Irish coffee.
  2. 2. Not being able to curse and/or name something FuckedUpException.
  3. 3. Not being able to use the IDE/TextEditor/OS that we want.
  4. 4. Managers that write shit Functionals.
  5. 5. Support people that write shit re-creation steps.
  6. 6. Not being able to cry and masturbate while you work.
  7. 7. The voices in my head that won't go away.
  8. 8. Having to communicate with someone in-person instead of via email.
  9. 9. Shit coffee.
  10. 10. Having to support IE.

Web development (0)

Anonymous Coward | about a year and a half ago | (#42561233)

Creating an intranet web application which is only ever going to be used by a handful of users.
This will easily take ten times longer than writing an equivalent desktop application, be harder to deploy, test, change, maintain, debug and be far more fragile. Also, it will be harder to rewrite or port to the Next Big Thing in two years when the web container or widget framework you used is deprecated, and will break when the customer department decides to change browser (after insisting it will only ever need to be compatible with IE6), and will perform horribly when they start using a realistic quantity of data.

So, now even posters don't RTFA? (1)

SolitaryMan (538416) | about a year and a half ago | (#42561263)

From the Summary:

When it comes to developers' productivity, numerous controversial studies stress the differences between individuals.

(Emphasis mine)

From TFA, first fucking paragraph:

They found no relationship between a programmer’s amount of experience and code quality or productivity.

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 study and stop proliferating this myth about super-human programming ninjas. We are way more equal in our skills than some egomaniacs would like to beleive.

Salary (0)

Anonymous Coward | about a year and a half ago | (#42561291)

The higher the salary, the lower the productivity. In spain we are one of the most productive european countries: we have *low* salaries. When someone talks about increasing productivity, they mean decreasing cost. This of course doesn't mean that reducing salary is beneficial to the project, and salary is of course not the only way to increase productivity. For example, as it was pointed earlier in a slashdot story, you can increase productivity, exploiting the people, but life expectancy might also decrease.

Of course you can try to improve productivity in better ways, like letting the developer be focused, having efficient team communication and good collaboration environment. This is of course what you should probably do, but I just wanted to point out how wrong things can turn out when you increase productivity in other ways. For example in Spain, in the regional Madrid TV channel they want to reduce costs to increase productivity by laying out +800 workers, leaving 380 in total, of which 180 will be high executives. Good productivity right? No executive is going to be laid out, and when things go wrong because they do bad their work, the workers are to blame.

Axing Projects (0)

Anonymous Coward | about a year and a half ago | (#42561295)

Pick 20 new features for that next release, and assign them to developers. Then once most of the development is halfway done - or finished, start axing about half of them (with no regard to the current state of each) simply because someone can't figure out how to test them - or just doesn't want to make time.

COKE, The kind you drink... (0)

Anonymous Coward | about a year and a half ago | (#42561319)

Free Coke Machine!!!! = Improved Productivity
No Free Coke Machine = Decreased Productivity

The most stupid company (5, Interesting)

slimdave (710334) | about a year and a half ago | (#42561323)

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.

articles from 2008 are news? (1)

koffka (1061592) | about a year and a half ago | (#42561329)

"Published Mar 27 2008, 10:15 AM by Steve McConnell"

Requirements and Replacements (2)

quietwalker (969769) | about a year and a half ago | (#42561341)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>