Slashdot Mirror
Ask Slashdot: What Practices Impede Developers' Productivity?
nossim writes "When it comes to developers' productivity, numerous controversial studies stress the differences between individuals. As a freelance web developer, I've worked for a lot of companies, and I noticed how some companies foster good practices which improve individual productivity and some others are a nightmare in that regard. In your experience, what are the worst practices or problems that impede developers' productivity at an individual or organizational level?"
Meetings are how people who don't know what they are doing suck the productivity out the people who do.
Sent from my ENIAC
Well that was a link fail on my part. I had intended to post this:
Nuff said.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
"First they came for the slanderers and i said nothing."
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
...software patents?
TPS reports and other BS paper work / time tacking / ect...
When I get in the zone I want to write code. I had a job that made you RDP to a development network to use Visual Studio on a machine that didn't have access to the internet (only to source control and the database server) and there was no copy/paste or file transfer to your environment -- you had to get the IT group to move files for you. You couldn't last 'in the zone' for very long before needing someone else's help to do *something*
Hitting brick walls like that, and not being able to take care of your own needs seriously crushes developer productivity (and to a certain extent, morale).
Procrastination is the Number One Productivity Impeder (Not sure if right word, but spellcheck isn't getting me)
Anything that involves a person in management.
My karma is not a Chameleon.
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.
Trolling Slashdot generally eats up 50% to 80% of my work day.
The rest of the time in meetings or organizing meetings for later.
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.
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.
Responding to Ask Slashdot questions.
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.
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.
!#@%*)anks for hanging up the phone, dear.
I might be in a minority, but having a cube-less environment, where everyone is sitting in a huge room, behind a desk and can see and hear everyone else, is the worst. I feel like sitting in a 60's call center. The "goal" of this arrangement is "collaboration". The result is distraction and irritation.
It 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.
Sent from my ENIAC
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?
Offshoring any part of the development process.
giggity
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.
John
Every time there's a minor version update or security patch released, I spend a day trying to migrate to it.
It doesn't matter if we're talking about bouncing between meetings and coding, coding and documentation, or just coding too many unrelated modules -- every time there's a substantial context switch, it takes a little bit for you to get your bearings and get up to speed. Sort of like a vehicle making sharp turns all of the time.
Koans and fables for the software engineer
HOLY capital letters that was a LONG comment... I see where your COMING from but I don't TOTALLY agree. Meetings DO harm you as far as time is CONCERNED. Rarely are YOU exiting the meeting with a better UNDERSTANDING of what the meeting was SCHEDULED to resolve. Most of the TIME its so that some MANAGER can get the people who KNOW what they are DOING in one room to REACH a DECISION. Rarely are meetings beneficial to ALL parties involved which results in TIME loss and PRODUCTIVITY wasted. I'm using GRATUITOUS use of all caps like you HAVE in your response because I'm emphasizing my WORDS so you understand my intelligence level.
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.
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Some meetings are necessary obviously... I'm in my first senior developer position now and I've instituted hard limits on meetings because it frustrates me to no end when idiots discuss minutiae for valuable hours of my team's time.
Agreed, but the actual time spent in meetings exceeds the required time by a significant factor at some workplaces.
Then there's the pay structure. It's almost as if some places want to pay as much as possible for work (paid overtime for panic fixes) or intend it to take as long as possible (long unproductive unpaid overtime). A better approach would be to pay for results, and damn the work time spent to achieve them, provided they meet the schedule. A 20 hour week can be as productive as a 40 hour week, and more productive than a 60 hour week.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
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)
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).
but you're an Anonymous Coward. Dammit.
Sent from my ENIAC
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
I've had managers that constantly try to shift my priorities to whatever has their attention that day. They want me to drop whatever I'm to focus on the most recent urgent pet project.
When it affects cash flow, I fully understand. We need to take care of a big advertiser or something like that, totally understandable. Pretty much everything that doesn't fit in that particular realm though, forces me to tell my boss it will have to wait so I can finish my other 10 urgent projects. The line "everything is top priority" also fits in this realm.
Pivotal Tracker is actually really helpful in this regard because there aren't task lists, there's a queue and something is at the top of it. That is what you work on. If a manager wants you to do something else you force them to de-prioritize your other tasks. It's fantastic in that regard because it forces managers to acknowledge they are slowing down their own requests.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
The G
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 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.
May Peace Prevail On Earth
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.
"Published Mar 27 2008, 10:15 AM by Steve McConnell"
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.
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.
I've been on those projects where management couldn't make up their minds so they just kept me on hold until they did. That's how I found Slashdot.
I worked for a startup with excellent unit testing practices. Productivity was amazing, even when working with older code, because design and implementation errors would be found immediately, when they were easiest to fix. New developers came up to speed quickly because they could *see* dozens of tested use cases of the code they were working on, and their newbie errors were quickly exposed by the tests.
We were acquired by a public company with a manual QA process and no unit tests. Developer productivity plummeted. Formerly 10x-er developers became 2x-ers as they spent massive amounts of time finding and fixing downstream issues every time they did something innovative. This led senior software managers to say things like "You can't change that class -- it is too risky", creating a perverse disincentive to create modular code. The code base was slowly crushed by its own weight, and the 10x-ers all left for greener pastures.
...pretty much everything they say is "good practice." I love it when a highly tested, well covered, well-reviewed piece of code is so buggy it can hardly stay running. It really reveals that no amount of process can compensate for individual skill.
Internet filters/blocks. Low-quality hardware/software. Phone calls. People that do not realize that IM is not for chit-chat. Endless meetings. Noisy people (I've resorted to earplugs quite a few times). Etc etc...
They're there in their room. You're on your own.
Nothing more unproductive than continually changing requirements/specs
Isn't "continually changing specs" another term for "Agile"?
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 resistance.
Sig Battery depleted. Reverting to safe mode.
That guy who comes by and lingers around my cube making idle chit-chat because he's bored out of this gourd and/or simply doesn't want to work. So he drags me down into that narfarious pit of unproductivity by making smalltalk about.... FOOTBALL... of all things.
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 amount of interest and he reves up into another 5 minute one-sided discussion. Ugh.
Strong typing. LOL
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
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?"
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 impropmtu get-togethers with a couple of people in the bosse's office more effective than big meetings in the conference room?
I'm confused. What about your meetings make them good meetings?
Asking questions every 5 minutes on basic things they should already know.
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.
The Official Site of 1337 Pwnage
Oddly enough it also helps developers stay on task and not over-build or over-complicate things, meaning projects require less work.
the people that constantly come to my and say blah blah blah facebook blah blah blah facebook
E-mail in an environment where you _cannot_ close it because the sender will be on the phone or in your cube if you haven't responded within five minutes.
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]-
Oh wait! I forgot, this is supposed to be about things developer's DON'T like. Not the things that developers love to do that make everyone else miserable.
Access to /.
http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad
http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code
On a web forum no less?
Egotistical programmers who firmly believe that their way is always the best no matter the history of procedures of the company. They do things without regard to how they effect other people and cause others a great deal off wasted time trying to figure out their 'optimized" code is doing. It is about project productivity not individual productivity. If an individual's excellent productivity leaves such a mess behind that it delays others it is not a good thing.
A perfect example of this is code format haters. They will use their own preferred format and ignore the company standard. They may work faster but the next person who reads the code will work much slower. The code will also be modified in code reviews wasting time. Short term gain for long term loss. Had they buckled down and accepted the code format they would be back to their original productivity in a short time and not be a continual drain on overall productivity.
There are other similar issue. I will use package A when it everything else uses Package B because I know Package A better. This neglects the fact that everyone else knows Package B and not Package A and will have to waste time going through the learning curve. The same goes for design patterns, scripting languages, etc.
Users like yourself
Sorry AC, not a user. I work on the support/administration end, where 90% of my life is cleaning up turds left behind by cowboy devs who think that "practices" interfere with their "creativity," and the "users" (aka THE PEOPLE YOUR JOB EXISTS TO SERVE) are somehow beneath notice. But thank you, I really appreciate your dropping by and proving my point for me.
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
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
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
...and meetings.
I work primarily in product testing, and nothing wastes more time than people or documentation that haven't been brought up to the latest information and standards.
Anecdotal evidence: Last week, a crucial item wasn't shipped on Friday because I had outdated documentation about the last few tests required before shipment. The prototype failed key tests, and nothing could be shipped until Monday. It didn't matter that this item met the expected standards, everyone in testing had outdated standards, and the shipment was halted.
Sadly, the failure went unnoticed by anyone who cared until long after the deadline, because they were all, you guessed it, in meetings.
Documentation, Testing, Bosses differing ideas, Making interfaces idiot proof for that 1 person that cant figure out what to do no mater how simple or straight forward something might be to you
http://interserver.net/
cowboy devs who think that "practices" interfere with their "creativity," and the "users" (aka THE PEOPLE YOUR JOB EXISTS TO SERVE) are somehow beneath notice.
Lol, such bullshit. I am the most customer-focused individual on my team, and I am constantly getting yelled at for not ping-ponging tickets back at the users for pedantic reasons.
The goal isn't to actually do any work or help people. The goal is to make sure you close the tasks in your queue before the end of the sprint so that the productivity reports are stellar. This makes the boss look good. It's also easier to justify his budget if you're constantly putting out fires rather than actually installing some fire prevention.
HOW MANY TIMES have I been forced to close a ticket even though it isn't done, and then have to work on it later because the shit is still broken. Obviously, this system requires a bit of planning, so you have to way overestimate projects to allow time for fixing shit that was prematurely closed but not actually fixed.
Madness!
I believe Frivolous Software Patent Litigation to be a major impeder.
We know bad requirements when we see them
I agree with your overall suggestion that poorly defined requirements lead to poorly executed projects, but this statement is some serious overreach on your part. So all devs have an innate understanding of all business needs? Devs have an innate understanding of the expectations of the user base? If such things were true, there would be no need to "push back." Trust me, people on the revenue side of the house do NOT want to go through the exhausting process of trying to communicate their needs. They would love it if you could read their minds and give them what they want.
Given free reign however, developers will tend to give the users what the devs want to make, not what the users want to use. I wonder how you would feel if [warning: gratuitous car analogy] the auto industry decided that seatbelts and airbags are wasteful because only incompetent people need them? Yet this is how many devs think when faced with the tedious, onerous business of building something to satisfy the needs of others.
It really fascinates me how this attitude continues to survive in geek culture. In most other creative professions, the creative types are obsessed with winning the adoration of their audience. This frequently leads to less talented people being branded as "hacks" or "panderers" who choose the easy path and are focused solely on pleasing an audience without demonstrating any true artfulness. Somehow many software devs continue to live in this bizarro world were they do what they feel like and pity the poor mortals that don't appreciate their genius.
Those of us who fix problems, rather than create them, are not amused. I'd rather work with a pandering hack than an arrogant prima donna any day of the week. My recommendation for your specific gripe is to make a point of reaching out to the project managers and the business analysts in your organization and offer to put resources from your team into the lion's den during the requirements definition phase of the project. Then you don't have to push back against decisions that were made without your input. You were there when the decisions were made. Good luck with that though. Apparently requirements definition is a fancy name for those "boring meetings" modded 5-insightful at the top of the post.
I work for a big software company and work on a huge product.
The number one productivity killer is Broken Code.
Broken builds, bugs which prevents the product from running, newly (undocumented) configuration.
Sometimes it takes me days until I can actually start developing.
Proper testing environment is a valuable asset for productivity.
Beyond the obvious reasons of making it easier to clean bugs, test by running is a time consuming method.
Our product is heavy and takes ages to start running and it surely consume my time when I'm developing.
That brings me to slow machines which is not a major time killer but is very easily fixed and I'm pretty sure has a good ROI.
Too many small assignments outside the issue tracker is filling the head with distracting thoughts. One small issue you have to enter on behalf of someone else could loose 10 minutes of productivity. All because the reporter was too lazy to spend 2 minutes in the ticket system. Another distractor is phones, a ringing phone breaks concentration even if it isn't your own. Fortunately my office is completely phone free.
The cycle goes something like this:
1.Non-software-background or bad-developer background management does not place a value on good quality, maintainable, extensible, appropriate code, Also, they don't understand that silent, non-communicating developers are often productive developers, focussed on generating good code.
2. Developers are therefore trained to feel that focussed time spent developing good code is bad for their career.
3. Developers are trained to rush everything and always meet magical deadlines, above all.
4. The project/company fails due to the software not being cost-effectively extendable to the refined definition of needs.
5. Or the project/company fails because the software development was rushed and produced code with inappropriate features and/or poor (non-performant, unmaintainable) architecture.
6. All of the rushed effort was therefore essentially "unproductive" in that it failed to produce a viable, maintainable product or service, for easily predictable reasons.
Where are we going and why are we in a handbasket?
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. :)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
ha! the place I used to work decided to integrate teams across all departments. Essentially we had one cluster of various IT admins sandwiched between the sales team. I forgot where the account managers were. At any rate, let me repeat: the sales guys (and gals) were on either side of the support teams.
Different culture, diametrically opposed. Completely different goals for work, different energy. You're trying to troubleshoot, and these idiots are banging a gong (really) every time they get a sale. They're fidgety, with ADD, we were much, much more quiet.
It was kind of hard to explain to the customer with a downed server that we were not celebrating the fact that his server was down by holding an impromptu dance off and banging a gong.
I could get so much shit done if it wasn't for people.
And computers.
richard.
The goal isn't to actually do any work or help people. The goal is to make sure you close the tasks in your queue before the end of the sprint so that the productivity reports are stellar.
Well hello, you appear to be agreeing with my sentiments. Agile is allegedly supposed to sweep away all the "bureacracy" that interferes with brilliant programmers writing beautiful, functional code. Nice in theory. Once you actually bake it into an actual organization of any size, it effectively becomes a codified work avoidance process. Fuck quality, we're SPRINTING baby.
Honestly, it's the people like your boss and the worker bees that buy into their thinking that I'm railing against. How many points in your sprint planning gets allocated to QA? Support documentation? Who knows? I will fully admit I'm not studied on what Agile's formal methodologies suggest, but from what I can tell in the implementations I've witnessed, things like QA and docs are just two more undefined activities that can be easily ignored if they look like they'll sully the productivity reports.
... selling things that haven't even been invented yet... but somehow now have a delivery timeline...
Some good comments have already been made; a hearty "me too" to bad requirements, meetings and other time wasters, interruptions, and bad prioritization of tasks/stories.
My contributions to the list are poor design and untestable codebase.
Poor design makes it difficult to understand what the code is doing and change it. Hidden side effects, a nightmare of dependencies, poorly named classes/methods/fields, badly thought out abstractions, copy-and-paste coding, the list goes on. When the design is bad, it will take me about three or four times longer to implement a feature or fix a bug. When it's complete crap, that multiplier probably doubles.
An untestable codebase means the only way to see if my changes are good is to build, deploy and manually test the application. Maybe that's only 30 seconds, although it's more likely to be measured in minutes. Even if it's only 30 seconds, that's about 28 seconds longer than it takes to run a unit test. Give me unit tests, or give me death by a thousand wasted minutes.
Thomas
I've noticed a substantial increase in disagreements over coding styles recently. :-)
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
You just gotta love the automatic content generation over at Amazon. What a review! I think I'll run out an buy it right now.
quiquid id est, timeo puellas et oscula dantes.
It shouldn't be necessary to have headphones on to be able to concentrate. I need an office. Two-up is fine if there's enough space, but the HP/Intel cube farm style or even worse, open-plan offices are not acceptable.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I mean in theory it's nice you can go over at any time and talk to a developer to get some info. Why it sucks is that as a developer people come over, often literally every 20 minutes and bother me about stuff they should be able to figure out themselves. I never get into the zone because of this co-location. If I had an office I would close the damn door to let people "No, I can't help you. I really am that busy."
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
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.
If you were me, you'd be good lookin'. - six string samurai
I hear you. During the dot com boom they were short on everything so I was sitting between two markerters. Then later on at the bigger place I was around the corner from some millionaire programmers who were working for the fun of it. Arrested adolescents literally playing with toys.
I had always taken quiet as a god given workplace right endorsed and understood by everyone.............not so.
Money.
Cube farms are cheaper than offices,
Open office layouts are cheaper than cubes.
John Cleese made a management film about how to run meetings. Everyone should watch this film before scheduling meetings or commenting about the subject. We'll schedule a meeting for that.
Oracle and unix guy.
Noise is a much bigger factor for me than meetings. I don't know how you can be expected to write reasonable code when people are screeching all around you.
It was kind of hard to explain to the customer with a downed server that we were not celebrating the fact that his server was down by holding an impromptu dance off and banging a gong.
This is the shit sitcoms are made of!
You are a FOOL for believe meetings help you.
You really don't need to sit down in a meeting, to do a code review. Maybe when someone first starts they should sit down with their mentor. But otherwise just do the code review by yourself, and write up some comments.
Meeting your customers? That really isn't the job of the developer. Sure it might be useful, occasionally, but not all meetings are bad and harmful. Just most of them.
Meetings are generally a waste of time. And cost more than the allocated time.
Cube farms are cheaper than offices,
Open office layouts are cheaper than cubes.
The difference in developer productivity is at least a factor of two between cubes and offices. It may be as high as a factor of ten in some cases. So you waste a lot of money on salary--which is the dominant expense in development shops by a very large factor--by having cubes rather than offices.
So the answer is clearly anything but money. If it was just about money (the least money for a given work product) small teams of developers in good conditions would be strongly favoured.
Businesses are not run to maximize productivity, they are run to maximize manager's feelings of power and control.
Blasphemy is a human right. Blasphemophobia kills.
Each of these is different and so needs different treatment. The first two might be dealt with in daily check-ups. The third needs a gathering of 'people who know' and the last needs a corporate agony aunt. Hint: Now you know the answers, implement them!
Working "core hours", then having those hours taken up by answering questions from random employees about random subjects all day, then having to do all of one's actual work at night to make up for it.
http://tinyurl.com/...
WHY? You are copying and pasting, WHY are you using tinyurl? Is slashdot's server running out of disk space?
Post the whole URL so we can see what we are clicking on
"Bullpen" environments (lots of desks in one big noisy room) are the single worst productivity sink I've ever seen. Sure, meetings reduce the time available for useful work, but bullpens make it next to impossible to concentrate, and thus next to impossible to get useful work done, even in the non-meeting time. But boy are they trendy - and just think how much money we're saving by not buying cubes or actual offices!
Oh, and slow PCs and small monitors are huge productivity sinks too.
Every bit of code written by a developer represents a hypothesis that "this will have desired behaviour X in the context of the production environment".
Anything that lengthens the time between when that hypothesis was formed, and when that hypothesis is validated or invalidated, decreases productivity in a non-linear way.
This could be anything like:
In my experience issues like these are often the number one source of productivity issues in any team and environment.
This does not negate that individual developer skill is a large factor in performance differences, because skilled developers know how to mitigate or prevent such long feedback loop times.
Provided you can afford to move to where "another job" is.
This is why you work in Silicon Valley, where the "another job" is in the next building
Provided you can afford to move to Silicon Valley in the first place. Where do most people not born near Silicon Valley find that kind of money?
"Online" and "offline" in the meeting sense considerably predate the internet sense. Originally it referred to equipment that was in the main production flow or pulled to the side for repairs, dating back to perhaps WWII and possibly further. The meeting sense was in use by the 1970s at least, and didn't seem new or strange then.
-- MarkusQ
I BELIEVE I've IDENTIFIED who this ANONYMOUS COWARD is. He SEEMS to be quite EGO-DRIVEN as he continually MENTIONS his grandiose ACCOMPLISHMENTS to establish his CREDENTIALS. I assume that he's a MAJOR PAIN IN THE ASS to work with. http://sourceforge.net/p/ultradefrag/discussion/709672/thread/f8561602
Have you read my blog lately?
usually problems with projects are caused by poor project management... regardless of whether the project is programming or otherwise
if there are problems, project managers don't often look at themselves (and take responsibility) to see if they could personally do things differently or learn how to manage better
Working in an environment that uses email and instant messaging constantly knocks me out of 'flow' state. Check email mornings, and after lunch. Disable instant message clients.
Go to Heaven for the climate, Hell for the company -- Mark Twain
Putting in a code comment that documents why something is the way it is, when it is not obvious is good. Commenting what something does is good for an overview of a complicated routine. Then there's what I would term negative value comments. The ones that take up a line commenting the next line that was so obvious that anyone couldn't have gotten what the comment said by half looking at the code wouldn't have understood what the comment was trying to tell them either.
Actual comments from C++ code in production that I've seen.
If a comment doesn't add value it takes away value by taking up space, time to read it and try to ignore it, question the value of any comments by that person in the future, and such. That's why I can them negative value comments.
Valentine Day Jordan Heels Sale
Air Jordan Heels 2013
Nike Heels 2013
Nike Dunk SB High Heels
Nike Air Force One Heels
Air Jordan 11 High Heels These images give out all the facts.You can have a nearer seem then examine the specifics on the cake with that of your unique pair. Soon following you could make out whether the details are accomplished effectively or not.You might have observed many cakes which have been launched these 12 months featuring the themes of some conventional sneakers.Numerous well-known pairs of Air Jodans happen to be employed for making the cakes that looks just exactly the same just like the pair on which the cake is based mainly. These shoes are of rand value that is self-evident high quality, durability and comfort all the time.