Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The art of interrupting software engineers

content.pivotal.io

Post reply on HN
Print view View original

191–200 of 255 posts

Re: The art of interrupting software engineers

#191

Post by pflenker »

disappearance wrote: post #187
pflenker wrote: post #115

Earlier quoted context omitted.

> So surveill and/or eavesdrop and/or ambush. Nice. It's common courtesy or some kind of "office ettiquette" that if Alice wants something from Bob, but doesn't want to interrupt, she waits until there is an opportunity. Returning from a break is an obvious cue.

I'll often go for a walk when facing a troublesome problem and return with an arbitrarily Complex model in my head. It would be an inconvenient time for an interruption, and probably looks quite a lot like returning from a break.

I just wanted to make the point that waiting for someone to return from a break before talking to them can be considered polite, instead of an impolite ambush as indicated in the previous comment. Of course, there is no one-size-fits-it-all solution.

Re: The art of interrupting software engineers

#193

Post by whatever_dude »

> 1. Check-in regularly

> I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with

Uuuuhhh...

If a PM did that with me when I have a lot of work to do it'd send me off the rails.

This article seems more to be about "what I have done as a non-technical PM to reduce my own anxiety at the detriment of my team".

It's hard to say without a lot of detail, but I think there's something disfunctional about the team or about how the project is structured in this example. How big are the tickets? It's common for a "user story" to take days or weeks; it can say something simple like "user can submit a form" but have a lot of big system dependencies that were not well thought out (a form system, a state system, a server component, etc).

Instead, tasks must follow a technical logic (a form system first, state management after, etc) and engineers should be left to do their own thing, with minimal "checking". Something like BaseCamp's "Shape Up" [1] comes into mind, with a few bets every cycle.

1: https://basecamp.com/shapeup/

Re: The art of interrupting software engineers

#194

Post by JJMcJ »

Saw a project where the PM would come around like clockwork twice a day. This was not a sprint project, it was a two year long push for a new product. What happened that every four hours a status update was needed?

People laughed behind his back.

Re: The art of interrupting software engineers

#195

Post by rev12 »

jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

> 4) Requirements are conveyed verbally, not through written documents.

I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along.

I admit to knowing very little about XP but this sounds like my own personal hell.

Re: The art of interrupting software engineers

#196

Post by bpyne »

There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in.

The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we walk to a nearby coffee shop. On the walk, we discuss issues and what we intend to accomplish for the day. It takes about 20 minutes.

Occasionally, we take a walk at the end of the day as well to discuss issues. When the manager calls for an end of day walk he senses our energy is low.

As I get older, I like routines in the morning. They help me get my mind in gear. We go for the coffee walk. When we get back I might read a short technical article. Then it's time to get stuff done.

Re: The art of interrupting software engineers

#198

Post by fit2rule »

I think there's an elephant in the room here, being overlooked:

>The engineers would give me highly technical explanation I couldn’t understand. This would frustrate me because I did not add much value and distracted them.

I have a rule which avoids this situation happening, ever, and its a controversial one, but bear with me:

* NEVER accept management from someone who cannot do your job.

This rule, hard and fast, has saved my ass so many times - and every single time I've broken it, things have been more painful than they should be.

Seriously, think about it. How can someone who isn't qualified to do your job, actually manage you? Only if 'management' is an administrative-only task - i.e. "report your hours worked - I don't care about anything else".

But if you put this rule into action and insist that your managers are able to do your job, you have a very strong, very stable organizational structure. This doesn't mean the manager has to do your job - just that they can, if they need to.

You can't manage things you don't understand. So never accept management from people who don't understand the job. And if that is not happening in the organization, you've got another problem: HR are just chair-stuffing. INSIST that this not be how your org is run.

Re: The art of interrupting software engineers

#199

Post by perlgeek »

> It masks the fact that I have expectations as to when something should be delivered and does not communicate urgency to the team.

But why mask the expectations?

IMHO the best thing you can do is it to communicate priorities (which is your job as product owner / manager), and then if you do need time-based estimations, work them out with the team -- with the clear expectation that they are provisional.

Setting up expectations yourself, and possibly communicating them, but not down, is just a recipe for stress and desaster.

Re: The art of interrupting software engineers

#200

Post by peteradio »

afarrell wrote: post #169
_betty_ wrote: post #139

Earlier quoted context omitted.

I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature. This practice is just saving time writing down behaviour that won't be implemented.

But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction? What do you do when people forget things?

You artfully interrupt them and always keep watch on what other people are doing!
Post reply on HN