3 ms·

> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible? No he doesn't

• dwaltrip 6y ago
  100% agreed. Code should only be as flexible as necessary to solve the intended problem along with a very cautious estimation of how that problem will evolve in the future. Small critique: s/he
  • cheez 6y ago
    Was on mobile, punctuation is a PITA but normally I use s/he
• zelphirkalt 6y ago
  On the other hand looking into my internal glas orb and expecting the next possible or useful use-case amd making my code flexible / abstract, while keeping it readable, enough to also represent that use-case has saved me hours time and time again. I think there is something to say for not overdoing it, but for not mindlessly implementing only the thing either. Thinking about what is the next abstraction that includes the functionality your want to implement and also is useful to implement anyway, because you already expect the need for flexibility in a certain direction. It depends probably on what type of software you write. Just a few procedures in a legacy code or a little command line tool, standing on its own for example. Certainly implementing only "the thing" gets the job done though. Perhaps doing more is doing more than what one is paid for.
  • cheez 6y ago
    I write code that lasts decades and I can promise you a glass orb is unnecessary.