The art of interrupting software engineers • Hacker News Board

Re: The art of interrupting software engineers

#91

Post by PhasmaFelis » Tue, Jul 30, 2019, 4:23 AM UTC

p1necone wrote: post #44

jacques_chester wrote: post #25

Earlier quoted context omitted.

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…

>>> 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... sounds like forced to me?

If you interview with a company known for making widgets, you don't get to say they "forced" you to make widgets to keep your job.

Re: The art of interrupting software engineers

#92

Post by rramadass » Tue, Jul 30, 2019, 4:26 AM UTC

dfischer wrote: post #13

40acres wrote: post #10

I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorr…

A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async ar…

>Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.

Finally! A sane voice appears!

Re: The art of interrupting software engineers

#93

Post by pflenker » Tue, Jul 30, 2019, 4:31 AM UTC

philliphaydon wrote: post #59

jacques_chester wrote: post #22

Earlier quoted context omitted.

Pivotal doesn't use sprints. Stories are pointed by engineers and ordered by the PM, but they're done when they are done , to the satisfaction of both. Tracker is able to give short-term forecasts of what will be done by when by averaging the last 3 weeks of deliveries (ie, velocity). Personally I think the idea of sprints is a menace. It creates an artificial deadline that leads to either waste or stress. Deadlines…

I think that artificial deadlines and stress exist because the team and management allow it to exist. A story should fit into a sprint, but it may spill into the following sprint, but you shouldn't sacrifice quality just because you tried to finish it within the sprint. And a team should stand up for themselves in this regard, as a team, because a team succeeds and fails together. If you sacrifice quality because of…

I think two core ideas of sprints are to 1) combat Parkinson's Law by creating an artificial deadline (the team should try to solve things within the sprint) and 2) protecting the team from changes (avoiding that requirements change all the time)

With that in mind, sprints can work pretty well, and work "spilling over" to another sprint is generally no problem. It starts falling apart if the artificial deadline becomes a forced deadline, or if the protection part is dropped.

Re: The art of interrupting software engineers

#94

Post by jdlshore » Tue, Jul 30, 2019, 4:40 AM UTC

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 atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.

4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.

5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.

Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.

This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.

Re: The art of interrupting software engineers

#95

Post by [deleted] » Tue, Jul 30, 2019, 4:44 AM UTC

40acres wrote: post #29

whycombagator wrote: post #24

Earlier quoted context omitted.

> daily sync (a.k.a stand up meeting) *status report > My team meets for 30 minutes each morning That is far too long IMO and IME > We're a small team (3 developers) 30 mins for 3 devs...

It's not just a status report, it's a casual discussion about the work. We collaborate on strategy, talk about any issues, and coordinate with each other. We front load information sharing so that it's rare to have to share information (ie. interrupt) at other times in the day.

[deleted]

Re: The art of interrupting software engineers

#96

Post by mnm1 » Tue, Jul 30, 2019, 4:52 AM UTC

This should be called the art of micromanagement. It's complete bullshit. I've worked under such conditions for a few months and I came very close to quitting. I didn't quit because it eventually stopped but I was considering some offers. This is one way to get your top engineers to quit. Why even hire product managers if this is what they think the job is? Save money. All they will do is slow down your team. Measuring time estimates in hours is also ridiculous especially when one has multiple things to work on. If this guy was a product manager in my company he'd be looking for a job in the morning.

Re: The art of interrupting software engineers

#97

Post by [deleted] » Tue, Jul 30, 2019, 4:54 AM UTC

[deleted]

Re: The art of interrupting software engineers

#98

Post by pmarreck » Tue, Jul 30, 2019, 5:03 AM UTC

I have started to have a simple rule for being a productive developer regardless of client or boss pressure:

Get 1 tangible thing done a day. Ideally it has a visible effect (but don't make this religion- I had to rip out a cache infrastructure last week and replace it with a home-grown one and there was no visible effect other than things not breaking!)

Now, some days, this means you either don't work the full 8 or you go over 8 because the particular piece you're building just won't get built sooner (or you didn't break it up enough). But on average, just having this goal seems to be working.

If interruption would be costly, I take it to a quiet place for a few hours such as a library.

Re: The art of interrupting software engineers

#99

Post by tawy12345 » Tue, Jul 30, 2019, 5:04 AM UTC

It sounds like a low trust environment.

If you actually need to know whether something is falling behind schedule every few hours (which seems unusual), of course not everybody is going to provide updates that frequently of their own volition. But most good engineers, under the right circumstances, will have a sense for when something is not on track and can raise their concerns.

If you actually had a good level of trust on the team, you would work to get people to buy into it. Of course, it's probably hard to convince most engineers that you actually need an update twice a day, for good reason.

Re: The art of interrupting software engineers

#100

Post by mnm1 » Tue, Jul 30, 2019, 5:04 AM UTC

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…

They are purely for management to feel like they useful and making a contribution when they mostly aren't. And with the stand-up/scrum mindset we get to waste everyone else's time too. I don't have a single example where another developer's stand-up update was useful to me. I don't even pay attention. I almost never know what I'm actually going to be working on at the beginning of the day so I just guess. That too is management's fault as they shift priorities constantly. The whole status update meeting is a waste of time. And it's not five minutes anymore it's thirty to forty five destroying peak concentration time in the morning. Because they are so early, I usually finish early and lose the peak concentration time in the evening instead of sleeping late and focusing on work at peak times. Then managers wonder why things take so long when they destroy every morning and every evening of work. When you treat and mistreat people like robots, you get shitty work. Yet management is oblivious and trying to change or even communicate this to them falls on deaf ears. Well they reap what they sow and it's a shit crop.