Me, in the zone, staring at the code. Co-worker enters.
Co: hey, can you...
Me (not really listening): no.
Co: it's just...
Me: no.
Co: later?
Me: no.
Co: but...
Me: no.
Co: (leaving)

that is a fast-no(p)

@justmove lol'ed :-)

just no.

I love this rant ++

Should say that to my manager, she interrupts me all the time when I'm thinking about a programming problem...

@Phlisg Since I've discovered how much expensive context switches are, I've boosted my productivity by reducing them. I also use to ignore telephone and email when working. Email is in the morning with the first coffee, sifting through and prioritising.

Another thing is to educate co-workers and avoid enticing the lazy ones to ask stupid questions. When they ask something they could as well look up themselves, I feign not to know the answer and say "should be in document X, just read it up."

@Fast-Nop I usually ask "are you busy / can we talk later about X", it shouldn't be too much to ask to get an answer. If I get the "no" treatment constantly I'm going to have a problem if I were to work with that person, because I would be tiptoeing around trying to get help/discuss a topic and I hate that so much.

@Qwby if it's about looking up documentation, then you shouldn't be asking at all before you havn't looked up the docs yourself. No effort on your side to solve the problem means you don't care about it, and if you don't care, I care even less.

In the case of the rant, the only thing I wanted in that moment was the person to shut the fuck up and go away as quickly as possible, and I didn't even want to listen.

Three minutes of their time easily blast half an hour to an hour of my time in such a situation.

Later, I did call back to check what was going on.

Sure, it depends. If you work there for long enough you should be expected to know where to look stuff up. If the company has documented their processes that is. You don't want to know how often this isn't the case and you have to ask around how people are doing the stuff in their projects. And I sympathize greatly with people who are confused by this at first and need to go "information hunting" by themselves.

@Qwby that kind of introduction gets done in the first days when someone new gets hired. How the intranet is stuctured, where to find the projects along with their docs, what our dev process is, where the process docs are, where to find the relevant standards and all that.

For someone new in the project, I would also email him an intranet link where to find his project so that he can always look up this email as starting point.

@Fast-Nop let's just say there are a lot of things that could be improved in our structures and documentation, so I understand why people here go around asking other people for processes, best practices and stuff like that.

@Qwby yeah, with that situation, I guess it's suboptimal for everyone. I'd write it up.

When I started in my company, I had to use an important tool with a lot of gotchas, but no documentation. I wrote down all the issues and how to work around them while I was figuring it out, and now when someone asks me, I can point at the documentation.

That's a little more work once, but it makes things better for everyone in the long run.

@Fast-Nop thing is we would first need someone at least partially responsible for managing our wiki or define where and how to document stuff. Most people do document but in such different ways and places and detail that it just feels more convenient for people to ask "who worked on similar projects before" and get the necessary information that way. We're in the process of improving that though, or so I've heard.