4 ms·

> You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintai

> You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintain it when you're gone. So effectively you have failed. 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. So I mean, yes, but also no. Sometimes it's OK to expect people to have some domain knowledge. Doesn't mean your code should be spaghetti of course.

ramy_d 6y ago
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.
aequitas 6y ago
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.
efsavage 6y ago
> if the junior or medior doesn't understand matrices, nothing I do will make them understand them. Teaching them will.
- hinkley 6y ago
  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.
  - FroshKiller 6y ago
    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.
  - efsavage 6y ago
    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".
  - eek04_ 6y ago
    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.
lhorie 6y ago
> 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.
Kalium 6y ago
> 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).
Mauricebranagh 6y ago
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"
wonder_er 6y ago
> 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.)
- gmfawcett 6y ago
  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."
  - peterwoerner 6y ago
    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.
hyperpallium2 6y ago
Will it be maintained, and whose fault that is, are separate issues.
zffr 6y ago
> 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.
8note 6y ago
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

ramy_d 6y ago

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.

aequitas 6y ago

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.

efsavage 6y ago

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

hinkley 6y ago
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.
- FroshKiller 6y ago
  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.
- efsavage 6y ago
  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".
- eek04_ 6y ago
  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.

lhorie 6y ago

> 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.

Kalium 6y ago

> 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).

Mauricebranagh 6y ago

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"

wonder_er 6y ago

> 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.)

gmfawcett 6y ago
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."
- peterwoerner 6y ago
  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.

hyperpallium2 6y ago

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

zffr 6y ago

> 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.

8note 6y ago

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