Timeline for How to deal with 'almost good' code from a junior developer? [closed]
Current License: CC BY-SA 3.0
37 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 22, 2020 at 4:00 | review | Reopen votes | |||
| Feb 27, 2020 at 3:05 | |||||
| Jun 7, 2017 at 23:27 | history | closed |
gnat GrandmasterB Thomas Owens♦ |
Not suitable for this site | |
| Jun 7, 2017 at 19:55 | comment | added | tom | +1 for linter tools, either on push or in CI. Most of these issues can be caught without human intervention. If they run alongside automated tests, you get much quicker feedback loops, and fixing these small coding style issues becomes much less tedious. Another nice factor is that it offsets the blame all around (there is less ego bruising when the machine tells you you're wrong than when a human tells you you're wrong) | |
| Jun 7, 2017 at 17:44 | history | protected | gnat | ||
| Jun 7, 2017 at 16:56 | answer | added | 200_success | timeline score: 0 | |
| Jun 7, 2017 at 16:40 | comment | added | Zalomon | @JeffO Not much design, since the tasks that are handed to him are not huge. But he started to put helper methods on classes totally unrelated to what he was doing. That does not make a class a God class automatically but it's the first step. | |
| Jun 7, 2017 at 16:34 | comment | added | JeffO | How much design is a remote junior dev doing? Usually with larger teams there would be some help with upfront design so things like God objects would never be considered. | |
| Jun 7, 2017 at 16:33 | comment | added | Andrea Lazzarotto |
The only time you should have no mercy is if the developer writes an opening curly bracket { on its own line, when it relates to a for, if, etc. ;)
|
|
| Jun 7, 2017 at 15:21 | answer | added | zak | timeline score: 1 | |
| Jun 7, 2017 at 15:06 | answer | added | BartoszKP | timeline score: 0 | |
| Jun 7, 2017 at 11:48 | vote | accept | Zalomon | ||
| Jun 7, 2017 at 10:49 | comment | added | dcorking | Have you considered peer reviews and linters? Have junior developers review each others code, or even your code. When a learner looks for improvements in others code it can improve ability to see them in their own code. When the time is right, encourage use of a lint tool, preferably one that autocorrects or lints on the fly. Good linters like rubocop can even spot simple refactoring opportunities. This means the code review can concentrate on the big structural issues and defensive coding gotchas that newbies can't see, | |
| S Jun 7, 2017 at 8:12 | history | edited | Zalomon | CC BY-SA 3.0 |
corrected grammar and typos; slightly changed wording;
|
| S Jun 7, 2017 at 8:12 | history | suggested | Søren D. Ptæus | CC BY-SA 3.0 |
corrected grammar and typos; slightly changed wording;
|
| Jun 7, 2017 at 8:01 | review | Suggested edits | |||
| S Jun 7, 2017 at 8:12 | |||||
| Jun 7, 2017 at 7:08 | comment | added | Sikorski | accomplishment before perfection ! | |
| Jun 7, 2017 at 3:36 | answer | added | closeparen | timeline score: 2 | |
| Jun 6, 2017 at 22:02 | comment | added | Sandy Chapman | Some things I've tried that help with this: pair programming - gain insight into how he works and thinks and maybe expose him to your thought processes as you go through your code. Find the tasks he's good at - sometimes you'll get better results throwing a bunch of small bugs at him vs large feature work. Tech designs - give him first crack at designing software without touching the code. This lets him think about structure and process vs putting his head down and churning out code. Lastly, good luck. It sometimes takes more persistence than expected but is worth it if he becomes productive. | |
| Jun 6, 2017 at 19:28 | answer | added | Legato | timeline score: 20 | |
| Jun 6, 2017 at 19:24 | answer | added | Machado | timeline score: 5 | |
| Jun 6, 2017 at 19:16 | answer | added | gnasher729 | timeline score: 5 | |
| Jun 6, 2017 at 18:46 | answer | added | Kevin Krumwiede | timeline score: 1 | |
| Jun 6, 2017 at 17:50 | answer | added | JacquesB | timeline score: 2 | |
| Jun 6, 2017 at 17:47 | answer | added | acithium | timeline score: -1 | |
| Jun 6, 2017 at 17:46 | answer | added | John Wu | timeline score: 4 | |
| Jun 6, 2017 at 16:40 | answer | added | JimmyJames | timeline score: 5 | |
| Jun 6, 2017 at 16:17 | review | Close votes | |||
| Jun 7, 2017 at 23:31 | |||||
| Jun 6, 2017 at 16:16 | comment | added | enderland | I edited this to make it more on topic. I believe this is different than the linked duplicate question as well. | |
| Jun 6, 2017 at 16:12 | history | edited | enderland | CC BY-SA 3.0 |
deleted 197 characters in body
|
| Jun 6, 2017 at 16:12 | answer | added | enderland | timeline score: 87 | |
| Jun 6, 2017 at 16:06 | history | edited | Zalomon | CC BY-SA 3.0 |
added 229 characters in body
|
| Jun 6, 2017 at 16:03 | comment | added | Zalomon | @gnat I think it's not the same case, my problem is not that we're exceeding estimates or overdoing code. Matter of fact we're ahead schedule. My question is how to balance the line between teaching the guy and not burning him out with constant criticism, for a junior it can be frustrating if you tell him to redo stuff that to his eyes is working. | |
| Jun 6, 2017 at 15:59 | comment | added | Zalomon | I made a document with software guidelines that included examples and counter-examples. Also, both when I ask him to change something or I change it myself I inform him what I'm trying to achieve. | |
| Jun 6, 2017 at 15:59 | comment | added | gnat | Possible duplicate of How to stop gold-plating and just be content to release working developments | |
| Jun 6, 2017 at 15:58 | comment | added | Blrfl | How much time have you spent making sure he knows what your expectations are? | |
| Jun 6, 2017 at 15:55 | history | edited | FrustratedWithFormsDesigner | CC BY-SA 3.0 |
added 13 characters in body
|
| Jun 6, 2017 at 15:50 | history | asked | Zalomon | CC BY-SA 3.0 |