Timeline for How can I deal with an underperforming peer that does not express interest in following team conventions?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 4, 2020 at 10:25 | comment | added | Thorbjørn Ravn Andersen | So in brief, make it unpersonal, so the process is the bad guy, not you 🙂 | |
| S Jun 4, 2020 at 1:18 | history | edited | Player One | CC BY-SA 4.0 |
Several grammar and orthography improvements
|
| S Jun 4, 2020 at 1:18 | history | suggested | Bernardo Sulzbach | CC BY-SA 4.0 |
Several grammar and orthography improvements
|
| Jun 3, 2020 at 17:24 | review | Suggested edits | |||
| S Jun 4, 2020 at 1:18 | |||||
| Jun 2, 2020 at 20:28 | vote | accept | Kroltan | ||
| Jun 2, 2020 at 20:28 | comment | added | Kroltan | I have met with the team and discussed this and we concluded on the same thing. We'll start doing code reviews and see how this pans out. I have upvoted all answers though, since they bring useful considerations. | |
| May 31, 2020 at 8:21 | comment | added | Askar Kalykov | When translating tech debt to managers, it's better to use real examples and facts. | |
| May 30, 2020 at 23:48 | comment | added | Seiyria | @Mazura I would happily take the time to make sure bad code doesn't get into the codebase. Review doesn't need to be full time, spend a bit of time, review, leave comments, and say "fix these before we will merge it" - this will solve the problem of this code getting into the codebase. | |
| May 30, 2020 at 17:07 | comment | added | Frank Hopkins | @PeterMortensen And while I do believe in pragmatic decisions in general, as a developer I feel our foremost priority is to ensure proper procedures and clean quality solutions. If there really is a hard case to be made for a strict deadline, other people will ask anyway if you cannot rush stuff, but within the team you shouldn't do so just because you feel you might miss the deadline - a deadline that is typically based on rough estimations with a notion that it might take longer. You obviously need to take into account the slow colleague and additional rounds in future estimates. | |
| May 30, 2020 at 17:04 | comment | added | Frank Hopkins | @PeterMortensen Then you fail the deadline if you don't have proper code till then. You don't allow people to drive over an unfinished bridge either but postpone the start date. If it's just the paint at one place missing, sure then schedule the paint job right for the next day after the opening and make it clear that some work will have to follow afterwards. Create a cleanup ticket and make sure it has high enough prio that it is actually done. This does require some level of team backing obviously, if your team wants to produce shitty code, it always will. | |
| May 30, 2020 at 9:10 | comment | added | Peter Mortensen | Yes, but what will happen when coming close a deadline and the pressure is on? | |
| May 30, 2020 at 1:37 | comment | added | Koenigsberg | @BernhardBarker My assumptions are also based around platforms such as GitLab. However OP mentions they are at similar level as Bob - they may not have the authority to just decide to change a few settings, thus establishing team practices, this is why in my view an emphasis on team concensus is important. As for rejection, I assumed it is clear that a rejection should go along with a proper reason and suggestions to improve the rejected code. This is not clear from my post and you are right to point it out. | |
| May 30, 2020 at 1:19 | comment | added | Mazura | "Designate a maintainer with elevated privileges." = Make it someone's full-time job to vet code. ? ... 'Volunteers?' | |
| May 30, 2020 at 0:43 | comment | added | Bernhard Barker | If you're using something like GitHub, a lot of what you're proposing can be accomplished by changing a few settings rather than trusting people to follow the correct process and reverting their changes if they don't. It should also cause less conflict. There are settings to prevent merging PRs without approval and there would be no need to revert unapproved merges because those wouldn't even be possible. Also, don't "reject" merge requests; leave comments suggesting how to fix them. And having a single maintainer seems like setting yourself up for issues when that person goes on leave. | |
| May 29, 2020 at 16:11 | history | edited | Koenigsberg | CC BY-SA 4.0 |
edited body
|
| May 29, 2020 at 15:50 | history | edited | Koenigsberg | CC BY-SA 4.0 |
added 1130 characters in body
|
| May 29, 2020 at 15:39 | history | answered | Koenigsberg | CC BY-SA 4.0 |