The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#131

Post by jasim » Tue, Jul 30, 2019, 8:16 AM UTC

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

Re: The art of interrupting software engineers

#132

Post by pflenker » Tue, Jul 30, 2019, 8:16 AM UTC

mikekchar wrote: post #127

pflenker wrote: post #111

Earlier quoted context omitted.

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

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 am a huge fan of attaching a "business value" to everything the team does. I also see the value (for everyone involved) to frequently collaborate and think about these things. But where the article proposes to ask all the developers for updates three times a day, I prefer the approach where the developers "pull in" their product managers when they need them, instead of the product managers "pushing" their views onto them multiple times a day.

This is why I was asking - I still don't fully understand if this is a "XP thing" or not.

Re: The art of interrupting software engineers

#133

Post by skgoa » Tue, Jul 30, 2019, 8:16 AM UTC

finder83 wrote: post #64

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…

It depends a lot on the company. I've been fortunate enough to avoid companies like the one posted, but there really are two (maybe three) views of developers: 1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow. 2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape. I'd argue mayb…

In my experience "the old waterfall companies" are the ones where the engineers are trusted with a task and left to do their thing. In such an environment, managers are only there to assist the engineers. I.e. escalate issues, provide ressources etc. and most importantly: fight for their team/department in meetings. We go to our team lead only when it is necessary and he only asks for updates when he needs to report our status to a superior.

What I have witnessed in those hip, agile young companies is that you have to report exactly what yyou have done, what you are plannign to do etc. constantly. At least once a day, plus whatever other weekly meetings you are in. Sometimes your entire day is filled with meetings and you are supposed to fit your actual work somewhere in the breaks. And if you can't finish a task in a day, you trigger extra attention from managers and suddenly you find yourself sitting at your desk with another engineer and a manager looking over your shoulder, wasting hours of expensive time instead of letting you work.

Those are the two extremes I have encountered and they are only annecdotes. But they do serve to show that the development process chosen for a project is not tell you anything about the management style.

Re: The art of interrupting software engineers

#134

Post by zimbatm » Tue, Jul 30, 2019, 8:18 AM UTC

I see a lot of anxiety in the article. This sentiment is going to permeate through the team!

As a developer, all I need from management is clear priorities. Let me know what the business needs, and keep reminding me what those are in case I get lost into code. Create chunks of time where the priorities don't change so I can focus. The bigger the chunks the better.

Then let me do my job please! I need to be able to trust that management is picking the right priorities, and management needs to trust that I am able to convert those into code. Trust is paramount.

If you can do that, I will be 10x more productive than any of these pseudo management techniques. It doesn't matter if we do scrumm, agile, daily standup, use Trello or some other tool. These are just implementation details. Let the developers pick whatever they are comfortable with.

Re: The art of interrupting software engineers

#135

Post by systemtest » Tue, Jul 30, 2019, 8:21 AM UTC

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…

When I read "pairing stations" I gagged.

Re: The art of interrupting software engineers

#136

Post by systemtest » Tue, Jul 30, 2019, 8:27 AM UTC

tbrock wrote: post #79

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…

Your team needs excellent JIRA hygiene for that to actually work. I’ve been on and managed teams where it’s expected and demanded and others where it was an afterthought.

Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.

For actually tracking the progression of the sprint we have a secret Slack channel that management can't see.

This way we don't have to explain to a spreadsheet monkey why the burndown chart looks like a skyline.

Re: The art of interrupting software engineers

#137

Post by _betty_ » Tue, Jul 30, 2019, 8:29 AM UTC

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.

Menlo innovations do pair everything and find most their employees are introverted and like it.

The theory is that introverts don't dislike social interaction but unsafe social interaction. It's why you're generally more social with friends and family.

Re: The art of interrupting software engineers

#138

Post by systemtest » Tue, Jul 30, 2019, 8:30 AM UTC

ilikehurdles wrote: post #5

raptorfactor wrote: post #3

If I had a PM come by my office twice a day to "check-in" I think I'd quit.

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.

Re: The art of interrupting software engineers

#139

Post by _betty_ » Tue, Jul 30, 2019, 8:32 AM UTC

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 .

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.

Re: The art of interrupting software engineers

#140

Post by lazerwalker » Tue, Jul 30, 2019, 8:36 AM UTC

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 .

An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large.

Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.