4 ms·

My grading criteria for a codebase is "Can a hungover junior engineer comprehend this and work on it successfully?" When we are getting to "only a Principle en

My grading criteria for a codebase is "Can a hungover junior engineer comprehend this and work on it successfully?" When we are getting to "only a Principle engineer who is an expert in scala with a history of strong mathematics can work on this" is about when a codebase gets a fail.

kungito 5y ago
Thats a broad generalization and many niche codebases cannot be high quality and still have a drunk junior become productive with it in a week. People need to accept that it's ok to require for some teams to have discussions on a level which requires serious experience and education
- catlifeonmars 5y ago
  Indeed. A more nuanced interpretation of the question might be: “Can the most junior (or least tenured) engineer on my team understand the code in time to deliver the feature they’re working on?” To be fair, OP’s original phrasing is still a good rule of thumb. And nowhere does the OP imply it’s an absolute.
jim-jim-jim 5y ago
This does a massive long-term disservice to junior engineers, especially because they're most likely just out of school and still very eager to learn.
- d110af5ccf 5y ago
  Merely being interesting or rewarding to work on doesn't justify complexity though. I think it's a reasonable mindset to approach things with in an attempt to simplify things whenever possible. Your entire team could be highly experienced and have PhDs in exotic subjects and I still think it would be a good approach to take.
  - jim-jim-jim 5y ago
    > Merely being interesting or rewarding to work on doesn't justify complexity though. I think it's a reasonable mindset to approach things with in an attempt to simplify things whenever possible. Yes. The simplest code isn't always the most immediately approachable though. At least due to the way universities and bootcamps teach things. OOP only smears complexity around and should be avoided at all costs, but the "simple" alternatives that most people have in mind (usually procedural Python/Go) aren't much better. Simplicity shouldn't be synonymous with repetitive, error-prone nonsense like for loops and null checks just because they are familiar. Junior engineers should be schooled up on mapping, folding, optional types, ADTs in general, etc, because these things make code radically simpler.
d110af5ccf 5y ago
> with a history of strong mathematics TBF that one is really going to depend on the domain addressed by the code.
deleted 5y ago
[deleted]

kungito 5y ago

Thats a broad generalization and many niche codebases cannot be high quality and still have a drunk junior become productive with it in a week. People need to accept that it's ok to require for some teams to have discussions on a level which requires serious experience and education

catlifeonmars 5y ago
Indeed. A more nuanced interpretation of the question might be: “Can the most junior (or least tenured) engineer on my team understand the code in time to deliver the feature they’re working on?” To be fair, OP’s original phrasing is still a good rule of thumb. And nowhere does the OP imply it’s an absolute.

jim-jim-jim 5y ago

This does a massive long-term disservice to junior engineers, especially because they're most likely just out of school and still very eager to learn.

d110af5ccf 5y ago
Merely being interesting or rewarding to work on doesn't justify complexity though. I think it's a reasonable mindset to approach things with in an attempt to simplify things whenever possible. Your entire team could be highly experienced and have PhDs in exotic subjects and I still think it would be a good approach to take.
- jim-jim-jim 5y ago
  > Merely being interesting or rewarding to work on doesn't justify complexity though. I think it's a reasonable mindset to approach things with in an attempt to simplify things whenever possible. Yes. The simplest code isn't always the most immediately approachable though. At least due to the way universities and bootcamps teach things. OOP only smears complexity around and should be avoided at all costs, but the "simple" alternatives that most people have in mind (usually procedural Python/Go) aren't much better. Simplicity shouldn't be synonymous with repetitive, error-prone nonsense like for loops and null checks just because they are familiar. Junior engineers should be schooled up on mapping, folding, optional types, ADTs in general, etc, because these things make code radically simpler.

d110af5ccf 5y ago

> with a history of strong mathematics TBF that one is really going to depend on the domain addressed by the code.

deleted 5y ago

[deleted]