Timeline for How to help a dev, who is otherwise good, improve the speed at which they work?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2022 at 15:34 | comment | added | Chan-Ho Suh | my nonscientific theory is it's a generational thing and the kind of tech environments that exist now. It's fairly well-established (a la Dunning-Kroger) that less knowledge can make you overconfident. The bar for software development has gone down in some ways.. from that viewpoint, it shouldn't be surprising. | |
| Oct 26, 2022 at 1:30 | comment | added | cjs | @Chan-HoSuh That's interesting. Your experience is the exact opposite of mine. I've almost invariably found that the the senior devs are far more likely to to decide they know they only right way to do something. (Not all of them do this, probably not even a majority. But it's much more likely coming from seniors than juniors.) This has been consistent since I started doing pair programming twenty years ago. | |
| Oct 25, 2022 at 15:34 | comment | added | Chan-Ho Suh | Actually, in my experience, junior and senior devs are the ones that butt heads most strongly. At least with two very experienced people, they can each respect or acknowledge there are different reasons for doing things, but junior devs sometimes have the idea that what they read is the gospel or that the framework they're using has no deficiencies (thus if it's done that way, it must be the only right way!). | |
| Oct 25, 2022 at 14:46 | comment | added | Chan-Ho Suh | @cjs you say you brought pair programming into environments where nobody is begin targeted and nobody felt targeted.. .and this is relevant to this situation where someone in particular is being targeted? Hm.. | |
| Oct 25, 2022 at 4:40 | history | edited | cjs | CC BY-SA 4.0 |
deleted 74 characters in body
|
| Oct 25, 2022 at 4:39 | comment | added | cjs | That said, learning pair-programming with someone more experienced might be a good idea, and I've added the thought to the answer. Though on reflection, I can see many ways that could be a worse option, rather than better. (It's harder to pair-program when you have two strongly opinionated people who are not in full agreement, and that's more likely to happen with two senior developers, especially when they're not familiar with the techniques for dealing with this.) | |
| Oct 25, 2022 at 4:36 | comment | added | cjs | @Chan-HoSuh I really think you're over-thinking this. I've worked in companies where I was the first to bring pair programming into long-existing teams, and started with junior developers, and never had an issue where people felt "targeted." You can of course think up all sorts of problems that could arise if one tries this, but you seem to spend very little effort comparing these to all the other problems that could arise if you chose any of the other alternatives (including doing nothing, thus potentially leaving the junior to be "targeted" by everyone for being slow). | |
| Oct 25, 2022 at 4:32 | history | edited | cjs | CC BY-SA 4.0 |
Suggest practice pairing first, under some circumstances
|
| Oct 24, 2022 at 18:18 | comment | added | Chan-Ho Suh | @cjs nice edit. Not to drag this on too long, but a thought. I think we both would agree this is more effective if done from the beginning and uniformly across the team. As a "sudden" solution that sprouts into existence when a certain dev is having problem, it can be too apparent one person is being "targeted". I would endeavor to do this uniformly and perhaps start with another dev being paired with. (you implicitly suggested this, but just being explicit here) | |
| Oct 24, 2022 at 7:11 | comment | added | cjs | @Chan-HoSuh Thanks for your comments. On further reflection I think that this technique is less likely than the alternatives to lead to the sort of backfiring you're talking about; I've edited the post to explain why. | |
| Oct 24, 2022 at 7:10 | history | edited | cjs | CC BY-SA 4.0 |
Add paragraph re backfiring
|
| Oct 24, 2022 at 1:24 | comment | added | Chan-Ho Suh | @cjs You can have a large probability of a moderate gain and a small probability of a devastating loss. I would agree the "expected value" is positive for pair programming, but obviously that can't be the only consideration. I said "worth a shot" because it sounds to me like the person may get fired. However, OP worded things very carefully; when he said "I also don't want to instill in them anxiety or pressure about how long they take", it did raise the question for me, "is this someone who has shown anxiety before?" If so, I believe my comments are relevant. | |
| Oct 24, 2022 at 0:46 | comment | added | cjs | @Chan-HoSuh Well, you never answered my question, but given your "worth a shot," comment, I'm going to assume you're going with,"it's more likely that they will improve if you pair program with them than if you leave them alone." | |
| Oct 23, 2022 at 22:48 | comment | added | Chan-Ho Suh | @cjs Hard to say. People have different psychological makeups. As an extreme example, some find the experience of having a superior "correcting" their work live a traumatic one. I'm not sure in that case they would be learning anything. Psychological studies show such a stressful scenario can, for instance, reduce cognitive flexibility and reinforce habitual patterns. | |
| Oct 23, 2022 at 4:24 | comment | added | cjs | @Chan-HoSuh Backfiring? Do you think someone is more likely to learn how to fumble less if you just leave them alone than if you pair program with them? | |
| Oct 22, 2022 at 22:03 | comment | added | Chan-Ho Suh | It's an interesting suggestion and worth a shot. If I had to hazard a guess though, this could end up backfiring. Why? Because in my experience, pair programming works better with programmers who have a structured flow, who can take suggestions and adapt to them, or can voice aloud their thought process. Someone that approaches tasks in an unstructured way, basically fumbling about, even on repeated tasks, is likely to be very unproductive once someone is watching them. And that's apparently what we have here. | |
| Oct 21, 2022 at 13:45 | history | edited | cjs | CC BY-SA 4.0 |
added 194 characters in body
|
| Oct 21, 2022 at 10:44 | comment | added | Josh Rumbut | I was going to say exactly this. One little tidbit I might add is to do the pairing with another developer first, both so that you have a baseline to compare and so it doesn't make them nervous you are there to fire them. | |
| Oct 21, 2022 at 8:03 | history | answered | cjs | CC BY-SA 4.0 |