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

161–170 of 255 posts

Re: The art of interrupting software engineers

#161

Post by mikekchar »

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…

There is a difference between not knowing what I need for an API next week and not knowing (vaguely) what I need for the business. My backlog stretches out about 4 months at the moment, but I don't do technical design until much, much later. But as a sibling post rightly points out, not all of the stories on my backlog are going to get done. 4 months is a long time and the business is hopefully gathering more and more data about what it needs. Frequently opportunities arise that overtake what I have in my backlog. Since I always have more in my backlog than I can actually do, that means that the stuff on the bottom drops off. If I were to estimate, I would say that about 1/3 of my 4 month backlog is practically 100%. It drops off to 0% by the end.

Re: The art of interrupting software engineers

#162

Post by mikekchar »

jasim wrote: post #131
mikekchar wrote: post #122

Earlier quoted context omitted.

I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- t…

This conversation is probably moot in teams where programmers are actually empowered to make their own decisions. In that case XP is fine, if you enjoy it, which makes it sort of a tautology. The problem though is the Agile Industrial Complex and "thought leaders" who have pushed this as a religion on the industry. I enjoy pairing, and the excitement of two minds working at the same problem in tandem is an experience…

Well, I won't disagree. I've had the moniker "Agile Coach" before it was ever a thing (I though I'd invented the term :-) ). But I have never been a business consultant. My "coaching" was exactly what you would expect from a sports coach: I helped the players, not the management :-).

XP (in its traditional sense) doesn't scale past 8 developers anyway. Anybody selling you XP for a team of 500 is someone to be wary of ;-)

Re: The art of interrupting software engineers

#163

Post by _57jb »

mikekchar wrote: post #122
jasim wrote: post #108

Earlier quoted context omitted.

Taylorism worked -- it decreased costs for companies, but people suffered -- they couldn't find meaning in what they do, their every move was monitored and choreographed, and they were squeezed for the last bit of efficiency possible. The kind of "pairing all the time" kind of XP that is being preached is similar for programmers. It also works for repetitive work - building yet another web application - at scale, not…

I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- t…

This right here. It changed my outlook on software completely.

There are pains and giving folks the opportunity for change/rotation is refreshing.

Software is a team sport, its a weak-link game where we must communicate and empathize in order to see clearly (often past our own egos) in order to pull one-another up.

I was fortunate that good pairing hygiene was a focal point. Without that it can be disastrous mentally and ruin the experience for everyone. It turned into a highly collaborative sport at that point.

I am a hugger naturally but when I run into those pairs I went through the trenches with, it is a brother/sister hug. Best time of my life.

Re: The art of interrupting software engineers

#164

Post by eowiror »

"I was a bit paranoid and would sometimes err on the side of conspiracy theories"

This smacks of high stress environment with a bunch of people who don't really know what they're doing, maybe all the way to the top.

Good developers don't work in these places. And if they do get caught here they don't stay long.

Re: The art of interrupting software engineers

#165

Post by targonca »

abc_lisper wrote: post #89
tschwimmer wrote: post #38

I'm a PM and this does not resonate with me. If you're getting status twice a day... I think something is very wrong. The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.

I think you jumped the shark here. The point of doing multiple checkins a day is to make good engineers feel like they are barely good enough, and make them hungry to please the bosses! Pavlov at work here, I think.

I'm not sure you're using "jumped the shark" correctly.

Re: The art of interrupting software engineers

#166

Post by bluedino »

mlthoughts2018 wrote: post #84
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…

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…

More extreme than Menlo?

Re: The art of interrupting software engineers

#167

Post by sebbyy »

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 an introvert and I like XP.

Left the company for a usual startup setup with your own Macbook, pull requests, and things.

I miss the almost zero friction collaboration.

As a pair. Either of us will point out each other mistakes and suggest an improvements to what we're doing in real time without the ping-pong of pull request.

If both of us can't figure things out. We can just scooch over to other pair workstation, sit in the other chair, use the mouse and keyboard to show part of code we have issue with, point to the monitor, and ask questions.

Re: The art of interrupting software engineers

#168

Post by afarrell »

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.

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.

Re: The art of interrupting software engineers

#169

Post by afarrell »

_betty_ wrote: post #139
ahartmetz wrote: post #130

Earlier quoted context omitted.

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 .

I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature. This practice is just saving time writing down behaviour that won't be implemented.

But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction?

What do you do when people forget things?

Post reply on HN