4 ms·

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better

by Twisol 7y ago

> Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. [...] It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. Absolutely. Modeling what you're trying to do in code is a critically important task, and a most surface-level grime is forgivable if you have an understandable foundation. However, I worry that if you focus on the first half of this block, you might think the abstractions aren't important. To a lot of new programmers, abstractions and models are themselves merely "nice" -- if you can get it done without them, clearly they're non-essential, right? I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this.

Vinnl 7y ago
...and also: bad abstractions can be major impediments to it.
- Twisol 7y ago
  Clarity is primary; good abstractions allow you to achieve it. The fact that bad abstractions harm clarity is something we agree on very strongly.
ozim 7y ago
Main point is to be consistent, if it is ugly the same way it is OK. If each time it is ugly different way start thinking about making it consistent. Most value is from consistency, if you make the same mistakes in the same way it is easier to find them. If you make the same mistake in a different way each time, good luck finding it.
majormajor 7y ago
> I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this. Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very, very hard about your abstractions before creating them. Everyone wants to turn every problem into some sort of framework loaded with interfaces and different implementations of them vs being ok with "feature X needs to do thing A, B, and D; feature Y needs to do things A, B, C, and E; let's just have them as two separate endpoints with separate biz logical calling those methods sequentially instead of trying to coerce them together."
- Twisol 7y ago
  > Bad abstractions and models make it much harder to understand code, though. True! The point I'm trying to make is more that code clarity is important and worth striving for, regardless of the means you use to achieve it. Clarity is a non-negotiable part of my definition of "nice". If it's also part of others' idea of "nice" -- especially those of novice developers who look to more experienced developers for guidance -- then this paragraph might suggest that clarity can be down-played. It can't. If you're an experienced developer, you should be able to find good abstractions for achieving clarity in-context. But novice developers can still identify code that's unclear (to them, especially). Blindly applying abstractions rarely helps with code clarity. Some developers apply certain abstractions because "it's a best practice", rather than because it's actually more clear. That's definitely not what I'm advocating for.

by Twisol 7y ago

Vinnl 7y ago

...and also: bad abstractions can be major impediments to it.

Twisol 7y ago
Clarity is primary; good abstractions allow you to achieve it. The fact that bad abstractions harm clarity is something we agree on very strongly.

ozim 7y ago

Main point is to be consistent, if it is ugly the same way it is OK. If each time it is ugly different way start thinking about making it consistent. Most value is from consistency, if you make the same mistakes in the same way it is easier to find them. If you make the same mistake in a different way each time, good luck finding it.

majormajor 7y ago

> I believe that most code is read more often than it's written. (You pass through a lot of code while tracing down bugs!) It pays to reduce the brainpower necessary to understand a block of code, and good abstractions and good models are key to this. Bad abstractions and models make it much harder to understand code, though. So for junior devs, yeah, it would often be better to be very, very careful, and think very, very hard about your abstractions before creating them. Everyone wants to turn every problem into some sort of framework loaded with interfaces and different implementations of them vs being ok with "feature X needs to do thing A, B, and D; feature Y needs to do things A, B, C, and E; let's just have them as two separate endpoints with separate biz logical calling those methods sequentially instead of trying to coerce them together."

Twisol 7y ago
> Bad abstractions and models make it much harder to understand code, though. True! The point I'm trying to make is more that code clarity is important and worth striving for, regardless of the means you use to achieve it. Clarity is a non-negotiable part of my definition of "nice". If it's also part of others' idea of "nice" -- especially those of novice developers who look to more experienced developers for guidance -- then this paragraph might suggest that clarity can be down-played. It can't. If you're an experienced developer, you should be able to find good abstractions for achieving clarity in-context. But novice developers can still identify code that's unclear (to them, especially). Blindly applying abstractions rarely helps with code clarity. Some developers apply certain abstractions because "it's a best practice", rather than because it's actually more clear. That's definitely not what I'm advocating for.