Team meetings where you go around in a circle and tell everyone what you're working on are useless. Change my mind

Depends.

I like it, think it is a good practice.

But the the meeting needs to be small, to the point, etc.

I think it is good to know what folks who work close to what you work on are up to. It can spark some interesting discussions ... that should take place after the meeting / another meeting.

"Hey you and I should talk about X... in another meeting between us." And then roll on to the next item kinda thing.

Sadly humans suck at focus and meetings generally. Some orgs just can't do it right and thus shouldn't do it.

Probably won't change your mind, but I prefer to know what each of 'people who could potentially fuck up my product' are currently working on.

It has happened that person A did the db changes and didn't think of notifying me, then I got a complaint from person B that thing x is broken..

So yeah, I couldn't care less what person D is doing if it's not affecting my product, but otherwise you better tell me what you are doing & how, so I can detect clashes before the problems happen.

@sladuled yea that makes sense. We just have one person per project implementation, so I'm the only one that could mess up thing x.

@sladuled yours is probably the best answer in my opinion. Communication is key when it comes to things like this.

@stub Thanks 😇
Most people are careless.. they need to change thing x & don't think of the consequences.. they just do it..

When I took over this project, it didn't occurr to me to just change some db structure without finding out who & what is accessing the data & if my changes will break things outside of the project...some people just don't think/care that much..

After a couple of mishaps & a lot of yelling/cursing from my side, boss said I'm free to yell at anyone who breaks things again because they didn't check with me first 🤣🤣🤣😇
They were of course first politely notified to discuss changes before actually making them.. Still got to yell once more, but now it seems they got the point..

@sladuled lol. Well it's good your boss was in your side. And it isn't as much of an ongoing issue. I've found in general most people are off in there own worlds. Some dont care most just don't think.

@shoogknight Mostly, we do too, one person, several projects.. But also several projects that operate on same db, so in some cases we all need to make adjustment or two to handle changes properly..and some people don't think about something minor that can fuck up others majorly, so this kind of thing is welcome from my side, so I can at least prepare & check how it impacts my part..

@stub Hahaha yes, always on my side..well almost always..

This project was a bust, went through so many devs who only bitched about how things are done, but none offered solutions..they didn't care..or think how to implement something.. Often they only did what was requested of them, but ended up fucking things up in the long run because they didn't know better.
I only did this mistake once.. quick fix was needed, done half assed from my side too because I lacked general dev expirience & in depth knowledge of how our projects interact.. and I didn't want to say no.. never fucking again.. Later I demanded time to rewrite this so we can do further development without much problems.. took me a bit longer than expected, but now if we need to add/change things it can be done within hours, not days & with fucked up backwards compatibility..
Anyhow, this was the first & last time boss wasn't on my side.. but later he admitted I was right to rewrite this shit and now if I state something is a bad idea he actually listens & usually agrees that we need to reconsider implementation details..
So messing up db structure & data without discussing it first with all parties..well he better be on my side xD

@sladuled I guess I was more talking about meeting where everyone is on a different project, we just meet because the manager probably feels like we have to. It be more productive if he asked does anyone have obstacles or brain storm ideas on anyrhubg.

But for your issue, I would think whoever made that change would create and send a work item among all the teams that needed to change code. That way all the changes can be tracked.

Sometimes it’s just nice to get a rough overview of the general work being done on the product.

And avoiding people having no idea what their colleagues are up to.

imho, especially for remote teams, it helps woth the feeling of momentum and awareness that i'm not the only lonely person doing something.

also useful for the boss to get a quick overview of what's going on and give others updates on communications with clients.

but i think i got into unusually good team, the standups actually are short and to the point, so far the LONGEST ONE was 20 minutes.

I used to work in a team of around 20 people between QA, BIs and Devs, and those reunions included the clients. They lasted around an hour and nothing useful came out of them since the client never truly cared for the solution we were trying to implement, they just wanted a cheaper version of an already existing solution, so the meetings were always us trying to explain why our solution would do what they wanted and more.

Fortunately I switched jobs three months after entering because it was about four hours of useless meetings per day and other four hours of developing things that no one really wanted. Now those meetings last around 15 minutes and always serve as an opportunity to ask for advice or to avoid future headaches

Every employee working on their own project is bad to begin with. What if you get sick? What if you leave? What if you have a deadline soon and would need more hands to work on another part of the project? No one else is familiar with your project. How do you even get code reviews?

Maybe the meetings exist to let each team member know what kinds of projects the team is even working on.