The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#41

Post by godelski » Tue, Jul 30, 2019, 2:03 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…

You should probably have your management team look at these comments. How much hated it is getting. I can say from experience that I have quit because of a manager like this. Don't do this. You will lose any engineer that can get another job and be left with those that can't jump ship. I'll let you determine the quality of those engineers.

Re: The art of interrupting software engineers

#42

Post by catmanjan » Tue, Jul 30, 2019, 2:04 AM UTC

jacques_chester wrote: post #39

catmanjan wrote: post #36

Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company? I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...

I think lots of people have just had genuinely shitty experiences where they were slowed down in their work by interruptions or made to feel that they were not trusted as professionals. They see this and it fits a pattern and so they are fairly skeptical.

Yeah fair enough, I've been lucky and haven't been made to feel that way

Re: The art of interrupting software engineers

#43

Post by godelski » Tue, Jul 30, 2019, 2:07 AM UTC

JustSomeNobody wrote: post #11

raptorfactor wrote: post #3

If I had a PM come by my office twice a day to "check-in" I think I'd quit.

Same. I'd be pissed. I mean, if they have time to come by everyone's desk a couple times a day, WTAF are they doing and why are they getting paid for it?

> WTAF are they doing

Harassing engineers

> why are they getting paid for it?

Engineers got their work done despite the micromanage (to be clear, I mean despite and not because. Just in case any PM or manager is reading this and thinks micromanaging is why tasks get done)

Re: The art of interrupting software engineers

#44

Post by p1necone » Tue, Jul 30, 2019, 2:11 AM UTC

jacques_chester wrote: post #25

dilyevsky wrote: post #21

Earlier quoted context omitted.

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…

>>> 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... sounds like forced to me?

Re: The art of interrupting software engineers

#45

Post by edgarvaldes » Tue, Jul 30, 2019, 2:11 AM UTC

My manager expects a formal report once a month, but he is always open to conversation about the products we build. We end up talking daily, but it is never forced.

Re: The art of interrupting software engineers

#46

Post by jacques_chester » Tue, Jul 30, 2019, 2:13 AM UTC

catmanjan wrote: post #42

jacques_chester wrote: post #39

Earlier quoted context omitted.

I think lots of people have just had genuinely shitty experiences where they were slowed down in their work by interruptions or made to feel that they were not trusted as professionals. They see this and it fits a pattern and so they are fairly skeptical.

Yeah fair enough, I've been lucky and haven't been made to feel that way

I have had a mix of experiences in my professional life, Pivotal is by far my favourite, even when I've gotten super frustrated about particular problems (and I have). I've learned that lots of folks on HN or reddit hear about our common practices and suspect that it's at best chicanery and at worse a deception (all for the fiendish end of working fixed hours with enormous autonomy, dun dun duhhh!).

Those responses usually upset me, because I feel that my experiences are being devalued. I read the comments and I compare them to my life of the past five and half years and they just aren't the same. It can be hurtful to have casual snide remarks made when you know that the people you work with are kind, thoughtful, intelligent, hard-working humans through and through.

But I also know that other people have had bad experiences and what they hear sounds like other things they've heard from shitty managers and colleagues, so they're cynical. If I talk down to them then I am devaluing their experiences. So I try not to, even though my personal nature is to be an arrogant wanker.

Re: The art of interrupting software engineers

#47

Post by dfischer » Tue, Jul 30, 2019, 2:13 AM UTC

opportune wrote: post #17

dfischer wrote: post #13

Earlier quoted context omitted.

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async ar…

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

With a visual system like Kanban, it's quite easy to see what other people are working on. The problem I have with daily syncs is that it's redundant to information already available, and you're forcing people to "meet" without any value. A lot of conversations in that "sync" are just noise to a majority of participants. It's kind of like a bunch of people talking to a wall unless you happen to be associated directly with the update – which is more rare.

In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done.

Anything else... is very wasteful in my experience.

Re: The art of interrupting software engineers

#48

Post by hermitdev » Tue, Jul 30, 2019, 2:14 AM UTC

catmanjan wrote: post #36

Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company? I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...

I dont think it is generally vigalanty programmers, just that routinely and irregularly interrupting knowledge workers is counterproductive. Like, I've been debugging and researching a potential bug and I'm deep in thought about it, then a manager or PM walks up, interrupts your train of thought with something completely unrelated to what you're currently working on.

Context switches are annoying to the engineer and costly for development. Each context switch probably costs between at least 15 to 30 minutes, maybe more depending on what the engineer is working on. If that happens 4-6 times a day, you've potentially burned 1/4-1/3 of the day. I spent close to 3 hours in 3 unrelated meetings. So, 1/2 of my day was spent task switching and not really giving 100% attention in the meetings because of the constant task switches. Frustrating and don't feel like I made any progress today, on my first day back on an overdue week long vacation.

Re: The art of interrupting software engineers

#49

Post by jacques_chester » Tue, Jul 30, 2019, 2:16 AM UTC

p1necone wrote: post #44

jacques_chester wrote: post #25

Earlier quoted context omitted.

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…

>>> 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... sounds like forced to me?

It doesn't to me, so this might be a disagreement about the meaning of forced. Nobody is surprised that the default mode is fulltime pairing, we make a point of having candidates experience it beforehand.

And as I noted above, pairing isn't mandated. Teams are free to adopt any process they please, but most folks at Pivotal like the defaults and we tend to gravitate to them.

Re: The art of interrupting software engineers

#50

Post by dfischer » Tue, Jul 30, 2019, 2:16 AM UTC

ajmurmann wrote: post #33

dfischer wrote: post #13

Earlier quoted context omitted.

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async ar…

> Anything else is just stakeholder over management and or inexperienced teams. At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about…

My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined.

My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often.

But alas, everyone has a different philosophy. :)