Live data from Hacker News

The art of interrupting software engineers

content.pivotal.io

201–210 of 255 posts

Re: The art of interrupting software engineers

#201
post #79

Earlier quoted context omitted.

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

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

This makes me so sad.

The jagged burndown chart should be the perfect tool to explain management that you didn't finish the sprint BECAUSE MANAGEMENT CHANGED OR ADDED THINGS, and so visualize the cost of such actions.

Re: The art of interrupting software engineers

#202
post #196

There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we…

> Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in.

See, to me, neither of those is a great idea. In the morning I'm coming in early before most folks so I can get a few hours of real work done without distraction. In the afternoon I'm mentally fried and ready to do anything other than office work. The best time to get me? Schedule an effing meeting so I can plan my day appropriate, and can make sure I'm apprised of any information I need so I'm not walking uselessly into an ambush. Doesn't have to be a big, formal affair in a conference room.

I think the moral of this whole discussion is that managers manage people, and people are all precious little unique snowflakes with differences. You either create your organization around a certain class of personality with everyone on board and the non-conforming out in the cold, or you create an environment that recognizes people aren't robots and work around those vagaries. Of course this is more a continuum than a binary.

Lazy managers treat everyone the same. Lazy managers also avoid setting some semblance of professional standard, leaving the mob to sort it out.

Re: The art of interrupting software engineers

#203
Interesting to read about the term "user stories" as narrative documents product managers hand off to devs so devs know what to build. (See also[0], found following links from OP.)

Is anyone able to share such "user stories"? I'd love to see how these business needs get transmitted in the real world.

Also - they're usually way longer than the one sentence referred to in these articles, right?

[0] https://www.producttalk.org/2012/04/user-stories-are-better-...

Re: The art of interrupting software engineers

#204

Interesting to read about the term "user stories" as narrative documents product managers hand off to devs so devs know what to build. (See also[0], found following links from OP.) Is anyone able to share such "user stories"? I'd love to see how these business needs get transmitted in the real world. Also - they're usually way longer than the one sentence referred to in these articles, right? [0] https://www.productt…

User stories are used (often in scrum) as a measurable deliverable and definition if done for a feature. They are usually 1 or 2 lines, such as `As a user I want to be able to log in to the system` That is the user story for the login feature

Re: The art of interrupting software engineers

#205
post #107

I honestly can't tell if this is a terrible practice or just the worst possible way to describe it for the HN crowd. People who end up in manager roles tend to be people persons and some use very touchy-feely language. I'm personally put off by all the references to his own anxiety as just one example. That doesn't necessarily mean he's actually a terrible manager. Part of his job is to make sure things get delivered…

I've also seen that programmers who're not really good at the job, but don't have qualms about playing politics often end up managing the teams they were unfit to work in in the first place. They were not necessarily better at people than others. The idea that programmers are not good with people is, in my observation, a self-perpetuating stereotype. Mostly because if you're writing code, you are on a maker's schedul…

More to the point, spending an hour thinking about how to have that conversation so it gets the desired result is literally the manager's job. Dealing with people is exactly what they are getting paid to think about and do.

It's not really about innate social skills per se. A lot of social stuff is learned behavior anyway.

Re: The art of interrupting software engineers

#206
post #79

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.

Yeah but tools almost always provide automation hooks. You can configure status to update on branch creation, PR creation, merge, deploy, etc. Always be automating.

Re: The art of interrupting software engineers

#207

Earlier quoted context omitted.

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 for…

The problem is that a client is paying by the hour, so going away for “weeks” to guess and “work” costs literally thousands of dollars. With XP, there would be a problem that would require weeks of obscurity to solve: it would be broken down into a smaller piece. And, you’d be working with your pair on it with frequent interaction with the PM.

I understand that. However I think it’s counterproductive to get daily status updates. It helps with the insecurities of management but I don’t think anything gets down quicker or better . Instead I believe the constant interruptions and second guessing slow things down.

Re: The art of interrupting software engineers

#208

Earlier quoted context omitted.

I agree with everything you wrote, but I also wonder if this is less of a distraction in the case of Pivotal since their engineers work in pairs.

Less distraction? Unless you are doing cookie cutter crap, you sometimes need to be able to walk away from your workplace for an hour or two to have good ideas; frankly, I've worked with some of the best scientists on this planet and it was common to see them leave their desk for an hour and walk around the block to clear their mind once a day or so. Moreover, I recently fell into the trap of working for an entire we…

I don’t understand how your comment relates to mine.

Re: The art of interrupting software engineers

#209
post #196

There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we…

> Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in. See, to me, neither of those is a great idea. In the morning I'm coming in early before most folks so I can get a few hours of real work done without distraction. In the afternoon I'm mentally fried and ready to do anything other than office work. The best time to get me? Sch…

The idea behind early and/or late walks is to not interrupt developer flow in peak cognitive hours. My current manager is one of few in my career who recognizes the reduction in productivity that comes from interrupting the flow.

Software engineers have largely been nocturnal, favoring later arrival times at work, in my experience. In my team's case, all the developers are late arrivals so our manager simply works with that tendency.

Re: The art of interrupting software engineers

#210

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 hell.
Post reply on HN