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
Filter error: You can type more than that for your comment.
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)
When you should be working.
That means you "Soulskill," or should I say Matt.
Also, you're fired.
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.
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.
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.
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.
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.
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
Let me summarize what the typical ./ crowd will say: 1) Meetings; 2) Slashdot; 3) Management;
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
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."
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.
Switching from one task to another eats up time.
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)
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.
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
"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."
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
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.
There is no project so trivial that a sufficient number of meetings cannot render it impossible.
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.
The G
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.
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
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.
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.
Free Coke Machine!!!! = Improved Productivity
No Free Coke Machine = Decreased Productivity
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.
thus my sarcastic response to his wall of text comment... thanks :D
Generally, anytime you have to make conscious decisions you waste time. If you think about the amount of time you spend naming variables, reading code that isn't in the same standard, dealing with version control because someone tried some new plugin, choosing a location for that new set of tests, etc. etc. etc.
Most of the time all these mundane decisions are not a huge deal, but many developers have a very independent mindset and do not want to be told in explicit terms how to use version control or to use tools they may believe are sub-standard. The opposite of having standards for most of the development workflow is having total freedom, which means that every person is having to make decisions about unimportant details all the time.
The best (and most productive) developers I know have an innate ability to block out these unimportant decisions and live with unoptimized tools and processes in order to solve problems.
i know, don't feed the trolls.... I just couldn't help it considering who posted it.
sleep
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.
Tell me what you want, and let me implement it. Do not change your mind before i finish...
Nothing more unproductive than continually changing requirements/specs
I once used to work where the managers would try to get questions done through IM. It's amazing how many quick conversations that should take 90 seconds face to face or over the phone can waste 20 minutes when done over IM.
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.
E-mail always pops up. I know you can close it but I receive important information through e-mail. Most of it is useless. It interrupts my train of thought and then I have to delete it to get rid of the little e-mail icon on the taskbar (otherwise it drives me crazy).
...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 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.
Half the team can't understand English well enough to perform their job.
Half the team can't perform their job.
(Those two halves have a significant overlap that is not total.)
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
Who posted it? It was AC, I've seen APK argue with APK before, I think there are multiples out there, like Atlas Shrugged references (John Gault references in sigs from ACs), so you can't know who it is, even if they look like a loon and sign it APK.
Learn to love Alaska
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
LOL - Just read all the comments from them. Let them eat cake, they scream! Don't bother me, don't fence me in, don't take up my precious time, take what I make you and be pleased I graced you with anything at all.
It's why your bubble burst a decade ago - and you've worked so hard to create a new bubble, only to find it is going to burst again, soon. Hope you stashed that money away - so your coding skills can help you sit and post on /. from home while you try to justify why no one wants to hire you because they are just inferior. I would say I hope your spouse has a good job, but well, chances are high you don't have one of those with you in your parent's basement.
Too funny - and almost all of the existing posts so far reinforce how out of touch most of you are with what business is versus what you want it to be to fit you.
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.
That bullshit Time Tracking Sheet is how I justify paying you.
-management
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]-
Radio's playing in the background or coworkers overhead conversations. Nothing impedes my coding more than this.
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?
1. Meetings
2. Bosses
3. Agile
Yes, because our jobs are so rosy that we want to keep the joy all to ourselves. Users like yourself never give us any grief or ask us to deviate from spec.
I, personally, love my job. Just the other day I was at the dentist getting a root canal and thought, "Man, I wish I was at work right now!"
The human varieties that go along and demand point less meetings, and the technical tools that waste time and enforce bad coding.
Just cut the meetings by 1/2 for a month and evaluate. Don't over think it. Just do this one thing and you see for yourself.
As for the technical tools, just throw away C++ and Java and any Microsoft product off your tool chain. C++ is just bad, Java is a patch that didn't hold, and Microsoft is the shooting yourself in the foot. C99 is very mature now and days so you can go with that. If you're feeling adventurous or need to handle low skilled programmers you can try Google's Go. It's light years ahead of anything else and feature wise offers everything without being verbose.
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.
Easy: speaker phones, conference rooms without auto-closing doors and worst of all, open office space.
There are two ways to increase the velocity numbers.
One, is to forever work more efficiently than the previous sprint, forever.
The other is to estimate tasks will take longer than they actually will.
I know which one I saw happen more often...
You're pitiful - what I call a "not man" online (acts more like a WOMAN than a man, lol)
Wow! He's sexist, too.
Hey dude, pitiful does not equate to being a woman. What a douche.
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?
n/t
Enough said, please don't tell my boss.
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/
I've been coding since I was 10 years old. I can write great software. I've written great software at home doing my own projects. However, I've never been able to achieve my potential in the workplace. Why? I think it's because I'm not allowed to be any better than the next guy. If I put my head down and crank out code, I do great things, but inevitably someone else will take credit for my work. If I try to "play the game" the everyone else plays, my productivity goes way down. it's a corporate culture that makes sure that everyone is of equal skill. If you're great, then a big company isn't for you. Your only chance is to work for yourself somehow.
I could get so much shit done if it wasn't for people.
And computers.
richard.
Strong typing will stop you from releasing crap that will emit dozens of GB of stack traces in the production environment. Horrible !
..you don't have proper version control to undo junior's work ?
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.
Once a product has been released, the product is out of the hands of development and becomes completely driven by marketing and sales. I've seen it happen a half a dozen times. So once it's released, you can kiss the idea of any new features good bye because all you'll be doing is fixing customer issues and adding features that sales guys get promised that a customer will buy a bunch of the product "if it had x". "x" always at that point gets implemented quick and dirty.
Meetings make matters worse, but management changing track every week is worse.
Doesn't matter how efficient the developers are then.
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
Very large companies that get audited regularly have multi-level sign-off processes for any source code change. It's terribly frustrating to have to do a 1 line bug fix, but because the bug is being fixed 'off-cycle' (ie: not on a scheduled release day), an emergency release must be requested electronically. Once the emergency release is approved, ancillary change instructions need to by filled in for remote deployers. You can't just change the line of code yourself because that violates SOx which is why you don't have test or production access. Once that happens, the code can go into QA and be signed off by a non-technical app person. After that happens, the process is repeated for UAT where a user (many times in another part of the country) needs to go in and test the change - usually they need some hand-holding. After that, it goes on a release and the deployment process is repeated once again... the change control process continues even after deployment to production... All of this facilitated by IBM ClearQuest.
I can't believe nobody has mentioned change control....
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.
Our scrum meetings are now lead by the radioactive cockroach. She kept trying to blow up the project, and the other week finally found the nuclear trigger. Now she sits there, all alone, on a sere and level plain and wonders where everyone went and why her hands glow blue.
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.
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.
- Interruptions
- Micromanagement (ex: FreshBooks)
- Lack of stimulant drugs, coffee, and/or nicotine
- only given a single 1024x768px monitor to work on
- Employees and bosses wanting "tech support" who feel that the most important part of your job is to fix their printers and fax machines
- Constant phone calls asking for said tech support
- Constant emails asking for said tech support
- Constant instant messages asking for said tech support
- Being placed in an out-of-the-way location isolated from the rest of the company leaving one feel like their presence is even desired
- Constantly being suspected and accused of slacking off instead of working
- Since you're single and have no kids to take care of, you're expected to work regular overtime shifts for the same salary. To hell with your personal life and getting sleep.
- If you happen to be paid hourly and not on salary, constantly being accused by the head of Finance of overstating your hours on the time-sheets and having to explain the accuracy of your reported hours
- Idiot employers INSISTING that you get drunk with them one night, leaving you hungover and unable to think clearly, and then they have the never to call you a lazy clockpunching alcoholic the very next day
Look! I have a nice stick for you to chase! Fetch!
Goooood boyyyyyyyy!!
Sent from my ENIAC
It's the culture. It's responsible for it all.
"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.
Copy-n-past of code tends to duplicates errors and bad practices. It is also indicative of poor architecture, a disregard of design patterns, or even an inadequate language for the task at hand.
That is the biggest roductivity killer
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.
The company I work for has grown considerably - we now have 70+ developers working on our Java GUI and 280+ on the C++ server code. The result has been that we now have so much procedure that the work I was previously able to do in half a day, now takes over a week. This is not because the coding complexity has changed but because we now have to branch the entire test environment to ensure that we are not going to break any tests before committing code. Once the branch is working, we have to merge it back to trunk with the revised tests, and then we are permitted to commit the actual code we wrote a week ago. If there's a bug we get to do it all again.
I now spend about 10% of my time coding and the rest of it making sure that a test is never broken, which drives me nuts.
Windows is the biggest productivity destroyer
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
Meetings eat up time, but paperwork does too. Some paperwork is good like design artifacts, or programmers guides explaining architecture, rationale, and how to rightfully extend the code are good.
Paperwork can get out of hand. Everyone wants to be satisified and they each want their own paperwork filled out (sqa team, govt team, customer team, change control board team, management team, etc.). Spending 95% of your time doing paperwork and only 5% coding/designing is a real drag. Some industries and companies have gone that way. I yearn for the days when I show up to work and just start coding to some idea. Ah the good old days.
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?
There are three types of developers: prototypers, new developers, and maintenance developers. It is debatable whether a systems analyst/designer is a developer or a separate category of IT jock. Perhaps a developer has to touch code to be a true developer. What is demoralizing and unproductive is when a developer's talents to develop are diverted into the requirements of becoming a filing clerk to turn new code into production jobs. In the classic days of system development, different people handled the tasks of turning new code into production jobs. In the classic days, file clerks were file clerks and developers were developers. In the classic days, organizations had production teams and development teams. The file clerks were the bridge between the two teams. In the modern age, since the Internet started, production and development teams got mashed into one confusing conglomeration. Security standards were lowered, so that developers could handle production data, thus making an organization subject to conflicts of interest.
The worst travesty that an organization can do is to destroy the creative talent of its employees. Let the creative talents of its development teams flourish and don't turn creative employees into robots. Better yet, on a national scale, don't outsource creative talent offshore. For the past twenty years, the USA has been shooting itself in the foot by outsourcing creative talent offshore.
Certainly, outsourcing has created a new middle class in those offshore countries, but at the same time it has squeezed the domestic middle class out of existence.
This field is filled with creative, intelligent individuals that are too often managed by arrogant, insuffereably untalented individuals that are indifferent and callous towards the needs of those that would most benefit from having an office with a door and/or an atmosphere that stimulates, motivates, inspires intellectual work.
Often the engineers themselves are poor at communication and even worse at drawing pictures to communicate complex object relationships in projects. It's been my experience that the software people are especially poor at this skill while the hardware groups are much better - perhaps because their work and preparation centers around diagrams.
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
I haven't seen anything in Scrum that justifies the amount of time it uses. Scrum is dumb.
Weekly meetings are a great idea. Better for Ops than for developers - it gives Ops a chance to share problems and solutions with different departments they support, with one another - which leads to better support for developers and everyone else.
Daily meetings are unnecessary because there is rarely enough change - 'delta' - to justify a meeting. For anyone.
Successful meetings require agendas as well as someone to facilitate the meeting. That person does not need to be a trained facilitator (a concept which has been around for decades) so much as they need to be genuinely committed to seeking a solution which is acceptable to all those invited to the meeting.
Such people rarely survive in the corporate world. They are more likely to be found in scholastic or non-profit environments.
Historically, and anthropologically speaking, meetings - gatherings of the herd - often turn into bullying sessions. Any group of more than two people is, over time, inevitably riddled, with rivalries and, eventually, schisms. It's part of being human.
Therefore, historically, minutes are required - so that third parties can subsequently determine if the agenda and the minutes coincide with one another. This does not eliminate bullying - but it does provide accountability.
Speaking of accountability, it has been my observation that many managers use meetings to pass on information which they do not wish to put into writing - particularly in one-on-one meetings.
As others have noted, a good bug-tracking system combined with dutiful, assiduous users fills most of the meeting-centric needs of the average developer-centric organization. It also provides that valuable 'paper trail' which, along with emails, goes a long way towards describing, when things go wrong ... why they went wrong.
Just sayan',
Holy shit on a shingle, just look at the code he provided. I'd be embarrassed to admit I wrote that code (especially while trying to show off how intelligent I was, and telling obviously capable developers how to do a simple thing like adjust scheduling priority).
I wondered if I was reading thedailywtf.com. I'll paste it here, but the entire thread is pretty hilarious. Check out the developer trying not to directly offend him (and still telling him his icon looks like human bowels, lol).
I use it myself here in fact (works perfectly, for all conditions noted below):
---
APK Hosts File Engine 5.0++ 32/64-bit:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
---
It's completely stable too, produces PERFECT hosts file data outputs, & is a multithreaded single self-contained TRUE 'stand-alone' executable!
* Show us you've done a better app that provides ALL of what is noted in that link it gives users to THEIR benefit on a number of levels, for both added SPEED & "layered-security"/"defense-in-depth" (plus reliability, and privacy online)...
(GO FOR IT! My guess here? You CAN'T... lol!)
See - unlike you AC mere troll "armchair quarterback" talkers, who aren't DOERS?
I can actually SHOW something it's been applied to that helps it run faster or lower priority in certain conditions (see below)! Can you show you've done the SAME?
Answer = NO!
LMAO @ U, troll!
---
I gave the guys @ UltraDefrag the option to use it... why?
Vs. this problem they had & others even RECOMMENDED my code vs. a problem they are having -> http://sourceforge.net/p/ultradefrag/bugs/136/
IN FACT? That's one of their coding team saying it... not me (Dmitri - THE ORIGINAL FOUNDER OF THE UltraDefrag64 PROJECT, not Stefan Pendl):
PERTINENT QUOTE/EXCERPT:
---
http://sourceforge.net/tracker/?func=detail&aid=2993462&group_id=199532&atid=969873" - Dmitri FROM -> http://sourceforge.net/p/ultradefrag/bugs/136/
---
(Albeit in Delphi Object-Pascal, vs. their usage of C/C++)
It's useful for stopping that, & NOT for raising priority only either, but quite the reverse also!
See - the front end is ONLY A REPORTER: It doesn't NEED to be high, normal, or even below normal priority - there are TIMES IT'S GOOD TO BE LOW even (see next)!
Lowering priority is important in these conditions!
It's more for when they add features the commercial "bigboys" have like Diskeeper, PerfectDisk, O&O Defrag etc./et al:
For LOWERING priority when it's minimized to tray or otherwise (along with stopping display generation of outputs wasting cycles if it is NOT VISIBLE onscreen - that is a waste & drag on the system overall and the app too)
or
FOR running in the background as a scheduled task!
I do it - it works! I have to write them on that much, for when they add those types of features to be more 'competitive' vs. the big boys noted above...
Especially Stefan Pendl, who I don't *think* realizes THAT benefit on lowering CPU & when to do it, & also of course, its ability to help solve their issue noted above by Dmitri, the founder of the project itself...
... apk
I use it myself here in fact (works perfectly, for all conditions noted below):
---
APK Hosts File Engine 5.0++ 32/64-bit:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
---
It's completely stable too, produces PERFECT hosts file data outputs, & is a multithreaded single self-contained TRUE 'stand-alone' executable!
* Show us you've done a better app that provides ALL of what is noted in that link it gives users to THEIR benefit on a number of levels, for both added SPEED & "layered-security"/"defense-in-depth" (plus reliability, and privacy online)...
(GO FOR IT! My guess here? You CAN'T... lol!)
See - unlike you AC mere troll "armchair quarterback" talkers, who aren't DOERS?
I can actually SHOW something it's been applied to that helps it run faster or lower priority in certain conditions (see below)! Can you show you've done the SAME?
Answer = NO!
LMAO @ U, troll!
---
I gave the guys @ UltraDefrag the option to use it... why?
Vs. this problem they had & others even RECOMMENDED my code vs. a problem they are having -> http://sourceforge.net/p/ultradefrag/bugs/136/
IN FACT? That's one of their coding team saying it... not me (Dmitri - THE ORIGINAL FOUNDER OF THE UltraDefrag64 PROJECT, not Stefan Pendl):
PERTINENT QUOTE/EXCERPT:
---
"I think, this issue can be resolved through changing the process priority as suggested before by Alexander Peter Kowalski http://sourceforge.net/tracker/?func=detail&aid=2993462&group_id=199532&atid=969873" - Dmitri FROM -> http://sourceforge.net/p/ultradefrag/bugs/136/
---
(Albeit in Delphi Object-Pascal, vs. their usage of C/C++)
It's useful for stopping that, & NOT for raising priority only either, but quite the reverse also!
See - the front end is ONLY A REPORTER: It doesn't NEED to be high, normal, or even below normal priority - there are TIMES IT'S GOOD TO BE LOW even (see next)!
Lowering priority is important in these conditions!
It's more for when they add features the commercial "bigboys" have like Diskeeper, PerfectDisk, O&O Defrag etc./et al:
For LOWERING priority when it's minimized to tray or otherwise (along with stopping display generation of outputs wasting cycles if it is NOT VISIBLE onscreen - that is a waste & drag on the system overall and the app too)
or
FOR running in the background as a scheduled task!
I do it - it works! I have to write them on that much, for when they add those types of features to be more 'competitive' vs. the big boys noted above...
Especially Stefan Pendl, who I don't *think* realizes THAT benefit on lowering CPU & when to do it, & also of course, its ability to help solve their issue noted above by Dmitri, the founder of the project itself...
... apk
Capital expenditure limitations. I've got a team of ten offshore developers working on a Java application (deployed in boss), working with late-90's hardware. The very common operation of switching branches takes each of them a half-day -- it s about 15 minutes on my laptop.
Upgrading the entire team's workstations would cost less than the yearly salary of one of them, yet some current company policy is preventing this.
So my vote goes to CAPEX policies.
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.
Having to report to five managers, and weekly TPS reports....
Lance Zimmerman of Panther Games
Ah yes. If anyone disagrees with you, just insist they could not possibly have understood you. After all, you are perfect and without flaw. Therefore no one could possibly have good reason to disagree with anything you ever say.
That's a classic one. Not classy, no not in the slightest. But all too common. It is how you protect your dysfunctional ego from discovering its own dysfunction.
Denial. It's not just a river in Egypt. APK, you really wonder why no one takes you seriously, don't you?
"Your try/except block has no code in it, making it useless" - by Anonymous Coward on Sunday January 13, @01:55PM (#42575973)
See subject-line above, & this snippet:
try except
Screen.Cursor:=crDefault;
ShowMessage(Trim('Abend in procedure SetCPUPriorityForMainThread'));
end;
FROM -> http://sourceforge.net/p/ultradefrag/discussion/709672/thread/f8561602
(You FAIL...)
---
"You fail to understand the purpose of try/finally" - by Anonymous Coward on Sunday January 13, @01:55PM (#42575973)
1st of all, you ALREADY "F'd UP" above, lol!
&
Secondly, no I didn't - it works, and it makes SURE things happen at the end of a try block NO MATTER WHAT, last UNLESS an exception occurs (which then I could dump the 'structured compiler exception message" or, just dump one of my own, bit friendlier to users, which is what the above did).
E.G.-> I often use try-finally to re-enable the control that started a particular part of a process for example, once it's done running in the 'finally' section as just an example of its usage & how I do it sometimes (since I often disable them @ the start so a user can't "double-detonate" it &/or I reset the cursor back to normal, etc.- et al (depends on what needs doing is all)).
* It wasn't bad for a "bang up job" example to post to them, especially considering they used it to fix a bug of theirs @ UltraDefrag!
Lastly - as I said?
The "trolling ac likes of you", who can't show us a DAMNED THING you've ever done is *trying* tell me ME "how to code"? LMAO - you screwed that up ROYALLY above, 1st of all!
SECONDLY, you don't have a DAMNED THING TO SHOW FOR YOURSELF as I suspected...(& I was obviously correct on, no less!)
APK
P.S.=> Again - you FAIL (& it's obvious you're STUPID, and merely trolling, since the guys @ UltraDefrag actually used my ideas to solve a bug - I had no idea they did, I just posted it & let 'em "have @ it"...)
... apk
"I wish I could see the code from some of your own projects" - by Anonymous Coward on Sunday January 13, @01:55PM (#42575973)
On the very topic YOU "F'd UP ON, fool -> http://tech.slashdot.org/comments.pl?sid=3339513&cid=42408867
* In fact - that covers the ENTIRE GAMUT of what I usually do considering try-finally &/or try-except, as well as "std error handler" overrides, & more!
(Again - you FAIL!)
APK
P.S.=> You wish you could see code in my projects? There's a bit in the link above, AND, you can see my work in motion too -> http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
HOWEVER: What can we see from a MORON "big talker" like yourself that utterly SCREWED UP vs. myself, here -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42581949 with your b.s. I didn't have code in my exception handler? N O T H I N G ... LMAO... double-fail!
... apk
With facts they can't match. Unjustifiable downmods = all they have to try hide his post that shames them easily. Down moderating what I wrote before http://ask.slashdot.org/comments.pl?sid=3376359&cid=42562109 on that same note isn't hiding that fact since I won't allow it. You fail as he says noobs.
http://ask.slashdot.org/comments.pl?sid=3376359&cid=42561917
Funniest part is - YOU DIDN'T ANSWER MY QUESTION! Again - Do YOU know the job aspects & workflow of the process that the people programmers write code for BETTER THAN THEY DO?
Hell no - that's impossible usually, without study beforehand, as well as advisement of the user themselves on THEIR JOB, which they do know BETTER than you as a coder does!
Funnier still?
Not a SINGLE ONE of you's done a thing, much less more, better & EARLIER than I have in the art & science of computing either, lol -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42561749
Which is pretty sad... AND YES, funny!
Especially vs. "lil' ole' me", & I don't consider myself 'great' either & said it earlier as well here -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42566629
(I'm just a guy that can GET THE JOB DONE (obviously unlike you trolling noobz!)).
APK
P.S.=> Puny trolls! Will you NEVER LEARN, I am your superior on ALL FRONTS NOTED? Lmao (that oughtta get another "rise" outta the ac trolling noobz again, lol)...
... apk
http://ask.slashdot.org/comments.pl?sid=3376359&cid=42564517 & http://ask.slashdot.org/comments.pl?sid=3376359&cid=42564581
* :)
APK
P.S.=> You have ALL seriously SHOWED ME, that you're all just noobz with nothing to show for yourselves as accomplishments in the art & science of computing as well, & certainly NOT before me/earlier, more of them, + better than myself, as well -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42561749
"APK, you really wonder why no one takes you seriously, don't you?" - by Anonymous Coward on Sunday January 13, @11:32PM (#42579133)
By MANY orders of magnitude via this partial list of only SOME of my upward modded posts & thus, by the opinions of your /. peers too, no less:
---
Roughly 241++ of them & I post as AC (hard to get even +1, as /. hides our posts & we "AC"'s start @ ZERO/0 points, unlike registered "lusers", lol!):
+5 'modded up' posts by "yours truly" (8):
HOSTS & BGP:2010 -> http://tech.slashdot.org/comments.pl?sid=1901826&cid=34490450
FIREFOX IN DANGER: 2011 -> http://news.slashdot.org/comments.pl?sid=2559120&cid=38268580
TESLA:2010 -> http://science.slashdot.org/comments.pl?sid=1872982&cid=34264190
TESLA:2010 -> http://tech.slashdot.org/comments.pl?sid=1806946&cid=33777976
NVIDIA 2d:2006 -> http://hardware.slashdot.org/comments.pl?sid=175774&cid=14610147
Ubuntu Linux sends back local disk query strings to CANONICAL: 2012 -> http://news.slashdot.org/comments.pl?sid=3304601&cid=42234351
Question to Mr. Mark Shuttleworth @ UBUNTU/CANONICAL: 2012 -> http://news.slashdot.org/comments.pl?sid=3304725&cid=42243467
COMPUTER ASSOCIATES BUSTED FOR ACCOUNTING FRAUD:2010 -> http://news.slashdot.org/comments.pl?sid=1884922&cid=34350102
----
+4 'modded up' posts by "yours truly" (5):
APK SECURITY GUIDE:2005 -> http://developers.slashdot.org/comments.pl?sid=167071&cid=13931198
INFO. SYSTEMS WORK:2005 -> http://slashdot.org/comments.pl?sid=161862&cid=13531817
WINDOWS @ NASDAQ 7++ YRS. NOW:2009 -> http://tech.slashdot.org/comments.pl?sid=1290967&cid=28571315
CARMACK'S ARMADILLO AEROSPACE:2005 -> http://science.slashdot.org/comments.pl?sid=158310&cid=13263898
What I admire about Theo DeRaadt of BSD fame: 2012 -> http://linux.slashdot.org/comments.pl?sid=3007641&cid=40785151
----
+3 'modded up' posts by "yours truly" (7):
APK MICROSOFT INTERVIEW:2005 -> http://developers.slashdot.org/comments.pl?sid=155172&cid=13007974
Linux security failures 2011-2012: 2012 -> http://it.slashdot.org/comments.pl?sid=3319303&cid=42306663
APK MS SYMBOLIC DIRECTORY LINKS:2005 -> http://it.slashdot.org/comments.pl?sid=166850&cid=13914137
APK FOOLS IE7 INSTALL IN BETA HOW TO:2006 -> http://slashdot.org/comments.pl?sid=175857&cid=14615222
PROOFS ON OPERA SPEED & SECURITY:2007 -> http://slashdot.org/
You're full of it and committing libel on my person you scumbag.
HOWEVER: I am GLAD You noted checking GOOGLE though: Simply as there is NO SHAME in being a many time recognized as doing decent stuff coder, which I am, amongst other accomplishments in the art & science of computing (which you & yours can't even BEGIN to match, lol, proven below)... & that's what folks will see!
* :)
(Whereas by way of comparison? You're just a TRULY cowardly little AC troll noob who won't post via his "registered 'luser'" account to face me, directly!)
I really ought to get my attorney & have them write who owns this site, just to track down your IP Address, & then nail you by netblock (to deteermine who your ISP is).
APK
P.S.=> However, since I've done THAT to scum online like you before? This is even easier: Show us you've done MORE, EARLIER, & BETTER than I have in the art & science of computing then -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42561749 (which I did while you were still in DIAPERS I'd almost wager, or possibly before you even began BREATHING... lol!)
... apk
It will run inside the 1st try (in the event of an exception) for catching exceptions inside the 1st try that uses finally. Haven't you ever "tried" that before? Apparently not. Live and learn fool!
APK
P.S.=> You can do it this way too:
try ... ... ... ...
try
finally
end;
except
end;
It'lll work via scope, OR, you can structure it the other way I showed -> http://ask.slashdot.org/comments.pl?sid=3376359&cid=42590827 that will work as well!
I.E.=> If the preceeding code has an error, the "try" with no code leading into the "except" WILL be executed and due to being under the scope of the previous try/finally, it will catch it. I prefer the latter method I noted in my p.s. above though. However, either works.
Either way?
YOU FAIL!
(Especially since I don't SEE ANYTHING YOU'VE EVER DONE THAT WAS NOTED AS BETTER THAN WHAT I PUT OUT, THAT YOU DID IT EARLIER, & MORE OF IT... not a peep outta YOU there, lol, is there? Nope!)
APK
P.S. => You don't understand scope... apk
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.