> if the junior or medior doesn't understand matrices, nothing I do will make them understand them

Oh but there are things we can do. We can add comments that link to resources, we can write long prose (both inline in comments and in out-of-band documents such as RFCs and documentation) explaining why we're using something that nobody else in the team understands vs the alternatives, and we can level people up via informal sessions like lunch-and-learns, info sharing sessions, etc.

It's true that many juniors aren't capable of following concepts above a certain level of difficulty, but it's also not rare for people to really flourish if given a gentle push.

There's definitely a paretto balance when it comes to knowledge sharing. Don't be that person that writes zero docs and hogs all the knowledge when you could spend 20% effort to level up 80% of people to the point where they can start helping each other.

> Overall I agree with you, yeah. But also no. Of course the code should be as simple to understand as possible, but if the junior or medior doesn't understand matrices, nothing I do will make them understand them.

There is a difference between code that is complex because it needs to be (ex: matrix mathematics) and code that is complex because you wanted it to be (ex: microservices and kafka and obscure functional languages for what could have been a Rails CRUD webapp).

> if the junior or medior doesn't understand matrices, nothing I do will make them understand them.

Teaching them will.

You can explain, you can teach, or you can refactor.

Sometimes refactoring is the cheapest of the three, but you won't know until you try to explain/teach it.

Often, explaining/teaching has only short term value in terms of the product. The code will outlive the team; I try to factor the knowledge into the code, making the code easy to deal with.

I also spend a lot of time explaining and teaching, as it is necessary, but it's really a stopgap measure. Give it a few years and there's mostly new people.

It was cheaper for me to ask my junior which of two blocks he understood more easily and eliminate the style he didn't grasp immediately throughout the project than it would've been to try to teach him and every programmer that follows him on the project for sure.

Agreed, but if cheap is your goal, you shouldn't be hiring junior devs. The leanest companies I've seen/worked for were all senior people. "No passengers".

Maybe they don't have to understand the detailed inner workings of an algorithm and such. But they should be able to deal with that piece of code in abstract. A good comment on what a piece of code is intended to do is perfectly fine to know it's place in a greater whole. Not every developer knows how crypto functions work, but they can make good decisions on how these functions should fit in certain logical scenarios or if an implementation is badly written/documented.

yeah I would say in principle this makes sense but in practice a junior will typically say "this is beyond me but you're the senior so if it works, it works!"

It is an opportunity to go through the code and concepts at least.

Do you expect these developers to be able to debug this code after its in production? Or is that bottlenecked to yourself?

Having most of your team not be able to understand the code they support sounds dangerous

> Rather, let everyone (juniors, QA, non-developers) in the team perform reviews of everyones code, even your senior code.

I think the OP is just saying that juniors should be allowed to participate in the reviews of senior engineer code (not that a junior review alone is sufficient for merging a PR).

I think this is a great way for juniors to get exposure to the complex topics they might not yet understand, but should learn more about.

> but if the junior or medior doesn't understand matrices, nothing I do will make them understand them.

What if you took a hour or a day to help educate an eager junior developer about what you did in that PR?

I, personally, don't know matrices. I can damn well learn them if it becomes relevant to me.

If we were on the same team, and I said "what's this stuff?" and you said "nothing I can do will make you understand this" I'd be pissed, and that attitude would _permanently sour_ the relationship.

I imagine there was a point in time that _you_ did not understand matrices. I've no doubt that matrices can be tricky, difficult to understand, etc.

So, lets work together on sharing that knowledge! Once you've helped me learn it (pointing me to resources, pairing with me on an example problem solving session involving matrices) I will be able to maintain the code, understand it, and apply the pattern to novel problems.

But not just that, because I am a compulsive documenter of what I've learned, as you teach me, you help me teach _everyone who comes behind me_

TL;DR the attitude of "if jr/med devs don't already understand matrices, nothing I do will make them understand them." is _extremely_ self-limiting, locking you out of tons of potential value, and causing your entire team to be worse off.

It's not your fault, per se. I know this attitude is common in the industry. It just really pisses me off, because so many teams are deeply damaged by it.

(I know, I know. Maybe you'd love to slow down and teach early-career devs, but the feature death-slog required by management precludes you taking that time... in that case this isn't directly your fault, etc.)

In defense of the seniors... It generally takes people several semesters of Linear Algebra to become competent with "matrix stuff." It's unrealistic to expect every senior dev to also be an expert teacher -- never mind expecting them to know what the latest and best learning resources are (for a subject they may have learned, themselves, before the Web was invented).

Sometimes the right and fair substitute for "nothing I can do will help you" is "get yourself a proper education on this subject, somehow, and then we can talk about the code."

I think the issue is that many of us are poor communicators (myself being number 1) so we say nothing I can do will help you instead of I can't teach linear algebra, numerical analysis and do the code review in an hour. Therefore putting a junior engineer who has a weak math background on a code review for my new algorithm which uses spectral sparsification for approximating matrix inverses in n log(n) isn't a good idea.

But a junior can still ask question like: "why isn't there a test for this code", "why are the business logic and algorithm code mixed together" or "why doesn't this align with the design documentation we wrote last week, does it need updating?".

And the junior will learn which things to learn. I certainly think you should allow juniors to code review senior coders work if for nothing more than mentoring, but I am sensitive as to why an overloaded senior would balk at the idea.

Wildly off-topic, but I recently learned this. Use asterisks in HN to express emphasis* in italics*. I too used underscores (a la Slack) up until a couple weeks ago when I noticed a comment from Dang somewhere saying how to emphasize.

aaaah thank you!

I often mis-apply slack/markdown formatting.

Instead, now I will less often mis-apply markdown formatting to hacker news.

Thank you!

And this isn't "wildly off-topic", by the way. This is "extremely germane to what I said, but addresses something other than the specific point I was trying to say."

Doesn't make it not helpful. In fact, I bet there are many situations where this kind of feedback is more (I almost wrongly-formatted that!) helpful than addressing the comment directly.

You, dear internet stranger, have taught me something. Thank you!

Shurly the point is you a document it and if required walk them though the code and mentor them.

And not to what some one did mumble years ago when I was taking over the map part of a map reduce product built in PL1/G and say after 3 days "haven't you learnt it all yet"

Will it be maintained, and whose fault that is, are separate issues.