[saidinesh5]

I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.

I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.

Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.

I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.

[addaon]

Are you at a company that tends to hire from non-traditional backgrounds? The topics you mention -- the underlying "how it works" of the tech we use to build things day to day -- should be, and in my experience are, the areas where juniors have the clearest understanding relative to more senior engineers, since they just finished 4+ years learning about it five days a week in detail.

[saidinesh5]

Good point.. A lot of those colleagues were indeed either fresh out of college (math, computer science, mechanism etc...) or graduated in things like electrical engineering etc.. and worked in software roles for 3-5 years..