The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#21

Post by dilyevsky » Tue, Jul 30, 2019, 1:40 AM UTC

opportune wrote: post #6

Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup .…

I mean this is from a company that forces pair programming down everyone’s throat (so that you don’t space out on hn as one of stated reasons) so what did you expect? =)

Re: The art of interrupting software engineers

#22

Post by jacques_chester » Tue, Jul 30, 2019, 1:42 AM UTC

philliphaydon wrote: post #18

I only read the first paragraph and couldn’t read anymore. I’m unsure why he cannot Know when a story will be delivered. A story should fit into a sprint and so he should reasonablely expect that it’s delivered at the end of that sprint. If it’s not going to be delivered then this information should be relayed back to the pm. Going and pestering the team is only going to slow down development process and increase the…

Pivotal doesn't use sprints. Stories are pointed by engineers and ordered by the PM, but they're done when they are done, to the satisfaction of both.

Tracker is able to give short-term forecasts of what will be done by when by averaging the last 3 weeks of deliveries (ie, velocity).

Personally I think the idea of sprints is a menace. It creates an artificial deadline that leads to either waste or stress. Deadlines should be reserved for actual meaningful deadlines.

Re: The art of interrupting software engineers

#23

Post by isoskeles » Tue, Jul 30, 2019, 1:43 AM UTC

opportune wrote: post #6

Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup .…

I agree with everything you wrote, but I also wonder if this is less of a distraction in the case of Pivotal since their engineers work in pairs.

Re: The art of interrupting software engineers

#24

Post by whycombagator » Tue, Jul 30, 2019, 1:44 AM UTC

40acres wrote: post #10

I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorr…

> daily sync (a.k.a stand up meeting)

*status report

> My team meets for 30 minutes each morning

That is far too long IMO and IME

> We're a small team (3 developers)

30 mins for 3 devs...

Re: The art of interrupting software engineers

#25

Post by jacques_chester » Tue, Jul 30, 2019, 1:45 AM UTC

dilyevsky wrote: post #21

opportune wrote: post #6

Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup .…

I mean this is from a company that forces pair programming down everyone’s throat (so that you don’t space out on hn as one of stated reasons) so what did you expect? =)

I don't know how you get the idea that it's forced.

We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them.

That is a good thing.

Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing but currently I'm working solo. If a pair decides they should work solo, they do. Lots of pairs have a rotating arrangement where somebody different works solo for a day or two. I know of teams where they are solo in the morning to review PRs and pair in the afternoon to work on new contributions.

None of this is enforced. There is no manual, no rulebook for The One True Way. Nobody tells you how to work. The way works is: the people are nice and smart and want to do the right thing. The rest is largely details.

Re: The art of interrupting software engineers

#26

Post by isoskeles » Tue, Jul 30, 2019, 1:47 AM UTC

I don't see the point in getting updates more than once a day. If something could change that you needed to know before tomorrow, isn't something else potentially wrong with the process?

The only case where I want such frequent updates are when (1) there's some P0 bug on production and it needs to be fixed / tested / deployed yesterday or (2) we're trying to pressure the person to want to quit their job or magically improve (more the former than the latter).

Re: The art of interrupting software engineers

#27

Post by Terr_ » Tue, Jul 30, 2019, 1:47 AM UTC

From the title I expected to see something a bit more, well, tactical about how to arrange communication by changing "real" interruptions into queued requests. For example, e-mails, or (varying by workplace-cultures) instant-messages that nobody expects immediate answers to.

Re: The art of interrupting software engineers

#28

Post by whycombagator » Tue, Jul 30, 2019, 1:49 AM UTC

jacques_chester wrote: post #12

I work for Pivotal. Product managers vary in how they work with a team, so this approach is new to me. As an anchor (approximately a tech lead) I made it my business to work closely with PMs on the product: giving feedback on how the technical direction was shaping up, asking for stories to be updated or broken apart, giving options for technical seams and so on. Frequently we embed product designers as well, so disc…

> In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse,

I don't want to read any further. Surely it doesn't get worse than that!

/s

Re: The art of interrupting software engineers

#29

Post by 40acres » Tue, Jul 30, 2019, 1:51 AM UTC

whycombagator wrote: post #24

40acres wrote: post #10

I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorr…

> daily sync (a.k.a stand up meeting) *status report > My team meets for 30 minutes each morning That is far too long IMO and IME > We're a small team (3 developers) 30 mins for 3 devs...

It's not just a status report, it's a casual discussion about the work. We collaborate on strategy, talk about any issues, and coordinate with each other. We front load information sharing so that it's rare to have to share information (ie. interrupt) at other times in the day.

Re: The art of interrupting software engineers

#30

Post by jacques_chester » Tue, Jul 30, 2019, 1:52 AM UTC

isoskeles wrote: post #23

opportune wrote: post #6

Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup .…

I agree with everything you wrote, but I also wonder if this is less of a distraction in the case of Pivotal since their engineers work in pairs.

Speaking for myself, I would give feedback to a product manager that asking during the day is unnecessary. I'd try to understand why the PM feels they need to.

But yes, pairing is very helpful for maintaining context when interruptions occur.