4 ms·

Code that is easier to read == better code. That's something I see most people struggling with, including myself, in particular when learning a new language.

Code that is easier to read == better code. That's something I see most people struggling with, including myself, in particular when learning a new language. e.g. in kotlin it can be tempting to use a ton of complex operators and rely on the intricacies of let vs run vs apply .. even if the resulting code takes some thinking to understand. At the beginning of my career, the code I was the proudest of was a gigantic piece of code doing some very complex stuff. It took a lot of effort to understand. Nowadays I am extremely happy when I take a complex problem and solve it only by writing very simple code that even the most junior dev we would hire can easily understand. The downside I can see is that in some orgs more respect is given if you write black box code making you unfireable but that's a good sign you don't want to work there/need to make the culture evolve.

ASlave2Gravity 7y ago
It's funny how one can feel ashamed for not using the esoteric language features. Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever!
- speedplane 7y ago
  > Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever! On the upside, this process is all about learning. It's easy to be clever, it's hard to be clever and successful. Making these mistakes and fixing them is how you turn knowledge into wisdom.
iforgotpassword 7y ago
That often depends on how familiar you are with a code base, and your personal knowledge about for example linear algebra or whatever specific thing is going on somewhere. Obviously there is no objective "right" in this matter, but always writing code that the greatest idiot can understand obviously isn't good either. Another problem with the duplication approach is that I'd you need to make some change later on, you need to apply it to 12 places and are pretty much guaranteed to mess up one of them, since this is the most boring task ever and your brain switches to lie power auto pilot after the third instance.
- sixstringtheory 7y ago
  Either you need to change 12 places and test those 12 (or whatever) use cases, or make one change and still test those use cases. Only with the DRY function, as the article says, it’ll wind up accumulating options and configuration to accommodate all those use cases, becoming a big hairy abstraction that’s harder to understand for any of those use cases, whereas with the duplicated functions they would all evolve separately and in isolation and remain independently simpler.

ASlave2Gravity 7y ago

It's funny how one can feel ashamed for not using the esoteric language features. Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever!

speedplane 7y ago
> Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever! On the upside, this process is all about learning. It's easy to be clever, it's hard to be clever and successful. Making these mistakes and fixing them is how you turn knowledge into wisdom.

iforgotpassword 7y ago

That often depends on how familiar you are with a code base, and your personal knowledge about for example linear algebra or whatever specific thing is going on somewhere. Obviously there is no objective "right" in this matter, but always writing code that the greatest idiot can understand obviously isn't good either. Another problem with the duplication approach is that I'd you need to make some change later on, you need to apply it to 12 places and are pretty much guaranteed to mess up one of them, since this is the most boring task ever and your brain switches to lie power auto pilot after the third instance.

sixstringtheory 7y ago
Either you need to change 12 places and test those 12 (or whatever) use cases, or make one change and still test those use cases. Only with the DRY function, as the article says, it’ll wind up accumulating options and configuration to accommodate all those use cases, becoming a big hairy abstraction that’s harder to understand for any of those use cases, whereas with the duplicated functions they would all evolve separately and in isolation and remain independently simpler.