20 ms·

Dear Boss: For a programmer, 10 minutes = 3 hours

699 points by joshuacc 15y ago

ChuckMcM 15y ago
This is so true. The sad part though is that during the 3 hrs Ed was stuck reading HN not doing something productive.
- pavel_lishin 15y ago
  > reading HN not doing something productive Hey now, what are you trying to imply? :)
- bitops 15y ago
  Ed could have shortened the time by helping. Really poor team attitude.
  - lawnchair_larry 15y ago
    Helping how? Telling her boss to share control? Telling her where to click? There was absolutely nothing Ed could have done, and it's the expectation that he can fix every little thing that is the root of these problems.
ww520 15y ago
This is what happens when there's no tech support people to interface with the users and translate the problem into engineering tickets. You either train the business users to be able to articulate the problem clearly and document the reproduction steps in the ticket, or the boss should have served as the interface to the business users to do the translation. Otherwise the engineers will be doing all the supports. As corporations continue to downsize, the remaining ones will take on more and more responsibility.
- a3camero 15y ago
  "I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?"
bingo_cannon 15y ago
3 hours and late lunch!
davux 15y ago
We all know that context switching is bad, and it's tough to switch so much, but did Ed really have nothing else to do? He seems bothered by what the boss was asking him, yet he blows most of the 3hrs not working on what he said he needed to work on originally? That just doesn't add up to me. I get the point, and it's definitely true, but I spend those idle minutes doing mail and other short tasks. I don't see how one can justify "well I'm waiting for you so I'll just not work for a while." Is this common outside of the computing industry? What do other people do in their 'in between' time?
- pavel_lishin 15y ago
  A lot of times, there isn't anything you can work on that doesn't require a lot of concentration. I got an interrupt earlier today that put me on hold for an hour, while an email chain tried to sort out what was necessary. How can I focus on implementing a hard feature when at any point, someone might pull me away from it and knock down my house of cards? Hell, even if I'm writing code and suddenly I have to actually start working on a different project, I have to commit what I was doing, and try to squash everything later, or start stashing code around, and set up the other project's environment, etc. That's five minutes eaten up already.
  - randomdata 15y ago
    I find learning something new doesn't require a lot of context switching, and while does not show immediate productivity, the long term gains to the organization are present and quite valuable. It beats just randomly surfing the internet anyway; bean counters may not agree.
- fleitz 15y ago
  Ed allocated his time according to his bosses request. During the entire time he was dedicated to making progress on his action item. If his company allocates time so poorly it is not Ed's fault. His boss clearly deprioritized his other tasks probably because he poorly estimated the time required by close to 2 orders of magnitude.
- div 15y ago
deleted 15y ago
[deleted]
j45 15y ago
Ed, the funny thing is I have customers that end up paying to do this. I give them an answer and then they take 3 hours going in circles to arrive back at my first email. I am slowly coming to see it as them paying for time towards their education when they decide to insist understanding the inner workings of something better than someone who has built it. Despite my best to bring it to their attention to send me the information complete and once to get the quickest resolution, folks feel productive when going back and forth. I squarely blame this on the Blackberry exec mindset. Talking all day by email or IM or phone doesn't mean you get anything done. If you point it out, they won't like finding out they're the cause of slowing everything down, because they're so important. 0.02
- yxhuvud 15y ago
  Indeed. It is often more effective to ask the right questions so that the other part can arrive at the correct conclusion by themselves instead of telling them the conclusion from the start.
nlawalker 15y ago
Heh, I love the detail on all the confcall/web sharing problems. Every conf call I join includes at least two of the following. - The leader who is in the conf room calls in from the table phone and from their PC and can't figure out how to stop the screaming feedback. What's funny about this one to me is that the same people do it every time. - Tom calls from his car. He must be on the interstate, judging from the road gradient we can hear. - Dick joins from his laptop, where the microphone is conveniently part of the same physical device as the keyboard. CLACKCLACKCLACKCLACK. - Harry is working from home. We become intimately familiar with his three-year-old daughter's escapades with Cheerios and love of Phineas & Ferb. - Judging from the number of sirens, Jake apparently lives in a bad part of town or is watching Blues Brothers in the background. - Lucy has apparently joined while sitting in a conference room, attending another meeting simultaneously. - Robert joins 15 minutes late and would like everything he missed to be recapped. - Mark absolutely will not let the meeting progress unless someone is recording. Everyone spends 10 minutes figuring out how to do this. No one can find the file at the end of the meeting. - James calls in via a VOIP connection from India, introducing a slight delay. "Hello?" "Hellohello" "Hi James, can-" "Hello" "Hi James, we are-" "Hello, hi yes-" "Hi James-" - Dave joins from the airport. According to the PA, someone named Janice needs to report to the ticket desk. - Mike has apparently set his cell phone ringer volume to "over 9000" and has placed it next to his mic. - "Can you see my screen?" "No". "How about now?" -cue pictures of cats- "Yes but I think you have shared the wrong monitor." "How about now?" -cue spreadsheet- "Yes." -cue scrolling that the video broadcast can't keep up with- "Now if you can see here, here and here..." Mass meetings are the funniest. During one surreal leadership presentation where hundreds of people joined via a web meeting and many more were present in person, someone forgot to lock down presenter rights, and people kept drawing on the slides.
- sbov 15y ago
  Heh, onetime I had to get on a conference call when the blue angels were in town. "No, I don't live in a war zone, sorry about the noise."
  - pagekalisedown 15y ago
    Ditto for Tuesdays at noon.
mkramlich 15y ago
He nailed it. I've experienced situations like that many times in my career. I'm now trying to live a life where I minimize my exposure to such Dilbertesque phenomena. Life's too short to piss it away on stupid people and inefficient processes.
Shengster 15y ago
I had something similar happen to me earlier in the week. The conversation went something like this: Boss: Hey, we've got an urgent production issue that needs to be looked at. I'm getting some heat on this one and I need someone to diagnose it to see if it's a blocker for our release. Me: Would you be able to ask X and Y to investigate? It seems they are on the support rotation for production issues. It'll take me at least an hour to clean up what I'm doing and switch over to run the old production instance locally. Boss: It's urgent, I think you need to drop whatever you're doing and look at this. Me: OK, sure. (50 minutes later, as I'm almost done building the old production instance) ... X and Y come back from a meeting. Boss: I'll have X and Y look at this, you can go back to working on your stories for this sprint. Me: !@#?$
- joelhaasnoot 15y ago
  One of the advantages of doing eXtreme Programming with lots of pair programming is that we eventually setup machines to be assigned to certain branches. Costs more computers, but is more productive. The best thing ofcourse is to reduce that buildtime, but not a whole lot you can do there.
- iy56 15y ago
  Use a VM
  - Shengster 15y ago
    Not enough CPU and Memory to do so. Our app is huge.
    - zikzikzik 15y ago
      How many lost hours make up for the necessary CPU and RAM?
baconner 15y ago
Funny... I assumed the punchline was going to be about the hours it takes a developer to get back into high productivity mode after interruption. Sure, bosses and customers frequently underestimate the amount of time these sort of calls take and an intermediary (support) ought to take a stab at pulling a clear issue out first, but they're not always wasted time. There's a lot of value in getting devs and customers talking directly. It just needs to be (and can be) planned in a way that avoids breaking up the developer productivity curve unnecessarily.
deleted 15y ago
[deleted]
tux1968 15y ago
The title reminded me of the old line about why programmers often confuse Halloween and Christmas... because Oct 31 = Dec 25.
- golden_apples 15y ago
  Reference Error: Dec 25 is not defined
- tux1968 15y ago
  thanks everyone for piling on the downvotes... lol
jgarmon 15y ago
This true for non-coder creatives, too. I can't count the number of times I've been asked to "look at a design" or "go over some copy" because three other employees had some feedback in some meting I wasn't a part of, but no one can remember exactly was "off" with the deliverable. We then have to do the SKype/email round robin until everyone has given their comments again. This gets even worse when we, the creatives, get feedback about functional changes. "When I click the checkout button, it goes to the shopping cart." "Uh...yeah." "Could you have an upsell page pop up between the two." "I can write the copy and spec the creative and functional design, but I can't change the button functionality. You'll have to get that prioritized in the next sprint." "We don't want to bother engineering. We need to get this done quickly." "It's a functional change. We have to involve engineering." "So you can't write the page." "I can write the page. I can spec the page. I can't build or deploy the page." "That's disappointing." "You have no idea."
- ja2ke 15y ago
  I only have meetings like that when working somewhere which has a discrete marketing department.
patrickyeon 15y ago
Hmmm, lots of "yeah, I hate it when that happens" comments. Does anybody have ideas on how to fight this? Does anybody keep track like edw did, and then use it to defend themselves for the next "just ten minutes" task? Successfully? I haven't been able to make a point about how it's not "just ten minutes" without coming off as rude/unhelpful/lazy. I've tried to explain the cost of context-switching, or push it off until I'm not being interrupted, or at least have other people do pre-requisite work first (filing a bug would've fast-forwarded to somewhere between 12:14 and 12:38 here). In my dream world, a manager respects (or fears) you enough that you can say "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock" and pull it off. Out here in the real world?
- pavel_lishin 15y ago
  I work for a small enough company, where my immediate supervisor commits code with the rest of us, and therefore understands these issues.
- hluska 15y ago
  Sorry to say this, but I think that the 'just ten minutes' task is a symptom of a much deeper corporate problem. For example, consider the boss in this story. Why does he/she think a task like this will only take 10 minutes? Is he a developer? Does he keep track of what is going on in other departments? Does he understand how a (seemingly simple) bug like this fits in the context of the whole project? Or, here's another question. Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate? Forgive me if I come across as being somewhat dismissive, but when I hear stories like this, I see signs of a very sick company that needs life support.
  - patrickyeon 15y ago
    There is definitely a corporate problem (or many) here. At least the manager deciding that "this needs to be looked into right now" above edw's opinion, and the idea that the whole conf call + webconf dance was a better move than filing a ticket. > Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate? Exactly. How should one fight that these steps be taken, when your manager is trying to skip them? The thought process that I expect led to this situation were similar to "I could file a ticket, which will take me 5 minutes, or if I just show it to someone, it'll only take me 3 [not voiced: if nothing goes wrong.] That's working smarter!" Similarily, how do you convey to people the true cost of asking for something like this, instead of them treating everybody else's time and effort as externalities. Yes, there are signs of a sick culture. Culture is fluid though, so how does one push it back towards health? Preferrably without getting classed as difficult/rude/not-a-team-player and then having any argument you bring ignored.
mgkimsal 15y ago
The thing is, it really did take about 10 minutes, but they weren't consecutive. Yeah, it's a bit of a smartass comment, but also true. Some people really can be as productive (or close to it) doing 6 10 minute tasks in an hour, switching every few minutes between those 6. To them, they still just spent 10 minutes on each task, and they're oblivious to the fact that not everyone's work can be sliced around like that with the same degree of quality that theirs can.
- eCa 15y ago
  Doing (starting and finishing) six discreet tasks in an hour is not too difficult. Obviously those tasks are not very taxing. What is hard if you have one four hour task, and one task that requires your attention every fifteenth minute. It completely ruins the four hour task.
  - Drbble 15y ago
    The hardest part is making sure no one finds out about all them, and that information doesn't leak between those discreet tasks. Indiscretions are killer.
    - eCa 15y ago
      Sorry. It was late. I obviously meant discrete, even though I didn't know about that difference (in my native language "discreet" has both meanings). So thank you.
csomar 15y ago
If this is happening frequently, then you need a support stuff. The support stuff will spend those 3 hours to get the actually problem and explain it to you in 10 minutes at the end of the day. If you want to focus, and your work is programming then you should delegate support to someone else. Probably a knowledgeable person about the software and some programming/technical skills to solve trivial problems.
yonasb 15y ago
Solution: use join.me or Print Screen + email and description
- m_myers 15y ago
  In Windows 7, you can use the Problem Steps Recorder to handle screenshots and descriptions for you: Start -> Run -> psr.exe. (Stolen from the Reddit thread: http://www.reddit.com/r/programming/comments/p9mxq/dear_boss_for_a_programmer_10_minutes_3_hours/c3nmwfd http://www.reddit.com/r/programming/comments/p9mxq/dear_boss...)
darwindeeds 15y ago
Ed really wasn't working but just reading HN. He is one of those guys who is always busy but doesnt do anything. The problem is Ed's boss thinks that he is actually good. The problem is not just with Ed though, his boss should have had Sue on call before get Ed on. Sue is lazy too. This is a company that is not getting anywhere. :)
dubajj 15y ago
In the time he spent reading HN, you could instead write an automated test hook to make sure this problem never happens ever again. Ed is a bad employee not because he is wasting time, but because he is publicly cultivating a culture of blaming time sink on others.
- bitops 15y ago
  I think it's a disgrace that your comment is near the bottom of this thread. Ed's attitude sucks and he will cost the company money. The people down voting you don't seem to care much for having a work ethic.
nirvana 15y ago
I think this illustrates a fundamental problem with the people being hired to manage programmers. I worked for a boss like this at Amazon. His degree wasn't even in business, but in criminal justice-- he was trained to be a prison guard and acted like it. His boss was even worse- I swear she must have been an ex-DMV employee, all attitude, no knowledge. (I forget her area of study but it had nothing to do with management, business or computer science.) A previous boss was-- and I am not kidding here at all-- a grade school teacher. He was in charge of the programmers. Knew nothing about programming but since the company was making educational software, obviously an gradeshool teacher should be running the department, right? The person running the art department was also a grade school teacher. They all had mastered that patronizing "settle down children" tone, and used it constantly. When we'd tell them that what they were asking wasn't practical or would take extra time, they'd be patronizing like we were trying to lie about having spilled milk. It is hilarious in retrospect. Why does senior management at these companies think that programmers should be managed by people who know nothing about programming?
- herge 15y ago
  The term I recently discoved for these people is Non-Technical Middle Managers.
  - gte910h 15y ago
    I've worked with tons of non-technical middle managers. The real trick is to not budge on estimation math. P=Programmger M=Manager Bad one: P.Here is the estimate. M.I want it done faster. P.Okay cut things. M.No. P.Well, it will still be done according to the estimate, as that's math. We have to change what we're doing to shorten the estimate, we can't just arbitrarily shorten it. M. I expect it done in 70% of the time on the estimate. All Done. Or Else. Okay one: P. Here is the estimate. M. I want it done faster. P.Okay cut things. M.Take out so and so and do so and so less well. Good one: P.Here is the estimate. M.What are things we can do to shorten this? P. Okay, we can de-risk items 1, 2 and 17 by limiting the requirements to X, and we can save a ton of time if we drop the requirement we can display right to left languages as well. M. Let me run the first thing by the client. M. The second won't fly, but even 10% is good. I've worked with some EXCELLENT ones as well as some so so and some poor ones. The real trick is: Remember, their boss probably ALSO thinks they're not that good if they pull crap on their reports. Push back, and do well because of it.
PaulHoule 15y ago
This has a lot to do with the claim that some programmers are 10x more productive than other programmers. If this happens to you more than once a month, you're not in the 10x club. If you want to be in the 10x club you need to avoid this at all cost. Otherwise you're just another muggle chafing at the bit.
- sukuriant 15y ago
  If circumstances beyond your control happen more than once a month, you're not in the 10x club?
  - PaulHoule 15y ago
    Ok, I exaggerated. But you've got to have dedication if you truly want to "Have Fun At Work"
    - sukuriant 15y ago
      I don't understand the connection to the article
  - dredmorbius 15y ago
    I think the message is to change your environment such that you're not getting this sort of interruption. I interviewed, three times (and turned down, three times) with a firm that apparently really wanted me. Why? 1: They were a very small vendor working for a very large client. The client is a household (swear) word, and behaves in a gratuitously overbearing manner to its customers and other vendors. 2: Everyone I spoke with admitted that this relationship lead to many, many last-minute changes in spec requiring much overtime and pain to make things just so. All while praying that things wouldn't change yet again at the next last minute. I said "thanks, but no".
rickmb 15y ago
Dear programmer: If the Boss asks you something, it's okay to say "no". Since your boss is apparently unaware of the problem, who's going to solve it if you don't speak up? There are no magic hacker fairies on HN that are going to do that for you.
- barefoot 15y ago
  Be careful about how you phrase "no". Sometimes an explanation of what's involved, previous times on similar tasks, and a question ("sure, would you like me to go ahead and start now?" after explaining that it will likely take two hours instead of two minutes) goes a lot further.
  - tomflack 15y ago
    I agree with you and the parent. It's a conversation you need to have at least once. Explain your workflow, getting in the zone, etc. Explain why there is a ticketing system. Explain the disruption to the productive day that interruptions like this bring. It totally sucks that you can't just be a semi-independent craftsman who works on what comes their way in a nice orderly queue, but that's the reality of today's workforce. If the interruptions keep happening time and time again after having this conversation and following up on it, then at least you know where you stand in this company.
- wisty 15y ago
  The problem is, you suddenly have an onus to be polite about it. "I have a concern that this may not be feasible". "No, you just have to try harder!" "Sorry, I wasn't very clear: This is flat out impossible". "Are you sure?" "Yes, because google tried, and couldn't do it. You see, it's actually impossible to get the (technical mumbo jumbo) so it will take literally years to run a single query." And this isn't a typical case. The most likely case is you suspect that the boss is leading everyone into the valley of death, but can't prove it. Do you confront them yourself, try to sound out other colleagues (who may have other concerns, since it's not their problem), or just warn them that there's likely to be problems, and gradually manage their expectations? In an ideal world, bosses are good at both ferreting out concerns fro indirect hints ("I'm a bit worried that"), and dealing with direct statements ("It's impossible, you git!"). In reality, they are often just wage slaves who kiss up and kick down, and don't really care if the project flops as long as someone else is to blame.
aidenn0 15y ago
We should thank this boss for subsidizing all of edw519's comments on HN
hc8217 15y ago
Ed needs to learn how to multi-task.
strictfp 15y ago
Dear programmer, when your boss says 'can you spare 10 minutes for me' he probably means 'can you help me take care of this exceptional situation'. The bug was probably severe and the boss wanted a dev to confirm that it was live before taking it to the steering commitee. The only slight wtf is how the boss worded that request. But taking something to the steering committe is a pretty big deal, so I understand that he would want to confirm it!
strictfp 15y ago
Dear programmer, when your boss says 'can you spare 10 minutes for me' he probably means 'can you help me take care of this exceptional situation'. The bug was probably severe and the boss wanted a dev to confirm that it was live before taking it to the steering commitee. The only slight wtf is how the boss worded that request. But taking something to the steering committe is a pretty big deal, so I understand that he would want to confirm it!
lesterbuck 15y ago
I guess I am hopelessly naive, but why is a ticket accepted without a short screencast of the issue? There are a number of free/cheap screen capture programs these days. There was no need for Ed's involvement (or his manager's involvement) until the problem had been captured. If submitting a ticket ends up meaning the developer sits there live as the user reproduces the problem (again), then the support department has much bigger scalability issues.
- cobralibre 15y ago
  But that, too, would be overkill. From TFA, here is the issue: OK, if I go into the main menu, click "Operations", then click "Sales", then click "History" it takes me to the Sales History Menu. See?... Then I click on Sales History Display by Part. I enter "R27-93" and the main screen pops up. Then I click on Invoices, I hit F5, then F3, then F7, and the Invoice Part Number changes to "GT548". This should never happen. What gives? What makes the article so mordantly funny is that it takes hours to get to this. Somebody could have typed out a description of the problem in minutes.
Hominem 15y ago
This is my life. All day. Every day. Along with status checks every 15 minutes. I love it though, every problem is an adventure. I couldn't be one of those dig in for a month and code developers.
rauar 15y ago
now he should know why he's the boss :p
Flemlord 15y ago
I feel sorry for the boss. Ed sounds disgruntled and/or lazy -- waiting for somebody to call you back, respond to email, or join a meeting is not an excuse to surf all day.
- bitops 15y ago
  Agree. The comments getting the up votes seem to think that techs should just sit around while the dumb users get their act together. Ed is as much a part of that team as everyone else.
- yason 15y ago
  Then what could he do but wait? Stare mindlessly to the screen, waiting for the flow to kick back in just to be interrupted again by another email or ring? To preserve your mental health, you need to do something sensible while waiting for your stack of work to clear ahead. Reading HN is probably one of the best and productive activities.
deleted 15y ago
[deleted]
tkellogg 15y ago
it reminds me of waiting for gogot
trout 15y ago
After doing this a few times a day for years the correct answer would be, "alright get them on the meeting recreating the problem and invite me when they're ready. " On average it takes 15-30 to get to someone else's screen to a productive point.
erdevs 15y ago
This is gross. Not the fact that the conference call was a mess of technical difficulties, or that Ed's boss interrupted his workflow. That Ed sat back. That the company's culture would even tolerate anything near this level of lackadaisical disengagement. If you're a Hacker, you don't say things like "that's not what I'm paid to do." You don't even think things like that. Your job is to help make your company, and those around you, successful. If you're not in a company with a mission you believe in, where you are excited to help achieve the goals the whole team is working toward... then freaking leave. Can you not find a job programming at a company that you do believe in? Then you're not a Hacker. You should probably stop reading Hacker News. The failure in management here isn't interrupting Ed. It's allowing such a lazy, selfish culture to exist in the first place. It's not inspiring Ed enough that he actually wants to help his co-workers be more efficient, because he realizes they are valuable components of the engine that is trying to accomplish a shared mission and set of goals too. It's not firing Ed's ass any of the number of occasions where he has doubtless sat back and watched teammates make mistakes without even trying to help. This is really, really gross.
- sukuriant 15y ago
  I think you're being a bit too hard on Ed. A lot of things need to be answered. How many times has this happened that he's had to deal with? How many times has he tried to explain to his boss that things take a lot of time? How many times has he tried to help and only confused them more? How many times has he been reprimanded by his boss for trying to help with these tasks? Also, how is Ed lazy? The chance of needing to speak up at a given moment is so high he couldn't adequately do another task, especially a programming one, or any task that requires a high amount of focus.
  - gaelen224 15y ago
    You are right. It is a little too harsh toward Ed. I think the general point is correct, though. The management failure here is much deeper. The culture apparently tolerates interruption of important work. Firedrills over relatively trivial problems. Leaning back and watching teammates fumble. And just generally not solving problems in efficient ways, looking for and resolving root causes. It is clear that Ed is not happy or fired up. The company sounds lame. I'm sure this is not the first time something like this has happened. Otherwise, why complain about it? And rather than leaning back and watch the slow motion car wreck over and over, I think erdevs is right... this is pretty lazy and lame. The company sounds lame too. Seems like the Hacker Way would have Ed either leaving such a lame place, or intervening at this place to try to help level the company up as best he can.
chaostheory 15y ago
Ed, I hate to ask this question, but given all the posts that I've read from you on the subject; why do you still work for that company? Am I wrong to assume that most of your work related posts center on the same company? One reason that I bring it up is that I've been there, and I've moved on to greener pastures. Where I've been still isn't perfect, but it's way better than the distant past. Your posts bring up a lot of bad memories for me. I could barely even make it past a year in that situation.
devs1010 15y ago
This brings up nightmares from when I worked remotely for a startup (they had no in-person office, by the way) and the boss was obsessed with WebEx, I had issues with it working on Ubuntu, also, so I would have to boot up a VM each time to use it. It got to the point where I told him every WebEx we do is a minimum of 1 hour of time wasted for me so lets make sure we really need to do a WebEx before we go down that path.
mathattack 15y ago
It's amazing how many folks at a software firm struggle to make a videoconference call, let alone a 3 way call. :-) Then again, in a prior life as a telecom consultant, I couldn't get 3 way calling to work on a landline.
malandrew 15y ago
Sadly, 3 hours is just the lower limit. The upper limit can be the whole day. 3 hours is how much time is wasted in the call. Depending how complex the task you were working on before the interruption, it can take up to the rest of the day just to re-immerse yourself in the problem you were solving before being interrupted.
readme 15y ago
Reminds me of http://www.thewebsiteisdown.com/ http://www.thewebsiteisdown.com/
scotty79 15y ago
I think the problem is that people are allowed to open their physical mouths when they are in the presence of the developers. I worked in one company that was managed nearly perfectly. If someone came to the developer to tell him something, he wasn't met with "hello". He was met with "Write a ticket!". Even though all employees occupied almost undivided space of less than 50 sq meters. Ticket system was only legal means of communication. Tickets had to be written well because you had no other way to reach the developer with your message. From time to time developer came to the ticket issuer to verify some details but he might as well just ask further details in ticket comments. There was one half an hour meeting per week that was attended by product manager that knew what she wants and two or three programmers working on the interconnected parts of the same thing. Product manager was available for instant contact for the developers at any time and had enough decision power to respond instantly. Developer could talk to the other developer when he had an issue or was interested in what the other developer was doing and if he has any issues. These "meetings" where usually announced via skype or happening at natural time when target developer was already out of zone because he was just getting back from toilet of with fresh cup of tee. There were of course "sky is falling" events that needed to be responded to urgently. There were communicated to developers by product manager via skype or in person but they were rare and serious enough so the developers wanted to deal with them in the first place to get "I just saved the day" feeling. Ticket system was the communication hub, wiki and google docs were the knowledge hub. Skype was when you have to ask someone about something but you don't want to make noise or interrupt them. And mouths were for drinking tee (or coffee) and swapping short remarks with the developer that is at the moment looking at the same physical screen as you do. And no slacking off because you monitor is visible to everybody. I think that the issue described by the blog post author would be resolved by "boss" telling Sue to describe step by step how to reproduce the issue or record a movie of her reproducing the issue and create a ticket for the developer with that description or the link to that movie. Boss could further (if it's really important) ask the developer politely at 30 minutes Monday meeting if he could take a look at this issue (after checking of course before the meeting if developer didn't do that yet). If you allow for other thing of communicating business issues (like email, skype, meat flapping) then the ticket system becomes cargo cult device that no one really pays attention to.
SonicSoul 15y ago
this hits so close to home. I have a manager who often claims a given task is "really simple" (especially in meetings) and when assigning some of these simple tasks he informs me that they should take 10 minutes. The funny part is to watch him take on some of these 10 minute tasks, and watch him cooped up in his office for 5 hours screaming at various pieces of software (i.e. visual studio or IIS) not behaving in a manner suitable for said 10 minute task. After the 10 minutes (plus 5 hours) of working on it, he'll call me into his office and ask me why his local IIS isn't working and that "it doesn't make any sense"... will spend another half hour troubleshooting all his issues, and 10 minutes after that his fix is ready to enter the release cycle.
dmbaggett 15y ago
To me this seems to be about valuing time and personal discipline as much as programmers/creatives vs managers. I know programmers who value their own time as poorly as the manager in this story. One would always find these programmers in the kitchen, posting long manifestos on their blog (they have a blog?!) or HN, etc. -- almost never producing any actual code. And I know managers who work very hard to protect their charges from distraction. Most (maybe all) of the very best programmers and managers I know are incredibly disciplined and value their time extremely highly. The never do what I'm doing right now (post on HN) or wander the halls chatting with people unless there is some specific objective they are trying to accomplish in doing so. The browsing-HN part of the story really struck me. Back at the dawn of the web, when surfing-while-compiling and surfing-while-on-concall first became possible, I worked with Andy Gavin at Naughty Dog. Andy is an extraordinary programmer, but not just because of experience and smarts; he's also very disciplined. When he's waiting for a build to finish, or engaged in some other "idle" activity, he switches emacs buffers and starts working on something else. He doesn't just browse the web while waiting for something; he works in parallel on multiple problems to make the most efficient use of time. He's never really idle. This is pretty hard to do, and requires great discipline. But it means that Andy automatically gets 10-20% more done in a typical work day than his exact equivalent who is surfing while compiling. And he probably has a lower "switching cost" than most, because he's practiced switching so much he's really good at it. Likewise, the best developers I worked with at ITA Software would write code and fix bugs during what would otherwise be time-wasting periods: during pointless concalls, on airplanes, etc. Personally, I am now so busy that I measure disruptions in terms of percentages of my day or week. E.g., taking one hour for lunch means I just consumed somewhere between 1/8th and 1/16th of my productive time for the day. (And since I am now in my 40s, I have to be realistic: it's closer to 1/8th than when I was 20-something.) Ditto for a one-hour concall. And then there's switching cost, time to get focused, etc., so multiply those costs by, say, 1.1 for the transitions. Once you start measuring time-cost this way, you quickly realize that it's not just the PHBs at your particular megacorp -- it's the entire world that's set up to distract you from getting anything done. The very fact that everyone still wants to talk on the phone when it's 10-100 times less time-efficient than emailing or texting a 150 character message is evidence that most people's social needs outweigh their desire to be genuinely productive. And, to be fair, most people view the kinds of people HN readers laud as "10x programmers" as dysfunctional, miserable, obsessive workaholics. I don't think you have to have "engineers all the way up" to make a software organization productive. I think you need to have disciplined people who value time very highly all the way up. Engineering fields tend to emphasize discipline, patience, and focus, so good engineers often have these qualities. But some non-engineers do too, and not allowing these people to help run your company is, IMO, a mistake that leads to less creativity and more group-think. This post just cost me 30 minutes: 1/8th of my possible productive time today. But it's OK, because it's Saturday.
feralchimp 15y ago
How this should have gone: Boss: we have a problem in production. Can you take a look at it right now? Ed: What's the ticket number? Boss: Sue entered it; I'll get it from her. [Boss gets ticket number; in the meantime Ed does something else productive.] Ed: Thanks Boss; I'll call Sue if I can't figure this out from the ticket. By when do you need an update? Boss: I'm concerned that pending changes could hold up a fix for this. If that's the case I'll need clearance from Steering before we can patch it. Let me know if this needs a code change, and what else could be affected. Ed: Right-o. [taptaptap]
- nandemo 15y ago
  Exactly. You wrote what I meant to write in my comment, but much more concisely. (however, it's quite possible Ed has mentioned the problems in the process many times. At some point, people give up and concentrate on doing what they can.)
lnanek 15y ago
I've always been able to multi-task pretty well. If one feature/bug requires a long test run, or review by someone else, or an email back and forth I can often switch over to another copy of the code and work on another. This has actually backfired with micromanaging bosses, though. I remember once the whole engineering team at a startup agreed I could fix the file size of an app as I went. So I worked a new file compression into a commit that involved the files anyway. Unfortunately, it looked like it took three days when it actually took a couple 10 minute sessions with a glob command line as it went through the review process, but was interspersed with other work. Well the manager went nuts against this change. Argued in emails citing problems that had long been fixed in the review thread emails, making up a bunch of incorrect complaints (he couldn't understand the difference between AAC and AAC+ and how they had different device support, and after having it explained to him, started with just vague "it's too much change" bullshit that couldn't be corrected). When I talked to him over IM about it later he admitted the real reason was because he said it took me days to do it and he wasn't going to approve any work on it no matter what. He was always the sort of guy who did the popular thing in big meetings with the employees, then pulled the rug out in private.
jmboling 15y ago
So tired of misleading headlines like this that pump up engineer ego... stop feeling better than everybody and work with people as good as you think you are -- or stop complaining.
mrstinton 15y ago
Sounds to me like the boss is an idiot. Did they really need to screw around with a web conference just to demonstrate that there was a bug in the sales history display? He should have had Sue just paste a couple of before/after screenshots into a doc file with a sentence or two of explanation and send it to Ed. "Here's the sales history for R27-93 (screenshot)... I hit F5, F3, F7 and the part number now incorrectly shows GT548 (screenshot)..."
jeffool 15y ago
I worked an overnight shift as a TV news producer, and was told to watch a recording of an earlierweb conference. The entire thing was a recording of the wrong monitor. I tried explaining to my boss that watching this wouldn't help me learn the new software, as if such oversight is required for most heavy computer users, but he insisted I watch it anyway, just so he could tell corporate everyone had seen it. After he failed to understand that the video contained no video of the software, because corporate could do no wrong, I told him I would watch it. The things one does...

699 points by joshuacc 15y ago

ChuckMcM 15y ago

This is so true. The sad part though is that during the 3 hrs Ed was stuck reading HN not doing something productive.

pavel_lishin 15y ago
> reading HN not doing something productive Hey now, what are you trying to imply? :)
bitops 15y ago
Ed could have shortened the time by helping. Really poor team attitude.
- lawnchair_larry 15y ago
  Helping how? Telling her boss to share control? Telling her where to click? There was absolutely nothing Ed could have done, and it's the expectation that he can fix every little thing that is the root of these problems.

ww520 15y ago

This is what happens when there's no tech support people to interface with the users and translate the problem into engineering tickets. You either train the business users to be able to articulate the problem clearly and document the reproduction steps in the ticket, or the boss should have served as the interface to the business users to do the translation. Otherwise the engineers will be doing all the supports. As corporations continue to downsize, the remaining ones will take on more and more responsibility.

a3camero 15y ago
"I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?"

bingo_cannon 15y ago

3 hours and late lunch!

davux 15y ago

We all know that context switching is bad, and it's tough to switch so much, but did Ed really have nothing else to do? He seems bothered by what the boss was asking him, yet he blows most of the 3hrs not working on what he said he needed to work on originally? That just doesn't add up to me. I get the point, and it's definitely true, but I spend those idle minutes doing mail and other short tasks. I don't see how one can justify "well I'm waiting for you so I'll just not work for a while." Is this common outside of the computing industry? What do other people do in their 'in between' time?

pavel_lishin 15y ago
A lot of times, there isn't anything you can work on that doesn't require a lot of concentration. I got an interrupt earlier today that put me on hold for an hour, while an email chain tried to sort out what was necessary. How can I focus on implementing a hard feature when at any point, someone might pull me away from it and knock down my house of cards? Hell, even if I'm writing code and suddenly I have to actually start working on a different project, I have to commit what I was doing, and try to squash everything later, or start stashing code around, and set up the other project's environment, etc. That's five minutes eaten up already.
- randomdata 15y ago
  I find learning something new doesn't require a lot of context switching, and while does not show immediate productivity, the long term gains to the organization are present and quite valuable. It beats just randomly surfing the internet anyway; bean counters may not agree.
fleitz 15y ago
Ed allocated his time according to his bosses request. During the entire time he was dedicated to making progress on his action item. If his company allocates time so poorly it is not Ed's fault. His boss clearly deprioritized his other tasks probably because he poorly estimated the time required by close to 2 orders of magnitude.
div 15y ago

deleted 15y ago

[deleted]

j45 15y ago

Ed, the funny thing is I have customers that end up paying to do this. I give them an answer and then they take 3 hours going in circles to arrive back at my first email. I am slowly coming to see it as them paying for time towards their education when they decide to insist understanding the inner workings of something better than someone who has built it. Despite my best to bring it to their attention to send me the information complete and once to get the quickest resolution, folks feel productive when going back and forth. I squarely blame this on the Blackberry exec mindset. Talking all day by email or IM or phone doesn't mean you get anything done. If you point it out, they won't like finding out they're the cause of slowing everything down, because they're so important. 0.02

yxhuvud 15y ago
Indeed. It is often more effective to ask the right questions so that the other part can arrive at the correct conclusion by themselves instead of telling them the conclusion from the start.

nlawalker 15y ago

Heh, I love the detail on all the confcall/web sharing problems. Every conf call I join includes at least two of the following. - The leader who is in the conf room calls in from the table phone and from their PC and can't figure out how to stop the screaming feedback. What's funny about this one to me is that the same people do it every time. - Tom calls from his car. He must be on the interstate, judging from the road gradient we can hear. - Dick joins from his laptop, where the microphone is conveniently part of the same physical device as the keyboard. CLACKCLACKCLACKCLACK. - Harry is working from home. We become intimately familiar with his three-year-old daughter's escapades with Cheerios and love of Phineas & Ferb. - Judging from the number of sirens, Jake apparently lives in a bad part of town or is watching Blues Brothers in the background. - Lucy has apparently joined while sitting in a conference room, attending another meeting simultaneously. - Robert joins 15 minutes late and would like everything he missed to be recapped. - Mark absolutely will not let the meeting progress unless someone is recording. Everyone spends 10 minutes figuring out how to do this. No one can find the file at the end of the meeting. - James calls in via a VOIP connection from India, introducing a slight delay. "Hello?" "Hellohello" "Hi James, can-" "Hello" "Hi James, we are-" "Hello, hi yes-" "Hi James-" - Dave joins from the airport. According to the PA, someone named Janice needs to report to the ticket desk. - Mike has apparently set his cell phone ringer volume to "over 9000" and has placed it next to his mic. - "Can you see my screen?" "No". "How about now?" -cue pictures of cats- "Yes but I think you have shared the wrong monitor." "How about now?" -cue spreadsheet- "Yes." -cue scrolling that the video broadcast can't keep up with- "Now if you can see here, here and here..." Mass meetings are the funniest. During one surreal leadership presentation where hundreds of people joined via a web meeting and many more were present in person, someone forgot to lock down presenter rights, and people kept drawing on the slides.

sbov 15y ago
Heh, onetime I had to get on a conference call when the blue angels were in town. "No, I don't live in a war zone, sorry about the noise."
- pagekalisedown 15y ago
  Ditto for Tuesdays at noon.

mkramlich 15y ago

He nailed it. I've experienced situations like that many times in my career. I'm now trying to live a life where I minimize my exposure to such Dilbertesque phenomena. Life's too short to piss it away on stupid people and inefficient processes.

Shengster 15y ago

I had something similar happen to me earlier in the week. The conversation went something like this: Boss: Hey, we've got an urgent production issue that needs to be looked at. I'm getting some heat on this one and I need someone to diagnose it to see if it's a blocker for our release. Me: Would you be able to ask X and Y to investigate? It seems they are on the support rotation for production issues. It'll take me at least an hour to clean up what I'm doing and switch over to run the old production instance locally. Boss: It's urgent, I think you need to drop whatever you're doing and look at this. Me: OK, sure. (50 minutes later, as I'm almost done building the old production instance) ... X and Y come back from a meeting. Boss: I'll have X and Y look at this, you can go back to working on your stories for this sprint. Me: !@#?$

joelhaasnoot 15y ago
One of the advantages of doing eXtreme Programming with lots of pair programming is that we eventually setup machines to be assigned to certain branches. Costs more computers, but is more productive. The best thing ofcourse is to reduce that buildtime, but not a whole lot you can do there.
iy56 15y ago
Use a VM
- Shengster 15y ago
  Not enough CPU and Memory to do so. Our app is huge.
  - zikzikzik 15y ago
    How many lost hours make up for the necessary CPU and RAM?

baconner 15y ago

Funny... I assumed the punchline was going to be about the hours it takes a developer to get back into high productivity mode after interruption. Sure, bosses and customers frequently underestimate the amount of time these sort of calls take and an intermediary (support) ought to take a stab at pulling a clear issue out first, but they're not always wasted time. There's a lot of value in getting devs and customers talking directly. It just needs to be (and can be) planned in a way that avoids breaking up the developer productivity curve unnecessarily.

deleted 15y ago

[deleted]

tux1968 15y ago

The title reminded me of the old line about why programmers often confuse Halloween and Christmas... because Oct 31 = Dec 25.

golden_apples 15y ago
Reference Error: Dec 25 is not defined
tux1968 15y ago
thanks everyone for piling on the downvotes... lol

jgarmon 15y ago

This true for non-coder creatives, too. I can't count the number of times I've been asked to "look at a design" or "go over some copy" because three other employees had some feedback in some meting I wasn't a part of, but no one can remember exactly was "off" with the deliverable. We then have to do the SKype/email round robin until everyone has given their comments again. This gets even worse when we, the creatives, get feedback about functional changes. "When I click the checkout button, it goes to the shopping cart." "Uh...yeah." "Could you have an upsell page pop up between the two." "I can write the copy and spec the creative and functional design, but I can't change the button functionality. You'll have to get that prioritized in the next sprint." "We don't want to bother engineering. We need to get this done quickly." "It's a functional change. We have to involve engineering." "So you can't write the page." "I can write the page. I can spec the page. I can't build or deploy the page." "That's disappointing." "You have no idea."

ja2ke 15y ago
I only have meetings like that when working somewhere which has a discrete marketing department.

patrickyeon 15y ago

Hmmm, lots of "yeah, I hate it when that happens" comments. Does anybody have ideas on how to fight this? Does anybody keep track like edw did, and then use it to defend themselves for the next "just ten minutes" task? Successfully? I haven't been able to make a point about how it's not "just ten minutes" without coming off as rude/unhelpful/lazy. I've tried to explain the cost of context-switching, or push it off until I'm not being interrupted, or at least have other people do pre-requisite work first (filing a bug would've fast-forwarded to somewhere between 12:14 and 12:38 here). In my dream world, a manager respects (or fears) you enough that you can say "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock" and pull it off. Out here in the real world?

pavel_lishin 15y ago
I work for a small enough company, where my immediate supervisor commits code with the rest of us, and therefore understands these issues.
hluska 15y ago
Sorry to say this, but I think that the 'just ten minutes' task is a symptom of a much deeper corporate problem. For example, consider the boss in this story. Why does he/she think a task like this will only take 10 minutes? Is he a developer? Does he keep track of what is going on in other departments? Does he understand how a (seemingly simple) bug like this fits in the context of the whole project? Or, here's another question. Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate? Forgive me if I come across as being somewhat dismissive, but when I hear stories like this, I see signs of a very sick company that needs life support.
- patrickyeon 15y ago
  There is definitely a corporate problem (or many) here. At least the manager deciding that "this needs to be looked into right now" above edw's opinion, and the idea that the whole conf call + webconf dance was a better move than filing a ticket. > Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate? Exactly. How should one fight that these steps be taken, when your manager is trying to skip them? The thought process that I expect led to this situation were similar to "I could file a ticket, which will take me 5 minutes, or if I just show it to someone, it'll only take me 3 [not voiced: if nothing goes wrong.] That's working smarter!" Similarily, how do you convey to people the true cost of asking for something like this, instead of them treating everybody else's time and effort as externalities. Yes, there are signs of a sick culture. Culture is fluid though, so how does one push it back towards health? Preferrably without getting classed as difficult/rude/not-a-team-player and then having any argument you bring ignored.

mgkimsal 15y ago

The thing is, it really did take about 10 minutes, but they weren't consecutive. Yeah, it's a bit of a smartass comment, but also true. Some people really can be as productive (or close to it) doing 6 10 minute tasks in an hour, switching every few minutes between those 6. To them, they still just spent 10 minutes on each task, and they're oblivious to the fact that not everyone's work can be sliced around like that with the same degree of quality that theirs can.

eCa 15y ago
Doing (starting and finishing) six discreet tasks in an hour is not too difficult. Obviously those tasks are not very taxing. What is hard if you have one four hour task, and one task that requires your attention every fifteenth minute. It completely ruins the four hour task.
- Drbble 15y ago
  The hardest part is making sure no one finds out about all them, and that information doesn't leak between those discreet tasks. Indiscretions are killer.
  - eCa 15y ago
    Sorry. It was late. I obviously meant discrete, even though I didn't know about that difference (in my native language "discreet" has both meanings). So thank you.

csomar 15y ago

If this is happening frequently, then you need a support stuff. The support stuff will spend those 3 hours to get the actually problem and explain it to you in 10 minutes at the end of the day. If you want to focus, and your work is programming then you should delegate support to someone else. Probably a knowledgeable person about the software and some programming/technical skills to solve trivial problems.

yonasb 15y ago

Solution: use join.me or Print Screen + email and description

m_myers 15y ago
In Windows 7, you can use the Problem Steps Recorder to handle screenshots and descriptions for you: Start -> Run -> psr.exe. (Stolen from the Reddit thread: http://www.reddit.com/r/programming/comments/p9mxq/dear_boss_for_a_programmer_10_minutes_3_hours/c3nmwfd http://www.reddit.com/r/programming/comments/p9mxq/dear_boss...)

darwindeeds 15y ago

Ed really wasn't working but just reading HN. He is one of those guys who is always busy but doesnt do anything. The problem is Ed's boss thinks that he is actually good. The problem is not just with Ed though, his boss should have had Sue on call before get Ed on. Sue is lazy too. This is a company that is not getting anywhere. :)

dubajj 15y ago

In the time he spent reading HN, you could instead write an automated test hook to make sure this problem never happens ever again. Ed is a bad employee not because he is wasting time, but because he is publicly cultivating a culture of blaming time sink on others.

bitops 15y ago
I think it's a disgrace that your comment is near the bottom of this thread. Ed's attitude sucks and he will cost the company money. The people down voting you don't seem to care much for having a work ethic.

nirvana 15y ago

I think this illustrates a fundamental problem with the people being hired to manage programmers. I worked for a boss like this at Amazon. His degree wasn't even in business, but in criminal justice-- he was trained to be a prison guard and acted like it. His boss was even worse- I swear she must have been an ex-DMV employee, all attitude, no knowledge. (I forget her area of study but it had nothing to do with management, business or computer science.) A previous boss was-- and I am not kidding here at all-- a grade school teacher. He was in charge of the programmers. Knew nothing about programming but since the company was making educational software, obviously an gradeshool teacher should be running the department, right? The person running the art department was also a grade school teacher. They all had mastered that patronizing "settle down children" tone, and used it constantly. When we'd tell them that what they were asking wasn't practical or would take extra time, they'd be patronizing like we were trying to lie about having spilled milk. It is hilarious in retrospect. Why does senior management at these companies think that programmers should be managed by people who know nothing about programming?

herge 15y ago
The term I recently discoved for these people is Non-Technical Middle Managers.
- gte910h 15y ago
  I've worked with tons of non-technical middle managers. The real trick is to not budge on estimation math. P=Programmger M=Manager Bad one: P.Here is the estimate. M.I want it done faster. P.Okay cut things. M.No. P.Well, it will still be done according to the estimate, as that's math. We have to change what we're doing to shorten the estimate, we can't just arbitrarily shorten it. M. I expect it done in 70% of the time on the estimate. All Done. Or Else. Okay one: P. Here is the estimate. M. I want it done faster. P.Okay cut things. M.Take out so and so and do so and so less well. Good one: P.Here is the estimate. M.What are things we can do to shorten this? P. Okay, we can de-risk items 1, 2 and 17 by limiting the requirements to X, and we can save a ton of time if we drop the requirement we can display right to left languages as well. M. Let me run the first thing by the client. M. The second won't fly, but even 10% is good. I've worked with some EXCELLENT ones as well as some so so and some poor ones. The real trick is: Remember, their boss probably ALSO thinks they're not that good if they pull crap on their reports. Push back, and do well because of it.

PaulHoule 15y ago

This has a lot to do with the claim that some programmers are 10x more productive than other programmers. If this happens to you more than once a month, you're not in the 10x club. If you want to be in the 10x club you need to avoid this at all cost. Otherwise you're just another muggle chafing at the bit.

sukuriant 15y ago
If circumstances beyond your control happen more than once a month, you're not in the 10x club?
- PaulHoule 15y ago
  Ok, I exaggerated. But you've got to have dedication if you truly want to "Have Fun At Work"
  - sukuriant 15y ago
    I don't understand the connection to the article
- dredmorbius 15y ago
  I think the message is to change your environment such that you're not getting this sort of interruption. I interviewed, three times (and turned down, three times) with a firm that apparently really wanted me. Why? 1: They were a very small vendor working for a very large client. The client is a household (swear) word, and behaves in a gratuitously overbearing manner to its customers and other vendors. 2: Everyone I spoke with admitted that this relationship lead to many, many last-minute changes in spec requiring much overtime and pain to make things just so. All while praying that things wouldn't change yet again at the next last minute. I said "thanks, but no".

rickmb 15y ago

Dear programmer: If the Boss asks you something, it's okay to say "no". Since your boss is apparently unaware of the problem, who's going to solve it if you don't speak up? There are no magic hacker fairies on HN that are going to do that for you.

barefoot 15y ago
Be careful about how you phrase "no". Sometimes an explanation of what's involved, previous times on similar tasks, and a question ("sure, would you like me to go ahead and start now?" after explaining that it will likely take two hours instead of two minutes) goes a lot further.
- tomflack 15y ago
  I agree with you and the parent. It's a conversation you need to have at least once. Explain your workflow, getting in the zone, etc. Explain why there is a ticketing system. Explain the disruption to the productive day that interruptions like this bring. It totally sucks that you can't just be a semi-independent craftsman who works on what comes their way in a nice orderly queue, but that's the reality of today's workforce. If the interruptions keep happening time and time again after having this conversation and following up on it, then at least you know where you stand in this company.
wisty 15y ago
The problem is, you suddenly have an onus to be polite about it. "I have a concern that this may not be feasible". "No, you just have to try harder!" "Sorry, I wasn't very clear: This is flat out impossible". "Are you sure?" "Yes, because google tried, and couldn't do it. You see, it's actually impossible to get the (technical mumbo jumbo) so it will take literally years to run a single query." And this isn't a typical case. The most likely case is you suspect that the boss is leading everyone into the valley of death, but can't prove it. Do you confront them yourself, try to sound out other colleagues (who may have other concerns, since it's not their problem), or just warn them that there's likely to be problems, and gradually manage their expectations? In an ideal world, bosses are good at both ferreting out concerns fro indirect hints ("I'm a bit worried that"), and dealing with direct statements ("It's impossible, you git!"). In reality, they are often just wage slaves who kiss up and kick down, and don't really care if the project flops as long as someone else is to blame.

aidenn0 15y ago

We should thank this boss for subsidizing all of edw519's comments on HN

hc8217 15y ago

Ed needs to learn how to multi-task.

strictfp 15y ago

Dear programmer, when your boss says 'can you spare 10 minutes for me' he probably means 'can you help me take care of this exceptional situation'. The bug was probably severe and the boss wanted a dev to confirm that it was live before taking it to the steering commitee. The only slight wtf is how the boss worded that request. But taking something to the steering committe is a pretty big deal, so I understand that he would want to confirm it!

strictfp 15y ago

lesterbuck 15y ago

I guess I am hopelessly naive, but why is a ticket accepted without a short screencast of the issue? There are a number of free/cheap screen capture programs these days. There was no need for Ed's involvement (or his manager's involvement) until the problem had been captured. If submitting a ticket ends up meaning the developer sits there live as the user reproduces the problem (again), then the support department has much bigger scalability issues.

cobralibre 15y ago
But that, too, would be overkill. From TFA, here is the issue: OK, if I go into the main menu, click "Operations", then click "Sales", then click "History" it takes me to the Sales History Menu. See?... Then I click on Sales History Display by Part. I enter "R27-93" and the main screen pops up. Then I click on Invoices, I hit F5, then F3, then F7, and the Invoice Part Number changes to "GT548". This should never happen. What gives? What makes the article so mordantly funny is that it takes hours to get to this. Somebody could have typed out a description of the problem in minutes.

Hominem 15y ago

This is my life. All day. Every day. Along with status checks every 15 minutes. I love it though, every problem is an adventure. I couldn't be one of those dig in for a month and code developers.

rauar 15y ago

now he should know why he's the boss :p

Flemlord 15y ago

I feel sorry for the boss. Ed sounds disgruntled and/or lazy -- waiting for somebody to call you back, respond to email, or join a meeting is not an excuse to surf all day.

bitops 15y ago
Agree. The comments getting the up votes seem to think that techs should just sit around while the dumb users get their act together. Ed is as much a part of that team as everyone else.
yason 15y ago
Then what could he do but wait? Stare mindlessly to the screen, waiting for the flow to kick back in just to be interrupted again by another email or ring? To preserve your mental health, you need to do something sensible while waiting for your stack of work to clear ahead. Reading HN is probably one of the best and productive activities.

deleted 15y ago

[deleted]

tkellogg 15y ago

it reminds me of waiting for gogot

trout 15y ago

After doing this a few times a day for years the correct answer would be, "alright get them on the meeting recreating the problem and invite me when they're ready. " On average it takes 15-30 to get to someone else's screen to a productive point.

erdevs 15y ago

This is gross. Not the fact that the conference call was a mess of technical difficulties, or that Ed's boss interrupted his workflow. That Ed sat back. That the company's culture would even tolerate anything near this level of lackadaisical disengagement. If you're a Hacker, you don't say things like "that's not what I'm paid to do." You don't even think things like that. Your job is to help make your company, and those around you, successful. If you're not in a company with a mission you believe in, where you are excited to help achieve the goals the whole team is working toward... then freaking leave. Can you not find a job programming at a company that you do believe in? Then you're not a Hacker. You should probably stop reading Hacker News. The failure in management here isn't interrupting Ed. It's allowing such a lazy, selfish culture to exist in the first place. It's not inspiring Ed enough that he actually wants to help his co-workers be more efficient, because he realizes they are valuable components of the engine that is trying to accomplish a shared mission and set of goals too. It's not firing Ed's ass any of the number of occasions where he has doubtless sat back and watched teammates make mistakes without even trying to help. This is really, really gross.

sukuriant 15y ago
I think you're being a bit too hard on Ed. A lot of things need to be answered. How many times has this happened that he's had to deal with? How many times has he tried to explain to his boss that things take a lot of time? How many times has he tried to help and only confused them more? How many times has he been reprimanded by his boss for trying to help with these tasks? Also, how is Ed lazy? The chance of needing to speak up at a given moment is so high he couldn't adequately do another task, especially a programming one, or any task that requires a high amount of focus.
- gaelen224 15y ago
  You are right. It is a little too harsh toward Ed. I think the general point is correct, though. The management failure here is much deeper. The culture apparently tolerates interruption of important work. Firedrills over relatively trivial problems. Leaning back and watching teammates fumble. And just generally not solving problems in efficient ways, looking for and resolving root causes. It is clear that Ed is not happy or fired up. The company sounds lame. I'm sure this is not the first time something like this has happened. Otherwise, why complain about it? And rather than leaning back and watch the slow motion car wreck over and over, I think erdevs is right... this is pretty lazy and lame. The company sounds lame too. Seems like the Hacker Way would have Ed either leaving such a lame place, or intervening at this place to try to help level the company up as best he can.

chaostheory 15y ago

Ed, I hate to ask this question, but given all the posts that I've read from you on the subject; why do you still work for that company? Am I wrong to assume that most of your work related posts center on the same company? One reason that I bring it up is that I've been there, and I've moved on to greener pastures. Where I've been still isn't perfect, but it's way better than the distant past. Your posts bring up a lot of bad memories for me. I could barely even make it past a year in that situation.

devs1010 15y ago

This brings up nightmares from when I worked remotely for a startup (they had no in-person office, by the way) and the boss was obsessed with WebEx, I had issues with it working on Ubuntu, also, so I would have to boot up a VM each time to use it. It got to the point where I told him every WebEx we do is a minimum of 1 hour of time wasted for me so lets make sure we really need to do a WebEx before we go down that path.

mathattack 15y ago

It's amazing how many folks at a software firm struggle to make a videoconference call, let alone a 3 way call. :-) Then again, in a prior life as a telecom consultant, I couldn't get 3 way calling to work on a landline.

malandrew 15y ago

Sadly, 3 hours is just the lower limit. The upper limit can be the whole day. 3 hours is how much time is wasted in the call. Depending how complex the task you were working on before the interruption, it can take up to the rest of the day just to re-immerse yourself in the problem you were solving before being interrupted.

readme 15y ago

Reminds me of http://www.thewebsiteisdown.com/ http://www.thewebsiteisdown.com/

scotty79 15y ago

I think the problem is that people are allowed to open their physical mouths when they are in the presence of the developers. I worked in one company that was managed nearly perfectly. If someone came to the developer to tell him something, he wasn't met with "hello". He was met with "Write a ticket!". Even though all employees occupied almost undivided space of less than 50 sq meters. Ticket system was only legal means of communication. Tickets had to be written well because you had no other way to reach the developer with your message. From time to time developer came to the ticket issuer to verify some details but he might as well just ask further details in ticket comments. There was one half an hour meeting per week that was attended by product manager that knew what she wants and two or three programmers working on the interconnected parts of the same thing. Product manager was available for instant contact for the developers at any time and had enough decision power to respond instantly. Developer could talk to the other developer when he had an issue or was interested in what the other developer was doing and if he has any issues. These "meetings" where usually announced via skype or happening at natural time when target developer was already out of zone because he was just getting back from toilet of with fresh cup of tee. There were of course "sky is falling" events that needed to be responded to urgently. There were communicated to developers by product manager via skype or in person but they were rare and serious enough so the developers wanted to deal with them in the first place to get "I just saved the day" feeling. Ticket system was the communication hub, wiki and google docs were the knowledge hub. Skype was when you have to ask someone about something but you don't want to make noise or interrupt them. And mouths were for drinking tee (or coffee) and swapping short remarks with the developer that is at the moment looking at the same physical screen as you do. And no slacking off because you monitor is visible to everybody. I think that the issue described by the blog post author would be resolved by "boss" telling Sue to describe step by step how to reproduce the issue or record a movie of her reproducing the issue and create a ticket for the developer with that description or the link to that movie. Boss could further (if it's really important) ask the developer politely at 30 minutes Monday meeting if he could take a look at this issue (after checking of course before the meeting if developer didn't do that yet). If you allow for other thing of communicating business issues (like email, skype, meat flapping) then the ticket system becomes cargo cult device that no one really pays attention to.

SonicSoul 15y ago

this hits so close to home. I have a manager who often claims a given task is "really simple" (especially in meetings) and when assigning some of these simple tasks he informs me that they should take 10 minutes. The funny part is to watch him take on some of these 10 minute tasks, and watch him cooped up in his office for 5 hours screaming at various pieces of software (i.e. visual studio or IIS) not behaving in a manner suitable for said 10 minute task. After the 10 minutes (plus 5 hours) of working on it, he'll call me into his office and ask me why his local IIS isn't working and that "it doesn't make any sense"... will spend another half hour troubleshooting all his issues, and 10 minutes after that his fix is ready to enter the release cycle.

dmbaggett 15y ago

To me this seems to be about valuing time and personal discipline as much as programmers/creatives vs managers. I know programmers who value their own time as poorly as the manager in this story. One would always find these programmers in the kitchen, posting long manifestos on their blog (they have a blog?!) or HN, etc. -- almost never producing any actual code. And I know managers who work very hard to protect their charges from distraction. Most (maybe all) of the very best programmers and managers I know are incredibly disciplined and value their time extremely highly. The never do what I'm doing right now (post on HN) or wander the halls chatting with people unless there is some specific objective they are trying to accomplish in doing so. The browsing-HN part of the story really struck me. Back at the dawn of the web, when surfing-while-compiling and surfing-while-on-concall first became possible, I worked with Andy Gavin at Naughty Dog. Andy is an extraordinary programmer, but not just because of experience and smarts; he's also very disciplined. When he's waiting for a build to finish, or engaged in some other "idle" activity, he switches emacs buffers and starts working on something else. He doesn't just browse the web while waiting for something; he works in parallel on multiple problems to make the most efficient use of time. He's never really idle. This is pretty hard to do, and requires great discipline. But it means that Andy automatically gets 10-20% more done in a typical work day than his exact equivalent who is surfing while compiling. And he probably has a lower "switching cost" than most, because he's practiced switching so much he's really good at it. Likewise, the best developers I worked with at ITA Software would write code and fix bugs during what would otherwise be time-wasting periods: during pointless concalls, on airplanes, etc. Personally, I am now so busy that I measure disruptions in terms of percentages of my day or week. E.g., taking one hour for lunch means I just consumed somewhere between 1/8th and 1/16th of my productive time for the day. (And since I am now in my 40s, I have to be realistic: it's closer to 1/8th than when I was 20-something.) Ditto for a one-hour concall. And then there's switching cost, time to get focused, etc., so multiply those costs by, say, 1.1 for the transitions. Once you start measuring time-cost this way, you quickly realize that it's not just the PHBs at your particular megacorp -- it's the entire world that's set up to distract you from getting anything done. The very fact that everyone still wants to talk on the phone when it's 10-100 times less time-efficient than emailing or texting a 150 character message is evidence that most people's social needs outweigh their desire to be genuinely productive. And, to be fair, most people view the kinds of people HN readers laud as "10x programmers" as dysfunctional, miserable, obsessive workaholics. I don't think you have to have "engineers all the way up" to make a software organization productive. I think you need to have disciplined people who value time very highly all the way up. Engineering fields tend to emphasize discipline, patience, and focus, so good engineers often have these qualities. But some non-engineers do too, and not allowing these people to help run your company is, IMO, a mistake that leads to less creativity and more group-think. This post just cost me 30 minutes: 1/8th of my possible productive time today. But it's OK, because it's Saturday.

feralchimp 15y ago

How this should have gone: Boss: we have a problem in production. Can you take a look at it right now? Ed: What's the ticket number? Boss: Sue entered it; I'll get it from her. [Boss gets ticket number; in the meantime Ed does something else productive.] Ed: Thanks Boss; I'll call Sue if I can't figure this out from the ticket. By when do you need an update? Boss: I'm concerned that pending changes could hold up a fix for this. If that's the case I'll need clearance from Steering before we can patch it. Let me know if this needs a code change, and what else could be affected. Ed: Right-o. [taptaptap]

nandemo 15y ago
Exactly. You wrote what I meant to write in my comment, but much more concisely. (however, it's quite possible Ed has mentioned the problems in the process many times. At some point, people give up and concentrate on doing what they can.)

lnanek 15y ago

I've always been able to multi-task pretty well. If one feature/bug requires a long test run, or review by someone else, or an email back and forth I can often switch over to another copy of the code and work on another. This has actually backfired with micromanaging bosses, though. I remember once the whole engineering team at a startup agreed I could fix the file size of an app as I went. So I worked a new file compression into a commit that involved the files anyway. Unfortunately, it looked like it took three days when it actually took a couple 10 minute sessions with a glob command line as it went through the review process, but was interspersed with other work. Well the manager went nuts against this change. Argued in emails citing problems that had long been fixed in the review thread emails, making up a bunch of incorrect complaints (he couldn't understand the difference between AAC and AAC+ and how they had different device support, and after having it explained to him, started with just vague "it's too much change" bullshit that couldn't be corrected). When I talked to him over IM about it later he admitted the real reason was because he said it took me days to do it and he wasn't going to approve any work on it no matter what. He was always the sort of guy who did the popular thing in big meetings with the employees, then pulled the rug out in private.

jmboling 15y ago

So tired of misleading headlines like this that pump up engineer ego... stop feeling better than everybody and work with people as good as you think you are -- or stop complaining.

mrstinton 15y ago

Sounds to me like the boss is an idiot. Did they really need to screw around with a web conference just to demonstrate that there was a bug in the sales history display? He should have had Sue just paste a couple of before/after screenshots into a doc file with a sentence or two of explanation and send it to Ed. "Here's the sales history for R27-93 (screenshot)... I hit F5, F3, F7 and the part number now incorrectly shows GT548 (screenshot)..."

jeffool 15y ago

I worked an overnight shift as a TV news producer, and was told to watch a recording of an earlierweb conference. The entire thing was a recording of the wrong monitor. I tried explaining to my boss that watching this wouldn't help me learn the new software, as if such oversight is required for most heavy computer users, but he insisted I watch it anyway, just so he could tell corporate everyone had seen it. After he failed to understand that the video contained no video of the software, because corporate could do no wrong, I told him I would watch it. The things one does...