5 ms·

"Talking a lot" = distracting a lot. Only interrupt developers if it is urgent. For a developer, resuming a task after an interruption can take time and effort

"Talking a lot" = distracting a lot. Only interrupt developers if it is urgent. For a developer, resuming a task after an interruption can take time and effort. Using an issue trackers and building discipline around keeping it updated is preferable to polling people for updates constantly. "How is this task going?" -> go to the ticket for that task in your issue tracker and read the status field. If you feel like "talking a lot", don't do it in the areas where developers do their work. It is distracting for developers.

cimmanom 8y ago
Status fields aren’t much help when you’re 8 days in on “in progress” for a ticket that was originally estimated to take 2. Often that’s exactly when you need to have a conversation. Scope is creeping; or the engineer is taking a poor approach and needs to talk it through with someone; or there’s some tech debt that warrants investing in refactoring; or the engineer just plain misunderstood the goals. And they’re almost certainly demoralized by now and need encouragement or help seeing a way out of the swamp.
Nimitz14 8y ago
I'm a developer and completely disagree with your advice.
paulgrant999 8y ago
a status field, does not a person or a persons work effort make ;) ...and if my workers were under the gun, they understood I was there strictly to offer assistance. shit sometimes I pull up a chair and code right next to them (now fangled as "pair programming"). sometimes people need a little help. -- true story, I had a dick client-side manager, whose project was about 2 years overdue, getting raked by the consulting company I worked for (body shop). they put me on the project, I tuned that shit up. johnny on the spot, and six steps ahead of the project/clientside managers. ... about two months in, I'm 20 minutes from closing out the entire project (I took some dev shortcuts to speed shit up - I was always a "high velocity" developer), I'm undoing the hacks (finalizing) to turn in the project, when the clientside manager decides he's going to come in to "motivate" me. if you are a developer, whose ever worked with a cunt of a manager who doesn't know tech/their ass from their elbow.... you know what that means. ... literally minutes away from closing out his entire project, and I quit the project (then got fired from the company). took'em a month to close it out after I left. if the work had been less quality, it would have taken them six months. ;) Now if he'ld shut the fuck up and let me handle my business, would have taken exactly 10 more minutes. and this was after I saved his ass on the project, and saved both of their asses with a direct product demo (pieced one together in under 4 minutes with 10 minutes notice) with the client-side ceo. -- I know who can get shit done, and who is having problems. because I know, whats going on in the projects/devs. and that comes from talking to people. not looking at status fields. if you learn nothing else, go and see. codebase ain't always the codebase/trouble-ticket. its the people writing it.

cimmanom 8y ago

Status fields aren’t much help when you’re 8 days in on “in progress” for a ticket that was originally estimated to take 2. Often that’s exactly when you need to have a conversation. Scope is creeping; or the engineer is taking a poor approach and needs to talk it through with someone; or there’s some tech debt that warrants investing in refactoring; or the engineer just plain misunderstood the goals. And they’re almost certainly demoralized by now and need encouragement or help seeing a way out of the swamp.

Nimitz14 8y ago

I'm a developer and completely disagree with your advice.

paulgrant999 8y ago

a status field, does not a person or a persons work effort make ;) ...and if my workers were under the gun, they understood I was there strictly to offer assistance. shit sometimes I pull up a chair and code right next to them (now fangled as "pair programming"). sometimes people need a little help. -- true story, I had a dick client-side manager, whose project was about 2 years overdue, getting raked by the consulting company I worked for (body shop). they put me on the project, I tuned that shit up. johnny on the spot, and six steps ahead of the project/clientside managers. ... about two months in, I'm 20 minutes from closing out the entire project (I took some dev shortcuts to speed shit up - I was always a "high velocity" developer), I'm undoing the hacks (finalizing) to turn in the project, when the clientside manager decides he's going to come in to "motivate" me. if you are a developer, whose ever worked with a cunt of a manager who doesn't know tech/their ass from their elbow.... you know what that means. ... literally minutes away from closing out his entire project, and I quit the project (then got fired from the company). took'em a month to close it out after I left. if the work had been less quality, it would have taken them six months. ;) Now if he'ld shut the fuck up and let me handle my business, would have taken exactly 10 more minutes. and this was after I saved his ass on the project, and saved both of their asses with a direct product demo (pieced one together in under 4 minutes with 10 minutes notice) with the client-side ceo. -- I know who can get shit done, and who is having problems. because I know, whats going on in the projects/devs. and that comes from talking to people. not looking at status fields. if you learn nothing else, go and see. codebase ain't always the codebase/trouble-ticket. its the people writing it.