|
I think I effectively just killed the goddamn title of SCRUMMASTER from our team. Good riddance.
|
#
¿
Mar 7, 2016 16:27
|
|
|
|
| # ¿ May 2, 2024 14:51 |
|
|
Cuntpunch posted:One of our team members already managed to completely devalue that title because he insisted the person using it was a pretender attempting to take away from his title, Scrum Lord Sounds like something from Star Wars.
|
|
#
¿
Mar 8, 2016 06:23
|
|
|
Pollyanna posted:We had a discussion yesterday afternoon on what to do about one of the engineers on our team. Specifically, that he's totally useless and slowing us down. He's the type of person that can't really do anything without being babied through it, even though he's supposedly a specialist in the type of work he's doing (CSS, Javascript, etc.) He tends to introduce more bugs than he fixes, has been taking my coworker aside all day whenever he's working on something, and isn't very rigorous about making sure his poo poo works. I don't want to promote a silo culture of "please stop talking to me", and it's perfectly fine to ask questions - it's just that he doesn't have enough experience to figure things out on his own, especially not any basic poo poo like git or Rails. The rest of the team wants him out, and I feel a little bad saying that I'm neutral on him staying or not - he doesn't really bother me even if he sucks at his job. This isn't the first time he's had trouble on a project either, he's been taken off a previous one for the subject being way out of his league/competence. You're not a manager yet, right Pollyanna? Was this discussion had with engineers from all levels?
|
|
#
¿
Jul 22, 2016 19:07
|
|
|
Pollyanna posted:No way I'm not a manager. This was between our entire product team (2 mid-level engineers, 1 senior) with our direct manager. Ouch. Not a fan of that at all. Performance related discussions should be handled on a 1:1 basis and not in a group environment like that. That doesn't mean issues with said co-worker shouldn't be raised, but should be done in private with one's manager (or one level up if the manager is the problem). It would then be up to the manager to go talk to people individually to get more information and hear out opinions in order to determine next steps.
|
|
#
¿
Jul 22, 2016 21:46
|
|
|
Hughlander posted:Manager should have said this isn't an appropriate platform for this issue and killed it at that point. This. Really poor decision making on their part.
|
|
#
¿
Jul 23, 2016 04:00
|
|
|
csammis posted:True story, when a previous company started trying to do MVP their consultant recommended this exact tactic to use on product managers asking for new features. They called it "five 'whys'" and the theory went that if you couldn't get to a concrete use case for a feature by the time you've asked "Why A? Because B. Why B?" five times then that feature isn't really necessary. It was fun the first couple of times and then the yelling / ignoring started...so yeah pretty much like a 5 year old Oh god, using the 5 whys for product prioritization sounds atrocious. It's great for retrospectives but not that.
|
|
#
¿
Apr 26, 2017 16:47
|
|
|
Pollyanna posted:Aren't team leads expected to be, like, available if we have questions? Yes.
|
|
#
¿
Aug 10, 2017 19:46
|
|
|
Pollyanna posted:This only goes so far when the other person decided to hang out in Maine for the week and their internet is nearly non-existent. That means the person is out of the office and not available to work. Relying on folks when they're not working is just setting yourself up for failure. Also, I'm also a tech lead (although it seems the new term is slowly becoming an engineering manager? who knows). There's definitely a careful balance of asking questions versus self education: 1. Identify the problem and rubber duck the question. 2. Google it if isn't domain specific (as opposed to general knowledge) 3. Look around for other examples of what you're trying to do already in the existing code base (timebox it to ~5 minutes) 4. Then ask for help in whatever instant communication platform you use but don't demand an answer initially. Adequately write out what you're trying to do, the problem you're experiencing, and the steps you've already taken to get to this point where the next best thing is for someone else to help you out. 5. All the while while waiting for a response (people are busy, in meetings, lunch etc) keep working on it. There's nothing more frustrating than someone waiting around, expecting help. Of course there's pairing, but unless your team is properly set up and structured to allow for a fair amount of pair programming, it's hard to rely on it for folks to get their help. I tend to suggest pairing for when dealing with more intricate or tougher problems that you know more than one set of eyes on at the start will really help in the long run. Now, when newer, especially junior, engineers join the team, pairing should be part of their onboarding program. Because everyone has one of those clearly laid out, right??? Self sufficiency is so so valuable to an engineer's career.
|
|
#
¿
Aug 12, 2017 16:41
|
|
|
Pollyanna posted:No, they're in, and said they'd be available - just that they didn't respond until hours later. Well then that's unacceptable and not behavior that should be tolerated. Sounds like they want to get away with not being out while also taking a vacation.
|
|
#
¿
Aug 12, 2017 18:28
|
|
|
Please use a tool (like Github, BitBucket etc) that allows for Pull Requests and the ability to comment on them. If I had someone just going around changing code I was trying to get merged in I'd be pissed.
|
|
#
¿
Aug 18, 2017 19:39
|
|
|
Vulture Culture posted:Are you asking about code review tools? GitHub/GitLab/BitBucket pull requests, Gerrit, and Crucible are all popular, but there's a bunch of other niche tools too if you go hunting for them. Yeah, these are pretty standard nowadays. I understand not everyone can use the GitHub service, but they do have https://enterprise.github.com/home
|
|
#
¿
Aug 31, 2017 23:52
|
|
|
|
| # ¿ May 2, 2024 14:51 |
|
|
Plorkyeran posted:The wordpress post itself was a response to FB announcing they were going to stick with the current license, so either they coincidentally pulled a 180 two weeks later or they didn't want to lose WP. Losing support from the platform that drives an incredible percentage of websites out there seems like a bad thing.
|
|
#
¿
Sep 23, 2017 13:49
|
|