3 ms·

Junior developers and newbie in general have one incredible quality: they don’t know and they are not supposed to. You absolutely want to tell them that their r

by bertil 9y ago

Junior developers and newbie in general have one incredible quality: they don’t know and they are not supposed to. You absolutely want to tell them that their role is to criticise and occasionally write the documentation. Start from things that are obvious and leverage their question: anything they ask, tell them it’s now their role to document it. How the business makes money, what that metric means, what is TDD, what happens with this fails, whether the company actually ships bug-free code. One pattern that I use: - pair program initially; I would do that even for principal, just to be familiar with the code base, but for probably one or two days, after that, they should be autonomous; for very junior developers, a week make more sense, but rarely more; - gradually replace that with code review, but more than once a day for more junior people; ask them kindly to commit; make sure to point out one or two issues in each very small PR: linting, method naming convention, then testing patterns, structure, etc. - have scheduled 30 minutes 1:1 meetings, preferably thrice or twice a week; make sure there is something nice at some of those: ice cream, walk out if it’s sunny, and have that meeting have four very explicit parts: what they have done, what blocked them; what they have learned; what they have taught (or documented). The last one is often overlooked but it’s very important for them to realise that they start owning some code, that they should think not of they direct impact but how to empower people. React to blockages by offering solutions, both from them and from you: they need to learn to unblock and that’s how you do it. Move that meeting to once a week for senior developer, once a fortnight for principals.

humanrebar 9y ago
> ...make sure to point out one or two issues in each very small PR... And try to bring up one or two improvements or good ideas. Being a proper critic involves praising things as well as panning them. If they weren't good at something, you wouldn't have hired them. If the entire review is straightforward an unsurprising, that's actually a good thing. Say it's very clear and easy to work with.
mdn0420 9y ago
In my experience, pair program is especially valuable for learning workflow, tools, debugging tricks, etc. For instance, I remember learning how to efficiently navigate a project with an IDE through pair programming. For ramping up on codebase/architecture, I prefer a brain dump then go off on my own and ask questions as needed. Every person has their own method and preferences of course.
afarrell 9y ago
> anything they ask, tell them it’s now their role to document it. Depending on how you interpret it, this advice is either great or terrible. If you read this to mean that the new person to a project should start out by documenting the things they don't know, then this is bad: - There are definitely Open Source projects which have this attitude and don't write user-facing documentation, expecting new-joiners to write it. This makes it both hard for a new person to join a project and hard for the project to market itself. - If you are just starting out on a project, it can be hard to know what are the key concepts that a person should really know in order to be efficient and what is incidental. It may or may not be a good idea for them to spend a bunch of time documenting ways in which your test setup uses selenium after running into some really weird end-to-end test bug. - If you don't know something, it is really hard to write a coherent explanation of it. You have to both empathize with ignorance and have the knowledge. Otherwise, you can just end up stuck/lost. If you don't have anyone willing to help you un-stick yourself... But that doesn't sound like the interpretation you mean. From the rest of your post, it very much sounds like you mean that the new person should turn a vocal explanation into a written one as a way of both confirming their knowledge and passing it on to others. This sounds great. It will generate lots of draft docs though, so you probably need some habit or person to keep them organized and keep them from getting stale.
- bertil 9y ago
  I certainly try to structure their documents a lot, and point them at the people who can answer their question -- although most of my energy is spent not assaulting anyone refusing to document properly with ”but I know it, so it's fine, you just have to ask me” or ”but it’s on an email somewhere, is that not enough?”. The best audience for the document is “who you were two days ago” and they generally have some empathy for that person for a day or two.

by bertil 9y ago

humanrebar 9y ago

> ...make sure to point out one or two issues in each very small PR... And try to bring up one or two improvements or good ideas. Being a proper critic involves praising things as well as panning them. If they weren't good at something, you wouldn't have hired them. If the entire review is straightforward an unsurprising, that's actually a good thing. Say it's very clear and easy to work with.

mdn0420 9y ago

In my experience, pair program is especially valuable for learning workflow, tools, debugging tricks, etc. For instance, I remember learning how to efficiently navigate a project with an IDE through pair programming. For ramping up on codebase/architecture, I prefer a brain dump then go off on my own and ask questions as needed. Every person has their own method and preferences of course.

afarrell 9y ago

> anything they ask, tell them it’s now their role to document it. Depending on how you interpret it, this advice is either great or terrible. If you read this to mean that the new person to a project should start out by documenting the things they don't know, then this is bad: - There are definitely Open Source projects which have this attitude and don't write user-facing documentation, expecting new-joiners to write it. This makes it both hard for a new person to join a project and hard for the project to market itself. - If you are just starting out on a project, it can be hard to know what are the key concepts that a person should really know in order to be efficient and what is incidental. It may or may not be a good idea for them to spend a bunch of time documenting ways in which your test setup uses selenium after running into some really weird end-to-end test bug. - If you don't know something, it is really hard to write a coherent explanation of it. You have to both empathize with ignorance and have the knowledge. Otherwise, you can just end up stuck/lost. If you don't have anyone willing to help you un-stick yourself... But that doesn't sound like the interpretation you mean. From the rest of your post, it very much sounds like you mean that the new person should turn a vocal explanation into a written one as a way of both confirming their knowledge and passing it on to others. This sounds great. It will generate lots of draft docs though, so you probably need some habit or person to keep them organized and keep them from getting stale.

bertil 9y ago
I certainly try to structure their documents a lot, and point them at the people who can answer their question -- although most of my energy is spent not assaulting anyone refusing to document properly with ”but I know it, so it's fine, you just have to ask me” or ”but it’s on an email somewhere, is that not enough?”. The best audience for the document is “who you were two days ago” and they generally have some empathy for that person for a day or two.