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

111–120 of 255 posts

Re: The art of interrupting software engineers

#111

Post by pflenker »

jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?

Re: The art of interrupting software engineers

#112

Post by mixmastamyk »

mnm1 wrote: post #100
ravenstine wrote: post #77

You know what I don't get about status updates? We're all using tools like Jira, Trello, Pivotal Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can just go to the project board and look for yourself? If I'm going to be asked about the status of what I'm doin…

They are purely for management to feel like they useful and making a contribution when they mostly aren't. And with the stand-up/scrum mindset we get to waste everyone else's time too. I don't have a single example where another developer's stand-up update was useful to me. I don't even pay attention. I almost never know what I'm actually going to be working on at the beginning of the day so I just guess. That too is…

I worked at a place like that ten years ago. Worst dev job I ever had.

Re: The art of interrupting software engineers

#113

Post by coblers »

irrational wrote: post #106
jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

I'm relatively outgoing and it still sounds horribly draining

Re: The art of interrupting software engineers

#114

Post by pharrington »

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…

To clarify - are you saying that Pivotal doesn't have any formal Standard Operating Procedures?

Re: The art of interrupting software engineers

#115

Post by pflenker »

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…

> So surveill and/or eavesdrop and/or ambush. Nice. It's common courtesy or some kind of "office ettiquette" that if Alice wants something from Bob, but doesn't want to interrupt, she waits until there is an opportunity. Returning from a break is an obvious cue.

Re: The art of interrupting software engineers

#116

Post by navyad »

ravenstine wrote: post #77

You know what I don't get about status updates? We're all using tools like Jira, Trello, Pivotal Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can just go to the project board and look for yourself? If I'm going to be asked about the status of what I'm doin…

Great point. The tools are there to make life easy for developers. Even after using these tools, PM need to do checkins with team then I think something is very wrong in terms how PM is handling the team.

Re: The art of interrupting software engineers

#117

Post by trabant00 »

> The engineers would give me highly technical explanation I couldn’t understand.

That's the problem right there. How do you expect to manage a project you don't understand?

I don't think I will ever agree with handing the project to a non technical person instead of the team lead.

Re: The art of interrupting software engineers

#118

Post by afarrell »

irrational wrote: post #106
jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

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.

Re: The art of interrupting software engineers

#119

Post by rramadass »

pflenker wrote: post #111
jdlshore wrote: post #94

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…

As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?

The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight.

You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.

Re: The art of interrupting software engineers

#120

Post by atoav »

afarrell wrote: post #118
irrational wrote: post #106

Earlier quoted context omitted.

This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

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.

Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I’d probably leave the room and think alone till I have something worthy of discussion
Post reply on HN