5 ms·

How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the proble

How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the problem 3. Years of dev effort spent with the abstraction at the core 4. Dev on step 2 is now the expert in some overly convoluted complex system 5. Is determined a genius since new comers cant easily grasp the complexity, gets promoted to a high ranking dev job My number one rule of coding politics: He who creates the OOP abstraction rules the team

vorpalhex 5y ago
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]
deleted 5y ago
[deleted]
vlunkr 5y ago
I agree, but I could also say the same thing about functional programming. If you let the dev that won't stop talking about monads touch your javascript code base it will soon become a tangled => web => of => arrow => functions
- eptcyka 5y ago
  Regular non-functional JavaScript code is riddled with non-arrow freestanding functions, is that any better?
  - vlunkr 5y ago
    I don't have a problem with arrow functions, just saying you can make a huge mess with OOP or FP.
  - recursive 5y ago
    Probably, because you step through it in a debugger without bouncing all over the code base for each expression.
bitwize 5y ago
This pretty much happened at one of my jobs. Principal engineer was airdropped into team and decided everybody would develop all new microservices with his new pet framework (literally, it was named after his dog) with Spring style DI cruft that was in many ways more difficult to work with than Spring. He enjoyed rulership of the team for a while before leaving for greener pa$ture$, and on his last day of work, he changed the README on the open source repository of the framework to point to his own, personal, repo as the locus for all future development. A move widely frowned on, especially by management and legal, which soured his reputation, and higher-up architects had different ideas anyway, so the pet framework was deprecated for future development. Lesson: If you're going to code your way into being the only developer who understands the core abstraction behind your employer's critical code, do not overplay your hand.
lelanthran 5y ago
What does OOP have to do with any of that? I was at a dev shop that used no OOP, and everything happened the same way. :-/

vorpalhex 5y ago

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]

deleted 5y ago

[deleted]

vlunkr 5y ago

I agree, but I could also say the same thing about functional programming. If you let the dev that won't stop talking about monads touch your javascript code base it will soon become a tangled => web => of => arrow => functions

eptcyka 5y ago
Regular non-functional JavaScript code is riddled with non-arrow freestanding functions, is that any better?
- vlunkr 5y ago
  I don't have a problem with arrow functions, just saying you can make a huge mess with OOP or FP.
- recursive 5y ago
  Probably, because you step through it in a debugger without bouncing all over the code base for each expression.

bitwize 5y ago

This pretty much happened at one of my jobs. Principal engineer was airdropped into team and decided everybody would develop all new microservices with his new pet framework (literally, it was named after his dog) with Spring style DI cruft that was in many ways more difficult to work with than Spring. He enjoyed rulership of the team for a while before leaving for greener pa$ture$, and on his last day of work, he changed the README on the open source repository of the framework to point to his own, personal, repo as the locus for all future development. A move widely frowned on, especially by management and legal, which soured his reputation, and higher-up architects had different ideas anyway, so the pet framework was deprecated for future development. Lesson: If you're going to code your way into being the only developer who understands the core abstraction behind your employer's critical code, do not overplay your hand.

lelanthran 5y ago

What does OOP have to do with any of that? I was at a dev shop that used no OOP, and everything happened the same way. :-/