4 ms·

"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Kent Beck

pelasaco 5y ago
Kent Beck said so many other great things.. he was really ahead of his time: http://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Kent.html http://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Ken... Yes, Uncle Bob :)
gpderetta 5y ago
Premature abstraction is the root of all evil.
- giu 5y ago
  There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.
  - grishka 5y ago
    But what about naming things
    - bryanrasmussen 5y ago
      naming things is a form of abstraction.
    - tgv 5y ago
      Follows by symmetry. Proof is left as an exercise for the reader.
    - s_dev 5y ago
      Thats an off by one error which naturally is included in all CS laws.
    - dkersten 5y ago
      Maybe the wrong thing was invalidated from the cache of hard things in computer science.
    - commandlinefan 5y ago
      There are only two hard problems in computer science: cache invalidation, naming things and off-by-one errors.
- dgb23 5y ago
  I liked this article about "semantic compression"[0] by Casey Muratori very much. He also posted some video lectures fairly recently about what he calls "non pessimisation" (a term that I personally didn't read anywhere else so far), which is mostly concerned with performance, but the idea is to simply avoid and isolate abstraction and indirection and programming in a style that adheres to what some people describe as mechanical sympathy. It basically comes down to: 1. Write the code that makes the computer do what it needs to do to achieve a specific goal. No more and no less. 2. Refactor ("compress") the code by deriving re-used (implicit) structures and functions. He puts a lot of emphasis on those steps being done in order and on deferring the second step Note that this is from someone who writes games/engines/tooling so there is a large, real pressure to write simple and reasonably performant, optimizable code. He would also prefer that most of programming would be done in this way. [0] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015
- the_only_law 5y ago
  I cost myself a position recently arguing about this. I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions. The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependencies and conventions. I was kinda backed into a wall and while attempting to explain my reasons I ended up in an argument with the interviewer and it was clear we did not see eye to eye. He would later challenge my ability to perform in a patronizing tone and I was sure the opportunity was dead It wasn’t the only thing that went wrong with that interview, but I feel that disagreement was the biggest killer.
  - ncmncm 5y ago
    Looks to me like you dodged a bullet.
    - DeathArrow 5y ago
      Yes, but it is hard to find teams who are not into abstracting for abstracting sake.
      - ncmncm 5y ago
        It is a good way to sort out prospects, then. I know people who actually believe a typedef for a pointer or atomic type is a Good Idea.
  - redisman 5y ago
    That would be your everyday experience. No reason to not be picky right now. I would go crazy having to work with over-abstract code for OOP religions sake
  - DeathArrow 5y ago
    >In turn I tried to keep the code as simple as possible, with only necessary abstractions. I always talked the talk and walked the walk for the interviews. I know people love Solid, design patterns, Dry, OOP, Restful, Clean Code, complicated architectures. So I am always willing to talk about these and even sprinkle the discussion with the most obscure design patterns they may never heard of. Yes, I do consider some of these being fads or even detrimental to good software but my goal was to be employed, not to convince people that there is not only one True Way.

pelasaco 5y ago

Kent Beck said so many other great things.. he was really ahead of his time: http://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Kent.html http://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Ken... Yes, Uncle Bob :)

gpderetta 5y ago

Premature abstraction is the root of all evil.

giu 5y ago
There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.
- grishka 5y ago
  But what about naming things
  - bryanrasmussen 5y ago
    naming things is a form of abstraction.
  - tgv 5y ago
    Follows by symmetry. Proof is left as an exercise for the reader.
  - s_dev 5y ago
    Thats an off by one error which naturally is included in all CS laws.
  - dkersten 5y ago
    Maybe the wrong thing was invalidated from the cache of hard things in computer science.
  - commandlinefan 5y ago
    There are only two hard problems in computer science: cache invalidation, naming things and off-by-one errors.
dgb23 5y ago
I liked this article about "semantic compression"[0] by Casey Muratori very much. He also posted some video lectures fairly recently about what he calls "non pessimisation" (a term that I personally didn't read anywhere else so far), which is mostly concerned with performance, but the idea is to simply avoid and isolate abstraction and indirection and programming in a style that adheres to what some people describe as mechanical sympathy. It basically comes down to: 1. Write the code that makes the computer do what it needs to do to achieve a specific goal. No more and no less. 2. Refactor ("compress") the code by deriving re-used (implicit) structures and functions. He puts a lot of emphasis on those steps being done in order and on deferring the second step Note that this is from someone who writes games/engines/tooling so there is a large, real pressure to write simple and reasonably performant, optimizable code. He would also prefer that most of programming would be done in this way. [0] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015
the_only_law 5y ago
I cost myself a position recently arguing about this. I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions. The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependencies and conventions. I was kinda backed into a wall and while attempting to explain my reasons I ended up in an argument with the interviewer and it was clear we did not see eye to eye. He would later challenge my ability to perform in a patronizing tone and I was sure the opportunity was dead It wasn’t the only thing that went wrong with that interview, but I feel that disagreement was the biggest killer.
- ncmncm 5y ago
  Looks to me like you dodged a bullet.
  - DeathArrow 5y ago
    Yes, but it is hard to find teams who are not into abstracting for abstracting sake.
    - ncmncm 5y ago
      It is a good way to sort out prospects, then. I know people who actually believe a typedef for a pointer or atomic type is a Good Idea.
- redisman 5y ago
  That would be your everyday experience. No reason to not be picky right now. I would go crazy having to work with over-abstract code for OOP religions sake
- DeathArrow 5y ago
  >In turn I tried to keep the code as simple as possible, with only necessary abstractions. I always talked the talk and walked the walk for the interviews. I know people love Solid, design patterns, Dry, OOP, Restful, Clean Code, complicated architectures. So I am always willing to talk about these and even sprinkle the discussion with the most obscure design patterns they may never heard of. Yes, I do consider some of these being fads or even detrimental to good software but my goal was to be employed, not to convince people that there is not only one True Way.