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

221–230 of 255 posts

Re: The art of interrupting software engineers

#221

Post by havocheavy »

afarrell wrote: post #168
afarrell wrote: post #118

Earlier quoted context omitted.

I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.

To clarify, I'd be fine with pairing 8 hours a day, but I'd want: - Some sort of sound barrier so that I couldn't parse the background conversations. - To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.

Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations? Did it propel your conversation at all, or maybe give you something to talk about? When people talk about the buzz of activity in a busy place, it's really closer to a situation like this.

Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience.

On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.

Re: The art of interrupting software engineers

#222

Post by JJMcJ »

fit2rule wrote: post #198

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, ha…

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

Advice to college students and recent grads:

Q: Help, I just discovered I hate programming and aren't any good at it. What do I do?

A: Go in to project management.

So programmers are run by people who are self-selected for mediocre skills or even outright hostility toward programming.

Re: The art of interrupting software engineers

#223

Post by JJMcJ »

whycombagator wrote: post #20

> 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. This is monumentally bad advice. > I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break So surveill and/or eavesdrop and/or ambush. Nice. > Hadrien Raffalli is…

> a casual non-work related conversation

Programmer 1: Whoa, that two hour Pomodoro was quite something.

Programmer 2: We got a ton done, though.

Programmer 1: Yeah! I hope they have the lasagna again at lunch.

Project Manager: Hi, are you getting your work done? If you could get back to work, that'd be great.

Re: The art of interrupting software engineers

#224

Post by mugsie »

pflenker wrote: post #191
disappearance wrote: post #187

Earlier quoted context omitted.

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.

There is - schedule a meeting (even if it is a 15 min "sync") the day before, so I know I have a context switch coming up.

Re: The art of interrupting software engineers

#225

Post by klohto »

jdlshore wrote: post #220
klohto wrote: post #126

Earlier quoted context omitted.

I love this, makes me want to join team that practices this. What is your book name? I would like to buy it.

The Art of Agile Development. It's published by O'Reilly and quite a bit of it is excerpted on my blog at https://www.jamesshore.com/Agile-Book/ .

No chance of hardcover?

Re: The art of interrupting software engineers

#226

Post by nojvek »

whatever_dude wrote: post #193

> 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,…

I would pretty much quit if someone came and interrupted me in person twice a day to ask me how things are going?

In my decade of experience i’ve usually seen new PMs be extremely anxious and paranoid about timelines. As they get more experience and they see more projects that go off the rails they understand the tech speak a bit and have laxer expectations.

Sure we’ll be 2 weeks late, but in the grand scheme of things, it doesn’t matter. Don’t burn your engineers for a dumb deadline that makes little difference to the customer.

There’s a reason we have kanban boards and sprint boards. How are things going? Look at the board. The tickets are updated. Any blockers? Read the slack channel. Only interrupt in person when shit is really on fire. But even for that, the monitoring software will page the opslead.

Re: The art of interrupting software engineers

#227

Post by jpdaigle »

jacques_chester wrote: post #35
opportune wrote: post #17

Earlier quoted context omitted.

I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements

In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.

My preferred way to handle this is to explicitly acknowledge that the meeting isn't just sync-up, it's really two meetings:

- sync up / status is 15 mins. Any implementation discussion gets put in the parking lot

- once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive!

This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.

Re: The art of interrupting software engineers

#228

Post by pflenker »

mugsie wrote: post #224
pflenker wrote: post #191

Earlier quoted context omitted.

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.

There is - schedule a meeting (even if it is a 15 min "sync") the day before, so I know I have a context switch coming up.

In my experience, that is not an acceptable solution for everyone. I have worked with people who despise these kinds of scheduled short meeting, because "we are sitting in the same office and can always talk to each other".

That having said, my personal preference is also the scheduled 15 minute meeting.

Re: The art of interrupting software engineers

#229

Post by JJMcJ »

lonelappde wrote: post #184
lazerwalker wrote: post #140

Earlier quoted context omitted.

An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large. Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.

We invented books because human memory storage is phenomenally expensive. Why throw them awaym

"The dimmest ink is superior to the brightest memory" - so said Benjamin Franklin or maybe someone else.

Re: The art of interrupting software engineers

#230

Post by abc_lisper »

targonca wrote: post #165
abc_lisper wrote: post #89

Earlier quoted context omitted.

I think you jumped the shark here. The point of doing multiple checkins a day is to make good engineers feel like they are barely good enough, and make them hungry to please the bosses! Pavlov at work here, I think.

I'm not sure you're using "jumped the shark" correctly.

Sorry. I should have read before using that phrase.
Post reply on HN