4 ms·

I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would di

I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would discuss with him like 4-5 times a day sometimes. It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I never tried it, so I don't know.

jdbernard 5y ago
To be fair, in the cases I'm thinking of it's more just chucking a new guy into the mess without direction. I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
JohnBooty 5y ago
I feel like if I would've been sitting with him I would have wasted a lot of his time Yeah I think forcing devs to pair for no reason and simply hoping the magic happens... tends to waste time What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense. Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it. I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided. Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.

4 ms·

I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would di

by newtwilly 5y ago

jdbernard 5y ago
To be fair, in the cases I'm thinking of it's more just chucking a new guy into the mess without direction. I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
JohnBooty 5y ago
I feel like if I would've been sitting with him I would have wasted a lot of his time Yeah I think forcing devs to pair for no reason and simply hoping the magic happens... tends to waste time What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense. Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it. I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided. Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.