News for hackers. Stuff that matters.
Re:The art of interrupting software engineers by opportune on Monday July 29, 2019 @09:21PM (#20561225)
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. And they even admit their technical knowledge is not good enough to actually be able to help much if there is an issue. If you are bothering and interrupting every single person on your team multiple times a day just in case you need to increment a number in a JIRA board now instead of tomorrow morning, you are wasting people's time. Leave it to the standup.

Your job as a PM is not to micromanage engineers. If that is anybody's job, that is the engineers' managers. Your job is to make the engineers more productive and make sure they're working on the right things - but not at an hourly granularity.

Re:The art of interrupting software engineers by pjm331 on Monday July 29, 2019 @10:03PM (#20561463)
Until recently, I shared your sentiment about product managers, but recent experience has refined my point of view.

IMO a good product manager does not focus on trying to understand _why_ things are hard, but rather _what_ things are hard.

With this understanding they can either 1) work to change scope/requirements so that the bigggest user pain points are solved ASAP or 2) accept that more time than anticipated is required to solve user problems.

Implicit in all of this is the trust that when engineers say something is hard, it is actually hard.

When I see the author talking about paranoia, trust is the first thing that comes to mind.

To be fair, I don’t think that trust is easy. But I also don’t think that effective product management is possible without it

Re:The art of interrupting software engineers by FridgeSeal on Tuesday July 30, 2019 @03:30AM (#20562795)
Everything is hard if someone is interrupting me too much.

Edit: why is the trust so one way? I’m just expected to trust them, but I have to earn theirs like some kind of untrustworthy child?

Re:The art of interrupting software engineers by dilyevsky on Monday July 29, 2019 @09:40PM (#20561316)
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 by jacques_chester on Monday July 29, 2019 @09:45PM (#20561353)
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 by p1necone on Monday July 29, 2019 @10:11PM (#20561509)
>>> 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 by PhasmaFelis on Tuesday July 30, 2019 @12:23AM (#20562122)
If you interview with a company known for making widgets, you don't get to say they "forced" you to make widgets to keep your job.
Re:The art of interrupting software engineers by rxhernandez on Tuesday July 30, 2019 @01:56AM (#20562419)
It's pretty damn near forced if you're on a visa. I had brilliant friends in the Bay area that felt like they were forced to stay at their incredibly toxic jobs since the job market was rough for them and not having a job meant leaving the country.
Re:The art of interrupting software engineers by cornicecream on Tuesday July 30, 2019 @05:10PM (#20569204)
I don't believe that's the fault of the company, nor their responsibility. There are many people that feel forced to stay at toxic jobs, in the Bay Area as locals, because their lifestyle relies on having zero unemployment windows - e.g., they'll default on credit card and house payments.

Especially to those on a visa, the only one forcing you to remain in the USA / Bay Area / x company is yourself. To put it bluntly, no one is entitled to a job, and this applies to every person. In this scenario, it's not like strangers are being pulled off the streets by Pivotal to pair program.

Re:The art of interrupting software engineers by rxhernandez on Tuesday July 30, 2019 @07:27PM (#20570263)
This is a pretty poor model for how employment should work, morally. Let's put this model to a realistic extreme to see how it falls apart:

Suppose an employer asks a loved one to have sex with them or they lose their job. I mean, no one is putting a gun to your loved one's head to have sex with their employer, but something is clearly very wrong at this level right? Suppose they have an expensive debilitating medical condition that can really only be treated with good insurance (I have seen this firsthand where a medication can cost hundreds a month even with insurance (not great insurance but I was an intern, it was all I could afford)). Suppose they tried searching for a job with comparable insurance for years but always come up empty. Now when it's between whether or not you will go homeless with a debilitating medical condition or basically being raped, what would you choose? Frankly, I would rather be raped. I have been in the hospital with great insurance as well, when my condition was at its worst, and even morphine and norco did nothing to make the pain go away; I can only imagine how much worse it would have been on the streets with that kind of unending pain; I can only imagine never being able to find a job like that ever again because I will always be in unending pain and never be able to interview well. Fortunately, I got really really lucky in that I am an engineer who is an American citizen that can find jobs easily that dont require me to physically be there but, most people are not in my position. Back to the point, if someone is more willing to be raped than to not be raped out of fear of the consequences, that's pretty damned close to forced right?

Re:The art of interrupting software engineers by commandlinefan on Tuesday July 30, 2019 @08:51AM (#20564319)
There's actually a name for this fallacy: https://en.wikipedia.org/wiki/Hobson%27s_choice
Re:The art of interrupting software engineers by jacques_chester on Tuesday July 30, 2019 @04:51PM (#20569005)
I thought about this some more and I think the distinction comes down to whether I am made to pair against my will. I'm not. So to me that doesn't feel forced.

But if I worked for Company X and then one day Thou Shalt Pair Or Else, then yeah, it would feel shitty. Labs developers pair with client developers on engagements and sometimes it feels like they've been dropped from a very great height.

Most of the time it works out fine: people are people and we work in the same industry and share many of the same experiences and passions. Sometimes it just doesn't work for everyone, which is also fine.

But insofar as anyone from Pivotal is explicitly or implicitly saying "or else!", I think they are making a mistake and hope they get feedback about it.

Re:The art of interrupting software engineers by jacques_chester on Monday July 29, 2019 @10:16PM (#20561544)
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 by nfrbc on Monday July 29, 2019 @10:29PM (#20561611)
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 by jacques_chester on Monday July 29, 2019 @10:32PM (#20561627)
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 by nfrbc on Monday July 29, 2019 @10:57PM (#20561751)
It's alright. I had great experiences with pairing when it wasn't forced on me and I had autonomy.
Re:The art of interrupting software engineers by dilyevsky on Tuesday July 30, 2019 @08:50PM (#20570741)
Are we really debating meaning of “forced” now?

What I meant is since Pivotal is known for uh voluntary-enforced? subscription to XP religious practices you can’t really expect it not to bleed into all aspects of dev process.

Btw I have nothing against pairing in general, just not the way Pivotal does this.

Re:The art of interrupting software engineers by pharrington on Tuesday July 30, 2019 @02:38AM (#20562568)
To clarify - are you saying that Pivotal doesn't have any formal Standard Operating Procedures?
Re:The art of interrupting software engineers by jacques_chester on Tuesday July 30, 2019 @04:56PM (#20569061)
We have the usual HR, legal, compliance etc. But product teams exercise enormous autonomy, arguably to a fault. A few years back an R&D mechanism was introduced of pushing triaged security issues directly into team backlogs. Something close to a riot broke out.

R&D leadership otherwise pretty much don't interfere. Their main business is explaining our strategy, keeping the lights on and teams connected and adjusting allocations between different product and component teams.

Re:The art of interrupting software engineers by twic on Tuesday July 30, 2019 @05:24AM (#20563270)
Since nobody is forced to join Pivotal, we weren't forcing pairing on anyone who worked there.

We totally did force pairing on client developers, though.

Re:The art of interrupting software engineers by isoskeles on Monday July 29, 2019 @09:43PM (#20561337)
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 by rxhernandez on Monday July 29, 2019 @10:18PM (#20561553)
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 by isoskeles on Tuesday July 30, 2019 @10:27AM (#20565099)
I don’t understand how your comment relates to mine.
Re:The art of interrupting software engineers by jacques_chester on Monday July 29, 2019 @09:52PM (#20561394)
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.