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
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 10, 2022 at 18:35 | comment | added | NiRR | @cjs like I said, I completely agree with everything you said. Maybe its a language barrier. Signing off. | |
| Oct 30, 2022 at 1:48 | comment | added | cjs | @NiRR I'm not sure what you think you wrote, but in your answer (which by my count is nine paragraphs, not two) you did say exactly what I quoted. "Encapsulation" is not a simple switch you turn on or off, and suggesting that a junior developer who doesn't get it right after you merely mentioning it twice cannot learn a technique suggests more that you do not understand at all how to train people. More generally, saying "do better" is very poor feedback; even senior devs will probably not know exactly what your definition of "better" is. | |
| Oct 29, 2022 at 11:37 | comment | added | NiRR | @cjs I agree with everything you wrote in the comment, I believe you simply missed the point I was trying to make. Maybe expecting to touch all the nuances of managing developers with a two paragraph stack exchange answer is a bit of a stretch to begin with. Just to be clear - no where did I write that i think bringing in HR on junior developers for not encapsulating makes any sense.... | |
| Oct 24, 2022 at 7:14 | comment | added | cjs | "If there is a comment from you about encapsulation more than exactly twice, it's time for HR to get involved." This is the primary reason for my downvote. How to do "encapsulation" is not always obvious, nor should it be used every place it can be used; bringing in HR on a junior dev where the problem is more likely your teaching skills is ridiculous. | |
| Oct 22, 2022 at 22:19 | comment | added | Chan-Ho Suh | Developers are probably more like house painters than Michelangelo, who actually meticulously scheduled and planned multi-year projects, carefully budgeting to not waste time or money. | |
| Oct 21, 2022 at 19:40 | comment | added | NiRR | @SteventheEasilyAmused I don't disagree, my suggestion was to help making the conversation simpler. "Go faster" is not constructive. "I expect the deliverable to contain proper comments and input validation" is. | |
| Oct 21, 2022 at 14:23 | comment | added | Steven the Easily Amused | @Steve that you used the word "slowness" is the point. I wrote "slowness - (all other things being equal) is a measure of productivity. I recognize that programming is a creative process, so that part of your analogy is accurate, but a lot of programming is like "painting houses" - there is a clear objective, the means to accomplish it are well understood, and its a matter of getting it done. In that world, the quickest to do a good job is the most productive. | |
| Oct 21, 2022 at 14:11 | comment | added | Steve | @SteventheEasilyAmused, developers are not house painters. Consider, Michelangelo was paid as an artistic designer, not as a painter - they wouldn't have paid a brass tack for his work (or even let him near the ceiling) if he was painting solid colours with a roller, no matter how quickly he could cover an area. So too with developers, slowness is not intrinsically a measure of the productivity of the things they are actually paid for, which is quality of design conceived, not volume of code typed out. | |
| Oct 21, 2022 at 13:30 | comment | added | Steven the Easily Amused | Slowness (all other things being equal) IS a measure of productivity. No one wants to pay a painter who takes 10 days to do what another painter does equally well in 4 hours (unless paying by the job, but even then there is the wait time). No one wants to wait 4 hours for a chef to prepare his meal when it is expected to happen in 20 minutes or less. The same is true of "slow" programmers. Unless the slowness results in better quality (accuracy, completeness), it is a net negative. | |
| S Oct 20, 2022 at 18:47 | review | First answers | |||
| Oct 21, 2022 at 8:51 | |||||
| S Oct 20, 2022 at 18:47 | history | answered | NiRR | CC BY-SA 4.0 |