
Dear Boss: For a programmer, 10 minutes = 3 hours - joshuacc
http://edweissman.com/dear-boss-for-a-programmer-10-minutes-3-hours
======
nlawalker
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
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."

~~~
joshwa
I've been dialing into conference calls all week from China, where it's still
Lunar New Year. This means fireworks and firecrackers, from 8am til midnight.
Sounds just like shells and machine guns.

"No, I don't live in a war zone, it's just Chinese New Year."

~~~
seanmcdirmid
I have a hard believing that you'd be able to even do a conference call in the
thick of it (especially the new year eve fireworks). I can barely have a
conversation with the person in front of me, let alone do anything with the
phone. Truly, a war zone isn't that bad.

~~~
joshwa
I really thought I'd be relatively safe at 8am on day 8 of the holiday...
clearly not the case :)

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

~~~
veidr
I've known people who could do high-output context-switching like that; what
they taught me was that context-switching is a skill, and one gets better with
practice. (Just like power-napping!)

------
jgarmon
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
I only have meetings like that when working somewhere which has a discrete
marketing department.

------
Shengster
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: !@#?$

~~~
iy56
Use a VM

~~~
Shengster
Not enough CPU and Memory to do so. Our app is huge.

~~~
zikzikzik
How many lost hours make up for the necessary CPU and RAM?

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

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

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

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

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

------
patrickyeon
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?

~~~
hluska
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
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.

~~~
vacri
Eh? There was a ticket filed. Finding it is what took up part of the 3 hours.

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

------
davux
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?

~~~
div
I can't imagine doing any useful work in the scenario being described.

If I'm being strung along like that, knowing that my attention could be
required at any minute, it is extremely hard to load a chunk of code in my
head because any spare brain-cycles are reflexively spent trying to figure out
if my input is required yet.

This is very much like trying to read when you're tired. You'll read 5 pages
and then all of a sudden realize you don't even know what you read in the
previous paragraph.

Sure you can triage your mail and small tasks and quickly do the stuff that
takes 3 or 4 minutes, but I find that I often have just a few of those tasks.
Certainly not enough to fill 3 hours worth of time.

~~~
Shengster
Great response. It's hard to get any real work done when you have to
constantly context switch between different things. Ed didn't know that he'd
have to waste 3 hours of his time. It was only supposed to take 10 minutes
after all.

~~~
babebridou
I've often had people ask me how I could context switch all the time like I
did and stay sane and a bit productive. I usually reply this: "I might be a
bit rusty but I can still dual task". It's generally enough for them to
realize that they are asking me to do something that they would never accept
to do themselves. They might not know the first thing about computer science,
project management or actual IT work, but at least they understand that
they're doing something wrong when they see me multitask only because of the
additional work they give me.

Call that passive-aggressivity, social engineering or mind games, I call it
just a game. Multitasking at work is tons of fun when you've practiced enough
to recognize and leave all error-prone activities out of the picture. And it's
very good to make people double-check their problem before they come bother
you, even though you're behaving like an open and helpful guy all the time.

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

------
PaulHoule
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
If circumstances beyond your control happen more than once a month, you're not
in the 10x club?

~~~
PaulHoule
Ok, I exaggerated.

But you've got to have dedication if you truly want to "Have Fun At Work"

~~~
sukuriant
I don't understand the connection to the article

------
feralchimp
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
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.)

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

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

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

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

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

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

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

~~~
m_myers
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...](http://www.reddit.com/r/programming/comments/p9mxq/dear_boss_for_a_programmer_10_minutes_3_hours/c3nmwfd))

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

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

------
strictfp
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!

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

------
malandrew
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
Reminds me of <http://www.thewebsiteisdown.com/>

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

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

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

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

~~~
yason
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.

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

~~~
golden_apples

      Reference Error: Dec 25 is not defined

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

~~~
bitops
Ed could have shortened the time by helping. Really poor team attitude.

~~~
lawnchair_larry
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.

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

------
darwindeeds
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. :)

------
bingo_cannon
3 hours and late lunch!

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

------
tkellogg
it reminds me of waiting for gogot

------
nirvana
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?

~~~
reinhardt
I am curious, is this a common and similarly frustrating experience for non-
programmers? Are managers of, say, car technicians or accountants just as
clueless about their subordinates?

~~~
sutterbomb
May be worse for programmers, but it all comes down to a lack of ground-level
details. From 5,000 feet you can't see how thorny the bush is.

~~~
LearnYouALisp
As I read these comments, I was imagining a non-technical supervisor sitting
down a programmer on a relatively small project to learn how their work is
done, from start to finish. The project should be short enough for the manager
or like person to see it completed over a few sessions, including the
overview, the draft, and the testing and problem-solving.

The programmer would explain the goal of the new project, like so: "We need to
design a module that talks to the what-what the customer is using. It has to
do three things: it must take an order from the what-what, then perform the
appropriate action, and finally receive information back from the central
system."

"So, we begin with the first part of the module: the part that will take an
order from the what-what. It needs to listen for a message from the unit the
customer is interacting with. Then, it needs a rule concerning what to do with
each order, that is, what instructions to follow."

Once the basic form and actions of each section are established, then he or
she can explain in more detail the actual working parts: "Now we need to step
through the list of orders. With each order, we will check our rule set and
perform the appropriate action. Once there are no more orders, we will tell
the computer (or program) we are finished and it can proceed to the next step,
which is receiving information back from the central system."

Throughout, the programmer only needs to explain conceptually the work he is
doing: Even the difficult or intricate concepts (details of network
connections, perhaps) he may illustrate. The details of the actual programming
language do not need to be explained for this purpose. (That is, he does not
need to say, "Now we write 'Blob userOrders = new (Blob)' to create a new
blob", or "We will receive the orders from the customer into an array ("What's
that?") and step through them with a 'for' loop.") He or she might use a pen
and paper to draw a diagram of the module as they design it.

Once the manager has the overview of the system and knows how it is supposed
to work, perhaps they can follow the writing of tests for it: "We will send it
some simple test orders to see if it follows them correctly....And now we will
give it an illogical order--did we check for a bad order?"

Finally, the manager or supervisor can join the programmer as he or she goes
back to the code to identify the source of the trouble. (More details could be
added here.)

The programmer does not need to oversimplify, but as they go deeper into the
project together, the programmer can explain more technical details.
Previously, these details would have been distracting, overwhelming, or
incomprehensible to the the person they are teaching, but now they enable them
and are necessary to see what the program is doing at this level, and why the
problem occurred as it did.

Could this be a realistic scenario, in certain cases at least?

~~~
codeonfire
"Could this be a realistic scenario, in certain cases at least?"

No, the supervisor's primary motivation is to avoid blame while gaining power.
If they know how everything works, there is no deniability when their plan
fails. The game they play is to promise the impossible to their bosses in
hopes of promotion and blame the 90% that didn't go to their plan on the
programmers while trying to take full credit for the 10% that was pulled off
by heroic coding. To this end, no supervisor will be caught in a 'code'
conversation. If they understood software engineering they would be on the
hook for the 90% as well.

Where an honest supervisor needs to learn the fundamentals of software
engineering is at the school and then later as a software engineer. You can
get a BS in software engineering in many places and go on to obtain a Masters
in technology management. Also work 5-10 years in deliberate practice as a
software engineer. There is no 'sit down for an hour and learn software
engineering' just like there is no 'sit down for an hour and learn how a
nuclear reactor works'. What you are talking about is remedial training, but
none of these guys would go for it. Their philosophy is that people willing to
do technical work are simple fools to be exploited. Usually they are very glib
about the idea that they skipped all the hard technical stuff.

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

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

