it finally happened, PM/PO/SM is now also dev シ

each standup he now also gives update about his work in progress, with his diligently designed subtasks, perfectly sticking to the daily script, like a good well-behaved employee boi. it's weirdly cute

devs can't await to review his first PR. feeling the strong urge to spank his ass for each minor coding style issue or poorly-named variable...

Wait - did they really pull in the clown also into development instead of doing it the other way around?!

Employee Boi, worst superhero ever

@Fast-Nop i think it's just a temporary measure to increase manpower so we can deliver our first poc faster. but my initial thought was that maybe this was a strategic decision so he can be a "role model" for other devs in the team and scrum team cohesion (between him and rest of the team) is improved in a way. but probably he didn't spend so many thoughts on this 😅

@soull00t Given his track record of being a "role model" sheds some doubt on that decision. Or maybe it's "how not to lead, given by bad example". ^^

@soull00t let's hope with him involved in the development poc doesn't stand for piece of crap

Oh wow, something is wrong at your company.

"each standup he now also gives update about his work in progress"

Okay, implying multiple days at least.

"devs can't await to review his first PR"

Still no pull request? Please tell me he is just very, very slow. Because you shouldn't normally have weeks long tasks. It might happens once in a blue moon, but not normally. And this shouldn't be given to a new dev if it happens. Even if the dev is an annoying PM.

Not that bad an idea to have everyone at least get a shallow taste of each others' work. It helps when management has some feeling about what everyone does and when devs know how other departments actually work.

Sometimes there actually is too much disconnect between departments.

Oh, please keep us updated when the pr finally comes trough! This is hilarious

Have some fun and assign to him/her some truly complex regex.

@TheCommoner282 after what period of time do you usually create a pull request? i mean if it's still a work in progress for a story that takes a whole sprint and there's nothing to show / discuss yet, there's no need for a PR, or is it?

@rarboot yeah agree, these subtasks are fucking retarded

@soull00t

Definitely not in weeks. It depends on the task. Low ball average number is one pull request every two days. High average is about 3 per day.

It's not like I never built something bigger. I mean, for instance back when I built a micro service for a client, I had one task in one sprint and it was the micro service and it took me two weeks, but I worked completely alone on it. If I worked together with others I had to split it up in smaller tasks.

What kind of tasks are you working on? I was a web developer and those tasks could be divided up quite easily.

@TheCommoner282 hmm... well, at the moment i don't work on tasks that would require several PRs a day or after 2 days... they are not small enough.

our team is currently working on a module for an embedded system prototype and my tasks also have this prototyping nature, stories involve whole libraries or data models... of course this is poor story composition, which i already criticized, but PM arguments that during prototyping, it is hard to specify everything beforehand, so stories might turn out more complex than initially thought. (i think, they are still poorly designed, but it's getting better^^)

anyway, for these types of tasks, imo it doesn't make so much sense to have such a high frequency of PRs.
also consider that every single PR involves time that other team members have to spend, keeping them from working on their tasks.
since we don't push anything to prod, we don't need this level of quality assurance yet.
we use PRs, but rather after some days or maybe a week.

@soull00t

I do not see it that way. The whole idea about pull requests is that you have a different pair of eyes on it. You basically see the code out of order. Which is bad enough.

The bigger the pull request the less someone will look over it. Basically my indifference is directly proportional to the length of a pull request and I don't believe that's different for others.

So, long pull requests are bad. It destroys the reason behind the pull request in the first place.

@TheCommoner282 don't get me wrong, I agree that code reviews are a good thing. ^^ but i also think that you can't prescribe a fix frequency (e.g. 2 days) that applies for every content, type of software/code, use case and project phase ^^

@Jifuna it might take a while ^^
https://devrant.com/rants/5715846/...