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

71–80 of 255 posts

Re: The art of interrupting software engineers

#71

Post by jacques_chester »

dfischer wrote: post #68
jacques_chester wrote: post #54

Earlier quoted context omitted.

Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out. My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn…

To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consist…

Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.

Re: The art of interrupting software engineers

#72

Post by nfrbc »

BurningFrog wrote: post #19
ilikehurdles wrote: post #5

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.

I thought I would hate pair programming, but it turned out to be, BY FAR, the best thing that ever happened to me professionally. That said, it really isn't for everybody. But you may want to give it a chance.

IME anyone is able to pair, given the right conditions and being paired with the right person.

However, it's like therapy: being forced to do it instead of doing it by yourself will result in a terrible experience.

Re: The art of interrupting software engineers

#73

Post by nfrbc »

jacques_chester wrote: post #58
nfrbc wrote: post #57

Earlier quoted context omitted.

I've been in such a team. Pairing was optional, but the team chose to do it, so everyone on the team had to do it. It wasn't "forced" because I "always had the option to quit the job". It was hell.

I'm sorry that your experience was hell. My experience has been different. That doesn't detract from yours.

It's alright. I had great experiences with pairing when it wasn't forced on me and I had autonomy.

Re: The art of interrupting software engineers

#74

Post by 6thaccount2 »

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…

Thanks for the insight. I like programming and read and write plenty of code, but it is a part of my job (tool in the belt) and not the focus. In my opinion, there are always so many unknowns for any project that scoping something out entirely beforehand seems entirely useless. I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it. I can't do that to start without a better understanding of the problem. I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.

Re: The art of interrupting software engineers

#75

Post by elliekelly »

jbarciauskas wrote: post #15

Software engineers aren't special. Literally any job that requires a modicum of concentration, whether it's writing marketing copy or doing complex financial forecasts, means that interruptions are costly.

I once had a boss (legal - so lots of drafting/reviewing) who had a rule: no meetings & no drivebys before lunch. For anyone on the team. Calendars were expected to be clear from 9-1. He'd say "If you aren't sprinting down the hall to talk about it then it can wait until after lunch."

Of course there were "emergencies" and things so it was more like a team standard than a rule but it was phenomenal. When I got to my desk in the morning I always knew I'd have a solid block of time to get through the important work before I had to go to a bunch of meetings and take on more.

Re: The art of interrupting software engineers

#76

Post by jacques_chester »

6thaccount2 wrote: post #74
finder83 wrote: post #64

Earlier quoted context omitted.

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…

Thanks for the insight. I like programming and read and write plenty of code, but it is a part of my job (tool in the belt) and not the focus. In my opinion, there are always so many unknowns for any project that scoping something out entirely beforehand seems entirely useless. I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to c…

> I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it.

Fred Brooks said "plan to throw one away, you will anyhow". He was mostly talking about the value of prototyping or what in some circles is called spiking.

> I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.

Not in my experience, and I'm a pro-estimate loony. A lot of products and problems do have fairly predictable elements and it's possible to give useful estimates (eg, add new form element, needs a new field in the endpoint, new column on the table, some validations, tests for the above, no changes to docs ...).

Other problems are closer to pure research and you just accept someone might come back with something some day.

What we argue about in software circles is how wide valley in the middle is.

Re: The art of interrupting software engineers

#77

Post by ravenstine »

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 doing every day, then don't make me use these systems.

It's like that episode of Seinfeld where Kramer pretends to be Moviefone. "To update the status of your ticket, press 1 now. .......... Why don't you just tell me the status of your ticket?"

Re: The art of interrupting software engineers

#78

Post by dfischer »

jacques_chester wrote: post #71
dfischer wrote: post #68

Earlier quoted context omitted.

To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consist…

Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.

Perfect! Music to my ears.

Re: The art of interrupting software engineers

#79

Post by tbrock »

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.

Re: The art of interrupting software engineers

#80

Post by dfischer »

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…

Exactly this. Enable peer collaboration, enable the team to talk to each other as needed, don't force meeting time.
Post reply on HN