2 ms·
In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engin
by no_wizard 7y ago
In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code.
Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t seen this be a productivity killer.
Also, with the shocking frequency I’ve seen, code based need more tests. Have them write tests! That’s a fast way to get up to speed.
One other point: senior engineers in one code base may have an uptick if a “junior” in another depending on existing quality, circumstances etc.
I think organizations are lying to themselves that they can only hire seniors. It’s a myth. Just like 10x developers.
I need hard data to be convinced otherwise not anecdotal evidence. All the hard data I’ve seen points in the opposite direction of any anecdotal information I’ve come across.
There are so many volumes of books devoted to these topics alone that I think most ideas around developer productivity without the firm backing of numbers are mostly hand wavy and myths we tell our selves to feel better
- watwut 7y agoWe would have always seniors who are there already for some time to refactor the code. No reason to have it refactored by someone who does not know how to properly code yet and does not know what problems existing structures have or solve. Otherwise you are just switching one mess to another mess. We had juniors for easy new features, tests, anything that is small and isolated.
- scarface74 7y agoHow would a junior no what to refactor and not make it worse? In my experience it’s harder to refactor existing code than to start with green field development.
- no_wizard 7y agoYou give them tasks with frames of reference. Not all refactored are monsters. It does require some guidance though that’s kind of the point. These are just some things I’ve been apart of. I’ve gladly been apart of this before. You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation. Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc. My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It’s a management failure to say you can’t hire junior engineers. It’s one thing to need someone that’s a domain expert, but often I see “senior engineer” === “No ramp time” and I think that’s just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers
- wpietri 7y agoA good way is for them to pair with senior people until they have grasped the direction and motivations of the refactoring work.
- JMTQp8lwXL 7y agoWell-tested code doesn't necessarily lead to code quality. Leaky abstractions will eventually show their hand, in an environment that's not as sanitized as a unit test.
- no_wizard 7y agoUnit test !== only type of test though. Functional tests are a must. I would also say that in this day and age integration tests are also a must. I don’t think there is any domain now where you are commonly interfacing with only your code end to end, some level of integration is happening and that should be tested too. Nothing’s perfect because we are human, I will say though that having proper functional, unit, and integration tests for a codebase I don’t see this issue crop often and when it does it becomes apparent, and then you write a test for that and then you have coverage for that etc. Software is an organism composed of changing structures, after all.