The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#51

Post by rxhernandez » Tue, Jul 30, 2019, 2:18 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.

Less distraction? Unless you are doing cookie cutter crap, you sometimes need to be able to walk away from your workplace for an hour or two to have good ideas; frankly, I've worked with some of the best scientists on this planet and it was common to see them leave their desk for an hour and walk around the block to clear their mind once a day or so.

Moreover, I recently fell into the trap of working for an entire week nonstop to solve a really hard problem. Took a few hours off one day to clear my mind and when I came back, I had the problem solved inside of an hour. If I continued down the route I was going down before that time off I can guarantee you it would be more days wasted.

Re: The art of interrupting software engineers

#52

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

godelski wrote: post #41

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.

If it's not already blazing on a dozen slack channels I'd be surprised, we are a tech company after all.

As I noted in another comment, I would give feedback to a PM that this kind of checkin isn't necessary and try to understand how to help foster trust.

At Pivotal I have worked with 9 or 10 product managers, none of whom have asked during the day how things were going.

If anything I would be the one interrupting them.

Re: The art of interrupting software engineers

#53

Post by opportune » Tue, Jul 30, 2019, 2:20 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 have had good and bad PMs. The bad PMs can take many forms, but one form is the "control freak who wants to be your manager". There is a happy medium between complete lack of information and thrice-daily status checks

Re: The art of interrupting software engineers

#54

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

dfischer wrote: post #50

ajmurmann wrote: post #33

Earlier quoted context omitted.

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

Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out.

My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.

Re: The art of interrupting software engineers

#55

Post by yowlingcat » Tue, Jul 30, 2019, 2:27 AM UTC

Wow, where do we start here? First of all, it is much more effective to team with a tech lead or engineering manager to remain semi-realtime up to date with the status of where things are in engineering rather than asking status update questions directly. To not understand that is a level of naivete that prevents a product manager from operating at the basic level of competence to be considered a senior IC.

Second of all, I've seen two kinds of product managers. One kind looks at software development estimates as commitments to be contractually adhered to. The other treats software development estimates as assets/investments with risks to be managed.

Which kind is more effective? Well, which computation accomplishes more results, the one that doesn't halt and logs the same line over and over, or the one that does halt and additionally does the thing it set out to do?

Re: The art of interrupting software engineers

#56

Post by DoreenMichele » Tue, Jul 30, 2019, 2:29 AM UTC

I honestly can't tell if this is a terrible practice or just the worst possible way to describe it for the HN crowd.

People who end up in manager roles tend to be people persons and some use very touchy-feely language. I'm personally put off by all the references to his own anxiety as just one example. That doesn't necessarily mean he's actually a terrible manager.

Part of his job is to make sure things get delivered in a timely fashion. If that's not happening, then feeling stressed by it isn't unreasonable, but the article sounds like he's just trying to manage his emotions rather than get deliverables from his people in a timely fashion.

I'm not posting this to dog the author. I'm posting this to suggest that his framing may reflect the fact that his job involves managing people rather than things.

If it were framed differently, the exact same practices might sound much more reasonable and palatable to people here on HN who are overall reacting fairly negatively to this.

Re: The art of interrupting software engineers

#57

Post by nfrbc » Tue, Jul 30, 2019, 2:29 AM UTC

jacques_chester wrote: post #49

p1necone wrote: post #44

Earlier quoted context omitted.

>>> 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.

I've been in such a team.

Pairing was optional, but the team chose to do it, so everyone on the team had to do it.

It wasn't "forced" because I "always had the option to quit the job".

It was hell.

Re: The art of interrupting software engineers

#58

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

nfrbc wrote: post #57

jacques_chester wrote: post #49

Earlier quoted context omitted.

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.

I've been in such a team. Pairing was optional, but the team chose to do it, so everyone on the team had to do it. It wasn't "forced" because I "always had the option to quit the job". It was hell.

I'm sorry that your experience was hell. My experience has been different. That doesn't detract from yours.

Re: The art of interrupting software engineers

#59

Post by philliphaydon » Tue, Jul 30, 2019, 2:35 AM UTC

jacques_chester wrote: post #22

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…

I think that artificial deadlines and stress exist because the team and management allow it to exist. A story should fit into a sprint, but it may spill into the following sprint, but you shouldn't sacrifice quality just because you tried to finish it within the sprint. And a team should stand up for themselves in this regard, as a team, because a team succeeds and fails together. If you sacrifice quality because of some artificial deadline you put in place then you're only going to suffer maintaining that later on.

Re: The art of interrupting software engineers

#60

Post by opportune » Tue, Jul 30, 2019, 2:35 AM UTC

dfischer wrote: post #47

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

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…

For me, what is in a Kanban board is not enough info to be able to determine when I can help unblock other people on my team. I think this probably depends on how you use project-management software and what your team works on; for me, a teammate's item might list "Create pipeline to process dataset Y on hourly basis". If they are running into issues, I don't know if it's something I've seen before with that dataset, or that pipeline tech, or the processing script, or end-to-end latency, or XYZ. A standup helps clarify things somewhat

Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.