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

151–160 of 255 posts

Re: The art of interrupting software engineers

#151

Post by twic »

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 material is not meant for people who aren't on an XP team. It's good advice for product managers who are.

No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting.

If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about.

It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.

Re: The art of interrupting software engineers

#152

Post by twic »

ahartmetz wrote: post #130
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…

4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself .

Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.

Re: The art of interrupting software engineers

#153

Post by edem »

This whole method is rubbish. I worked for a company who forced this method on us. The fluctuation was astronomical. Pair programming is only useful in specific cases (like getting a junior up to speed or solving super-complex problems) but in other cases it is a colossal waste of time and an extreme demotivator. Fixing bugs in pairs is the most boring thing that ever happened. Not writing down anything is a surefire way to forget what was the supposed solution for problem X or why did we put workaround Y in the code... A horrible, horrible method, I'd suggest steering clear of any company which adopts it.

Re: The art of interrupting software engineers

#154

Post by edem »

6thaccount2 wrote: post #37

Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the co…

Thanks to God it is not. I've only worked for a single company who did this and I left as quick as possible.

Re: The art of interrupting software engineers

#155

Post by pflenker »

repolfx wrote: post #143
mikekchar wrote: post #127

Earlier quoted context omitted.

I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty dar…

I don't know what I'm going to need next week let along 3 months (or whatever) from now. Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast. I'd say customers being able to stick to a coherent story about what they…

Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible.

Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.

Re: The art of interrupting software engineers

#156

Post by verinus »

trabant00 wrote: post #117

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

the opposite is dangerous too: having somebody who is so full of himself that he thinks he knows everything is rarely a good idea. Knowing your limits and being honest about thinks you know and understand is a requirement for a leader, imho.

Re: The art of interrupting software engineers

#157

Post by trabant00 »

verinus wrote: post #156
trabant00 wrote: post #117

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

the opposite is dangerous too: having somebody who is so full of himself that he thinks he knows everything is rarely a good idea. Knowing your limits and being honest about thinks you know and understand is a requirement for a leader, imho.

I'm sorry but technical knowledge and feelings are just two completely different aspects. BOTH are required, you can't just simply get stuff done by being a nice guy.

Re: The art of interrupting software engineers

#158

Post by repolfx »

trabant00 wrote: post #117

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

It's worth observing that successful tech firms like Google insist that PMs have computer science degrees and are former developers. Exactly to avoid this issue.

Re: The art of interrupting software engineers

#159

Post by kd5bjo »

tuxxy wrote: post #146
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…

I've been reading a lot on focused work and this sounds like the exact opposite of what's supposed to happen. I can't recommend Cal Newport's book "Deep Work: Rules for focused success in a distracted world" enough. He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science,…

I can second the recommendation for Deep Work, but it’s not the end of the story. Richard Hamming points out in You and Your Research that the researchers who were open to distraction tended to do a better job figuring out what to work on. In Programming as Theory Building, Peter Naur argues that the primary focus on a programming team should be developing a shared understanding of the problem space in which the program will operate.

While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.

Re: The art of interrupting software engineers

#160

Post by repolfx »

pflenker wrote: post #155
repolfx wrote: post #143

Earlier quoted context omitted.

I don't know what I'm going to need next week let along 3 months (or whatever) from now. Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast. I'd say customers being able to stick to a coherent story about what they…

Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible. Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.

But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
Post reply on HN