7 ms·

> 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 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 a Product Lead at Pivotal. Here's me thinking it's probably a more junior PM doing this. Nope, it's a Product Lead. PMs/TPMs can be great, if they are good. I've worked with some that made my life easier. I've worked with others who really didn't. Based on this article alone, Pivotal's PMs would make me quit.

mlthoughts2018 7y ago
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 people working pretty much anywhere else.
- jdlshore 7y ago
  As far as I know, Pivotal's process is based on Extreme Programming (XP), a process which deliberately takes an extreme point of view. (It's in the name.) It's not bureaucratic, but it is demanding. I have a lot of experience with XP. In my experience, XP succeeds because of its extremeness, not despite it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well. So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"
  - jasim 7y ago
    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 at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.
    - mikekchar 7y ago
      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 -- three days after you could have done something about it ;-). In the pure XP teams I was on, I had a lot less conflict overall -- mainly because you are kind of forced to deal with conflict up front. However, we had a few guys on our team that really didn't like it. They left and I don't think less of them in any way. It's a different way to do things. As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).
      - jasim 7y ago
        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 to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.
- bluedino 7y ago
  More extreme than Menlo?
- lonelappde 7y ago
  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?
  - mlthoughts2018 7y ago
    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.
pflenker 7y ago
> 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.
- disappearance 7y ago
  I'll often go for a walk when facing a troublesome problem and return with an arbitrarily Complex model in my head. It would be an inconvenient time for an interruption, and probably looks quite a lot like returning from a break.
  - pflenker 7y ago
    I just wanted to make the point that waiting for someone to return from a break before talking to them can be considered polite, instead of an impolite ambush as indicated in the previous comment. Of course, there is no one-size-fits-it-all solution.
    - mugsie 7y ago
      There is - schedule a meeting (even if it is a 15 min "sync") the day before, so I know I have a context switch coming up.
      - pflenker 7y ago
        In my experience, that is not an acceptable solution for everyone. I have worked with people who despise these kinds of scheduled short meeting, because "we are sitting in the same office and can always talk to each other". That having said, my personal preference is also the scheduled 15 minute meeting.
commandlinefan 7y ago
> So surveill and/or eavesdrop and/or ambush. Nice. Maybe that's the idea - "He always ambushes us when we come back from a break... we'd better stop taking breaks!"
JJMcJ 7y ago
> a casual non-work related conversation Programmer 1: Whoa, that two hour Pomodoro was quite something. Programmer 2: We got a ton done, though. Programmer 1: Yeah! I hope they have the lasagna again at lunch. Project Manager: Hi, are you getting your work done? If you could get back to work, that'd be great.

mlthoughts2018 7y ago

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 people working pretty much anywhere else.

jdlshore 7y ago
As far as I know, Pivotal's process is based on Extreme Programming (XP), a process which deliberately takes an extreme point of view. (It's in the name.) It's not bureaucratic, but it is demanding. I have a lot of experience with XP. In my experience, XP succeeds because of its extremeness, not despite it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well. So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"
- jasim 7y ago
  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 at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.
  - mikekchar 7y ago
    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 -- three days after you could have done something about it ;-). In the pure XP teams I was on, I had a lot less conflict overall -- mainly because you are kind of forced to deal with conflict up front. However, we had a few guys on our team that really didn't like it. They left and I don't think less of them in any way. It's a different way to do things. As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).
    - jasim 7y ago
      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 to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.
bluedino 7y ago
More extreme than Menlo?
lonelappde 7y ago
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?
- mlthoughts2018 7y ago
  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.

pflenker 7y ago

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

disappearance 7y ago
I'll often go for a walk when facing a troublesome problem and return with an arbitrarily Complex model in my head. It would be an inconvenient time for an interruption, and probably looks quite a lot like returning from a break.
- pflenker 7y ago
  I just wanted to make the point that waiting for someone to return from a break before talking to them can be considered polite, instead of an impolite ambush as indicated in the previous comment. Of course, there is no one-size-fits-it-all solution.
  - mugsie 7y ago
    There is - schedule a meeting (even if it is a 15 min "sync") the day before, so I know I have a context switch coming up.
    - pflenker 7y ago
      In my experience, that is not an acceptable solution for everyone. I have worked with people who despise these kinds of scheduled short meeting, because "we are sitting in the same office and can always talk to each other". That having said, my personal preference is also the scheduled 15 minute meeting.

commandlinefan 7y ago

> So surveill and/or eavesdrop and/or ambush. Nice. Maybe that's the idea - "He always ambushes us when we come back from a break... we'd better stop taking breaks!"

JJMcJ 7y ago

> a casual non-work related conversation Programmer 1: Whoa, that two hour Pomodoro was quite something. Programmer 2: We got a ton done, though. Programmer 1: Yeah! I hope they have the lasagna again at lunch. Project Manager: Hi, are you getting your work done? If you could get back to work, that'd be great.