Live data from Hacker News

The art of interrupting software engineers

content.pivotal.io

241–250 of 255 posts

Re: The art of interrupting software engineers

#241

Earlier quoted context omitted.

Pivotal also has thing where everyone is expected to pair program all the time. I think I would despise the environment but it’s clearly not for everyone, myself included.

Don't forget the 9:06AM company breakfast. I'd rather have breakfast with my family and bring the kids to school.

Breakfast is gone by 9:06AM actually.. you have to be there before billing hours for the free food.

Re: The art of interrupting software engineers

#242

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

How does preferring sending/having a scheduled daily status update over random interruptions twice a day make one "vigilante"?

Re: The art of interrupting software engineers

#243
post #105

Earlier quoted context omitted.

I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.

Haha, me too, the voice in the back of my head pleaded, "Make it stop..!" Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach. However, every point in the de…

I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down.

Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :)

EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.

Re: The art of interrupting software engineers

#244

Earlier quoted context omitted.

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.

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…

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

#245

Earlier quoted context omitted.

Pivotal is well known for having a particularly extreme point of view, bordering on forthright religious fervor, when it comes to pair programming and taking highly bureaucratic versions of Agile development to an extreme. Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for peo…

How are you so sure? They are so brilliant they can make great stuff despite a terrible process they choose, but they aren't smart enough to not use the process?

Yes, this is quite common. The people who choose the process are not the same as the people who get stuff done despite it.

There’s also a survivorship / selection bias inherent to companies with extreme views like this. Either you both (a) agree to cheerlead & display positive affection for the religion and (b) display effectiveness in the role, or else you will quit or get fired or self-select to never work there in the first place.

So in a large part, it’s literally unknowable to what degree success is in spite of vs because of these extreme practices. There can’t be evidence about it because by definition there is the confounding factor that the employees whose productivity you measure are only from one specific sub-population (likes extreme view & delivers good software). You never get to measure what people with diverse opinions about tbe philosophy would do in the role, and you never get to measure what less successful developers would have done in the extreme philosophy.

The same effect happens with extreme coaching philosophy in sports, where again after you apply the filter that the players are selected to both be very good and accepting of the philosophy, there’s no way to measure the counterfactual possibilities, so it reduces to religion.

Re: The art of interrupting software engineers

#246

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…

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

#247
What I don't like about agile is its an awful approach for building large complicated products.

The focus should not be on time management, that's not why software fails, it fails due to bad design.

The "ongoing conversation" developers should have should be about modules, objects, interfaces and algorithms, not about user stories. And refactoring the system to better handle new features should be encouraged, not thought of in terms of "how does this advance a user story".

User stories should be input into the exhaustive design process, and then the design should drive the development tasks.

I'm expecting push back on this, I'd probably go as far to say that for a large team on a large project 1/3 to 1/2 of a Sprint should be spent designing, and the remainder of the time coding.

Writing tests fits in this "designing" bucket for me. TDD is a great way to flesh out how the system should be structured.

Re: The art of interrupting software engineers

#248

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.

"constant hum" is quite the understatement. It is often close to a dull roar (from personal experience with "pair all the time in an all-agile open office environment". I quit and went on to better things).

Re: The art of interrupting software engineers

#249

Earlier quoted context omitted.

To clarify, I'd be fine with pairing 8 hours a day, but I'd want: - Some sort of sound barrier so that I couldn't parse the background conversations. - To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.

Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations? Did it propel your conversation at all, or maybe give you something to talk about? When people talk about the buzz of activity in a busy place, it's really closer to a situation like this. Individuals doing solo work are often distracted by background noise, and even I do! But…

> Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations?

Yes. Its an unpleasantness I endure if I’m not trying to work through anything which is an intense use of my Working Memory.

Re: The art of interrupting software engineers

#250

Earlier quoted context omitted.

Haha, me too, the voice in the back of my head pleaded, "Make it stop..!" Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach. However, every point in the de…

I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down. Regardless of that is…

Thank you for the perspective! Pivotal does sound like an exciting place to work.

> [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down

Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP.

For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together.

> I also don't really mind interruptions

Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive.

I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.

Post reply on HN