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

81–90 of 255 posts

Re: The art of interrupting software engineers

#81

Post by nfrbc »

raptorfactor wrote: post #3

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

Funny thing is, asking twice a day doesn't even make sense for the manager...

Of course, it relieves stress and stuff, but if you're THAT stressed because of the project and need constant reassurance from the engineers, you're clearly in the wrong job.

I had to lead a few engineering teams (wasn't a PM, though) and the only approach that ever worked for me was to check things out in much larger intervals, a week, sometimes even more. Actually treat engineers like adults and be an adult yourself. Let them come to you if they have a problem. Sample the progress in much larger intervals in order to reduce noise.

Micromanagement doesn't do any good for anyone.

Re: The art of interrupting software engineers

#82

Post by ryandrake »

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…

I'm a big believer in "using the tools engineering is already using" but you need to also have a culture of including status updates in bugs. Developers typically are used to putting developery stuff in bugs, not statusy stuff. Crash logs, stack traces, commentary on possible root causes, diffs, etc. you can always find in the bug history. But updates? Not so much. Even a little "UPDATE: Root cause found, fix in progress, ETA 2 days," which takes 10 seconds to write, would make your Project Manager love you and stop him/her from inadvertently interrupting you out of the zone.

Re: The art of interrupting software engineers

#83

Post by Iv »

Here is a missing advice in the art of interrupting software engineers: don't. Use asynchronous messaging, not alert-based messaging. Send emails. Make sure they read emails once a day and only interrupt if your question is really more urgent than that.

Thanks.

Daily meetings are not good. They waste people time and constitute an interruption. If you can sync the whole team so that the meeting happens on the morning before people start working, that's better, but still not good as you are imposing a schedule on a team that may know better.

I just finished a deadline at 2 am yesterday. My team is sane and did not expect me in the morning today (joined the slack around 11 am). Would not have done that if I had a daily at 9:30 am. I would not only have missed the deadline but the daily would have even further delayed it. What's more, I would have spent some time preparing it because I would feel I need excuses ready in case someone starts a blame-game.

If developers time is precious, don't waste one hour per day on dailies/daily preparation.

Re: The art of interrupting software engineers

#84

Post by mlthoughts2018 »

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

Re: The art of interrupting software engineers

#86

Post by Ididntdothis »

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…

That's how it used to be when I started in the 90s. My first projects were pretty much like "Here is the problem. Come back when you have questions" and me and others would often work for weeks without talking to management. Now it seems a lot of companies are doing more micromanagement. I also sometimes wonder if the younger programmers need more handholding these. When I started there were almost no people with formal training in software development so we were all self starters that had learned on our own because that was the only way to get into the field.

Re: The art of interrupting software engineers

#87

Post by Ididntdothis »

One trick a lot of PMs and other managers don't seem to understand is to listen and really understand what people are dealing with. If people are complaining about something then listen and see if you can improve the situation. It doesn't help to constantly ask "When is it done?" but you should ask "How can I help?". And then really help and don't just set up more meetings that don't result in anything.

Also, learn how to use JIRA or whatever tracking is being used. In my company managers doesn't bother to look at the JIRA board so you end up reporting the same thing five times to different management levels.

In short, be less controlling but try to help and treat people like professionals who know what they are doing.

Re: The art of interrupting software engineers

#88

Post by srean »

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.

Can you please clone as many copies of yourself sir. That would be task 1154162 on the dashboard.

Re: The art of interrupting software engineers

#89

Post by abc_lisper »

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.

Re: The art of interrupting software engineers

#90

Post by jdlshore »

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…

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?"

Post reply on HN