Definitely this. It can be helpful to both parties. The learning opportunities for experienced developers start to thin with time, and one of the best ways to combat that is to get a fresh perspective.
Yea unfortunately, this is one of those things one really end up learning by experience. Once you've been writing code for long enough (and especially in a codebase that's been highly) is when the developer experience starts to be a thing that really occupies your mind when building.
Yeah, most won't really become devs, but they'll gain some newfound technical literacy and some respect for what devs do full-time.
It's important in these situations to look outside of the context and just see what's actually happening: people are learning. And that has more positives than negatives I'm sure.
If you know your team well, it will help you keep an eye out for common mistakes they've made in the past. It may also help adjust your tone, as developers you've worked with for a long time will understand light humor or other well-intended comments that might be read as off-putting by newer devs.
There's always a story behind every codebase. Taking the new team member through the codebase at a high level, telling the story and explaining how everything fits together and is deployed is a time well spent.
It helps me connect with them, develops empathy, understanding and aids my form of communication with them.
The how is explained above. Why you should is "because humans".
There's a large amount of room for developers with low level knowledge (data structures are a huge gap for new devs) and devs that know how to manage a codebase over years.
Given how many degrees of freedom (knowledge of language, operating system, data structures, IDE/git, testing, browsers/JS, database/network/web service dependencies etc) I think most experienced devs will have something to offer you, especially the ones your "equal"
And i think it's great to be able to dictate code out loud. And it's a lot easier on your wrists.
The point being made is the lucidity of explanation is part of the dev job. We aren't all just code monkeys, typing out programs for 8 hours straight every day.
Being able to design, describe, explain, and critique in a way that doesn't make everyone at your company resent you is far more important than any dev hard skill.
I thought the same thing until I started doing a significant amount of code reviews. You need to know these things to explain to more junior devs to help them become better programmers.
I myself am in a position where I'm treated like an apprentice, and it's great. I've only been programming for a couple of years and the rate at which I'm learning, and the broad swath of knowledge I feel like I'm getting from the senior developers is great.
reply