5 ms·

The more experience I get, the more I feel that too many programmers worry about making things pretty "in the small", but not enough care about proper design of

The more experience I get, the more I feel that too many programmers worry about making things pretty "in the small", but not enough care about proper design of an entire codebase. I'll admit that I like a concise and well-crafted function just as much as many others, but articles like this one are probably the things that can lead to the kind of unproductive bikeshedding that is sometimes experienced in PRs and other discussions. I don't care that much about whether your function is messy - or about where you put your ifs and fors (or if you use maps and filters instead), as long as the function is properly named, has a good interface (including expressive types), a clear purpose, is properly documented, doesn't make excessive use of side effects etc.

kubb 3y ago
Programming language design also tends to focus on the small (e.g. optimizing the number of language keywords).
tangjurine 3y ago
Like there's the stuff that can be refactored because the changes are local, or the places to change are clear. And then the stuff that is a lot harder to refactor because you would need to change code in a lot of places, and the places that need to be changed aren't clear. That's probably more the proper design of a codebase stuff.
Leo_Germond 3y ago
The advice about if up is not bikeshedding though, it is the exact kind of architectural choice you're saying one should decide on. Don't believe me ? Well imagine you have inputs, where should you validate them ? According to this rule of thumb it's at the topmost level, when they are received. Well that seems super sensible, and it's typically something that helps with understanding the code (rather than checking them at thw very last moment). Also for proofs that's technically necessary to allow the preconditions to "percolate up", which has the same effect of moving the if up. So the first advice is definitely not bike shedding, the second one I'm not so clear though ;)
- Tainnor 3y ago
  But the article wasn't about "validate inputs at the boundaries" (which is a semantic concern), it was about "push your ifs up" (which is a syntactic concern). I agree that in the provided example, those two seem to somewhat coincide (although it's hard to say, given that the author makes an effort to give their functions names such as "frobnicate" that don't indicate their purpose), but in the general case that doesn't have to be true.
  - mike_hock 3y ago
    Are we reading the same article? There is zero concern for syntax. The first point is literally what you said. Write functions with clear interfaces. If your function doesn't handle None, make its argument type reflect that (Walrus instead of Option<Walrus>). The second point is about performance. Hoist branches out of loops, and process batches so any constant cost is amortized over the batch. Is that even controversial? > the author makes an effort to give their functions names such as "frobnicate" Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example.
    - Tainnor 3y ago
      > Are we reading the same article? There is zero concern for syntax. By "syntactical" I mean "concerned with the surface level appearance of low-level code structure". > Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example. Only if you think that guidelines about how to write code should be devoid of the context of the problem you're trying to solve. I happen to think that this is mostly wrong.
      - mike_hock 3y ago
        Yes, I think it's possible to have discussions on an abstract level and not everything has to be a case study.
  - pjc50 3y ago
pjmlp 3y ago
To go along the same line of thought, too many think about the beatuy of the flower, instead of the whole florest. The amount of hours occasionally wasted discussing this in PR, that add zero value to what the customer actually cares, e.g. does pressing the button print or not their monthly invoice. Sure there is a balance to be had between completly unmaintainable code, and a piece of art to expose in the Louvre, however too many focus on the latter, instead of what is the customer getting out of their beautiful flower.
- valand 3y ago
  Often the people who overfocus on the beauty of the flower are those detached too far from the customers, too many indirections that hide failures and pressure
mpweiher 3y ago
> ... but not enough care about proper design of an entire codebase. One reason is that we don't have ways of meaningfully expressing components much larger than functions or that connect differently from functions in our programming languages. At most we can aggregate functions together. After that we're on our own.
teo_zero 3y ago
Poor choice of words in TFA and a cursory read by a reader generated this misunderstanding. "Up" means "to the caller" for the author, but was probably understood as "towards the beginning (of the function or file)".
- Woshiwuja 3y ago
  From the title i would have guessed "Use more ifs and less fors" and it didnt make sense at the beginning
- Tainnor 3y ago
  No, I did understand the point the author was making. I just think it's a weak one.
joelthelion 3y ago
> The more experience I get, the more I feel that too many programmers worry about making things pretty "in the small", but not enough care about proper design of an entire codebase. I've seen the reverse a lot, too. People who enjoy designing over-engineered cathedrals and can't be bothered to think about the low-level efficiency of their algorithms.
- maeln 3y ago
  In general, I feel like too many developer get caught up in dogma, "best-practices" that are effectively often unrealistic, and tend to adopt extremist way of thinking about the big and / or the small picture. A lot of the "dev culture" feel like it lacks a sense of pragmatism.
- antupis 3y ago
  I think this tells more about company culture than the people themselves, some companies like small things, and others like cathedrals.
- berkes 3y ago
  > People who enjoy designing over-engineered cathedrals and can't be bothered to think about the low-level efficiency of their algorithms. When that's deliberate, I'd say it's good. Quite often we need to optimize for maintenance. Or for high churn in developers. For readability. Adaptability. And so on. Each optimization is a trade-off. It's not always "performance vs readability", but quite often it is. If we spend time and effort on the low-level efficiency of algorithms, AND that comes at the cost of readability, adaptability, maintainability or any other -ility, we should very deliberate make a choice: does performance matter more than X. The answer is suprisingly often "no". And it's one of the many reasons why today's software is slow, bloated, battery-eating and unstable. Well, the times when that choice is not made deliberately are probably more to blame.
- Tainnor 3y ago
  "Over-engineered cathedrals" aren't what I mean by "good, proper design". I hate huge, messy meta-frameworks where everything happens implicitly and you can debug nothing. But I hate piles of ad-hoc code where everything calls everything and you can't change a single thing without breaking 2000 other things just as well. You usually don't need complicated code constructs to organise your code well - but you do need to think. Designing maintainable code is a difficult skill and one that involves careful thinking about tradeoffs. Unfortunately, mostly we as an industry never seem to be able to have time for it.
valand 3y ago
> but articles like this one are probably the things that can lead to the kind of unproductive bikeshedding that is sometimes experienced in PRs and other discussions I'd counterargue that if these trivial principles are established beforehand, unproductive bikeshedding of this type will happen less on PRs and other discussions. > as long as the function is properly named, has a good interface (including expressive types), a clear purpose, is properly documented, doesn't make excessive use of side effects etc. In performance-sensitive software where DOD thrives, more care needs to be put into these "in the small" things because that is how compiler optimization works. Then, it changes the rule of the game: statement semantics become crucial, self-documenting code makes more sense, in-code comments are for reasoning exclusively, and "documentation" becomes "specification and user manual".
t8sr 3y ago
I work in security, and get to interact with a lot of area tech lead and architect types (L7-L9 in FAANG terms). I have found that the people who most concern themselves with “proper design” are generally about 5-10 years into their career and trying to prevent juniors from shooting themselves in the foot, but don’t yet have a proper appreciation for the cost of complexity and how code changes over the long run. Conversely, after you’ve been doing this for 20+ years you learn to value simplicity over most other technical factors. Questions like “how early do we branch” and “what is the actual job this has to do” end up being the ones whose answers tend to have the most long-term value. Questions about abstractions and encapsulation tend to lead to the type of argument you describe. And the “the big picture” people are the ones with the most security issues in their code, because they don’t really understand what the properly architected codebase is really doing.
- Tainnor 3y ago
  > Questions like [...] “what is the actual job this has to do” end up being the ones whose answers tend to have the most long-term value. How is that not "big picture", proper design and abstraction/encapsulation? You seem to be arguing against a strawman. I didn't write "complexity". But if you want to fix security issues in your database access patterns, you better not have SQL distributed across your whole codebase.
  - t8sr 3y ago
    I don't think I am. You seem to disagree that things like where to branch are worth talking about, but you haven't given examples of what you mean by the big picture that is worth talking about. In this thread, you've told a few people they don't understand what you're saying - so what are you saying? Re: SQL. Maybe? Maybe not? It's a lot easier to do bad things to a database if you let an ORM generate the query. Writing SQL directly is not an anti-pattern, as long as you parametrize the query. But then again, maybe an ORM is not what you're suggesting - once again, you're saying what you don't like, and others are left to draw conclusions about what you think is good style.
    - 3y ago

kubb 3y ago

Programming language design also tends to focus on the small (e.g. optimizing the number of language keywords).

tangjurine 3y ago

Like there's the stuff that can be refactored because the changes are local, or the places to change are clear. And then the stuff that is a lot harder to refactor because you would need to change code in a lot of places, and the places that need to be changed aren't clear. That's probably more the proper design of a codebase stuff.

Leo_Germond 3y ago

The advice about if up is not bikeshedding though, it is the exact kind of architectural choice you're saying one should decide on. Don't believe me ? Well imagine you have inputs, where should you validate them ? According to this rule of thumb it's at the topmost level, when they are received. Well that seems super sensible, and it's typically something that helps with understanding the code (rather than checking them at thw very last moment). Also for proofs that's technically necessary to allow the preconditions to "percolate up", which has the same effect of moving the if up. So the first advice is definitely not bike shedding, the second one I'm not so clear though ;)

Tainnor 3y ago
But the article wasn't about "validate inputs at the boundaries" (which is a semantic concern), it was about "push your ifs up" (which is a syntactic concern). I agree that in the provided example, those two seem to somewhat coincide (although it's hard to say, given that the author makes an effort to give their functions names such as "frobnicate" that don't indicate their purpose), but in the general case that doesn't have to be true.
- mike_hock 3y ago
  Are we reading the same article? There is zero concern for syntax. The first point is literally what you said. Write functions with clear interfaces. If your function doesn't handle None, make its argument type reflect that (Walrus instead of Option<Walrus>). The second point is about performance. Hoist branches out of loops, and process batches so any constant cost is amortized over the batch. Is that even controversial? > the author makes an effort to give their functions names such as "frobnicate" Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example.
  - Tainnor 3y ago
    > Are we reading the same article? There is zero concern for syntax. By "syntactical" I mean "concerned with the surface level appearance of low-level code structure". > Yes, and that's good, because it keeps the focus on his actual points rather than the minutiae of a contrived example. Only if you think that guidelines about how to write code should be devoid of the context of the problem you're trying to solve. I happen to think that this is mostly wrong.
    - mike_hock 3y ago
      Yes, I think it's possible to have discussions on an abstract level and not everything has to be a case study.
- pjc50 3y ago

pjmlp 3y ago

To go along the same line of thought, too many think about the beatuy of the flower, instead of the whole florest. The amount of hours occasionally wasted discussing this in PR, that add zero value to what the customer actually cares, e.g. does pressing the button print or not their monthly invoice. Sure there is a balance to be had between completly unmaintainable code, and a piece of art to expose in the Louvre, however too many focus on the latter, instead of what is the customer getting out of their beautiful flower.

valand 3y ago
Often the people who overfocus on the beauty of the flower are those detached too far from the customers, too many indirections that hide failures and pressure

mpweiher 3y ago

> ... but not enough care about proper design of an entire codebase. One reason is that we don't have ways of meaningfully expressing components much larger than functions or that connect differently from functions in our programming languages. At most we can aggregate functions together. After that we're on our own.

teo_zero 3y ago

Poor choice of words in TFA and a cursory read by a reader generated this misunderstanding. "Up" means "to the caller" for the author, but was probably understood as "towards the beginning (of the function or file)".

Woshiwuja 3y ago
From the title i would have guessed "Use more ifs and less fors" and it didnt make sense at the beginning
Tainnor 3y ago
No, I did understand the point the author was making. I just think it's a weak one.

joelthelion 3y ago

> The more experience I get, the more I feel that too many programmers worry about making things pretty "in the small", but not enough care about proper design of an entire codebase. I've seen the reverse a lot, too. People who enjoy designing over-engineered cathedrals and can't be bothered to think about the low-level efficiency of their algorithms.

maeln 3y ago
In general, I feel like too many developer get caught up in dogma, "best-practices" that are effectively often unrealistic, and tend to adopt extremist way of thinking about the big and / or the small picture. A lot of the "dev culture" feel like it lacks a sense of pragmatism.
antupis 3y ago
I think this tells more about company culture than the people themselves, some companies like small things, and others like cathedrals.
berkes 3y ago
> People who enjoy designing over-engineered cathedrals and can't be bothered to think about the low-level efficiency of their algorithms. When that's deliberate, I'd say it's good. Quite often we need to optimize for maintenance. Or for high churn in developers. For readability. Adaptability. And so on. Each optimization is a trade-off. It's not always "performance vs readability", but quite often it is. If we spend time and effort on the low-level efficiency of algorithms, AND that comes at the cost of readability, adaptability, maintainability or any other -ility, we should very deliberate make a choice: does performance matter more than X. The answer is suprisingly often "no". And it's one of the many reasons why today's software is slow, bloated, battery-eating and unstable. Well, the times when that choice is not made deliberately are probably more to blame.
Tainnor 3y ago
"Over-engineered cathedrals" aren't what I mean by "good, proper design". I hate huge, messy meta-frameworks where everything happens implicitly and you can debug nothing. But I hate piles of ad-hoc code where everything calls everything and you can't change a single thing without breaking 2000 other things just as well. You usually don't need complicated code constructs to organise your code well - but you do need to think. Designing maintainable code is a difficult skill and one that involves careful thinking about tradeoffs. Unfortunately, mostly we as an industry never seem to be able to have time for it.

valand 3y ago

> but articles like this one are probably the things that can lead to the kind of unproductive bikeshedding that is sometimes experienced in PRs and other discussions I'd counterargue that if these trivial principles are established beforehand, unproductive bikeshedding of this type will happen less on PRs and other discussions. > as long as the function is properly named, has a good interface (including expressive types), a clear purpose, is properly documented, doesn't make excessive use of side effects etc. In performance-sensitive software where DOD thrives, more care needs to be put into these "in the small" things because that is how compiler optimization works. Then, it changes the rule of the game: statement semantics become crucial, self-documenting code makes more sense, in-code comments are for reasoning exclusively, and "documentation" becomes "specification and user manual".

t8sr 3y ago

I work in security, and get to interact with a lot of area tech lead and architect types (L7-L9 in FAANG terms). I have found that the people who most concern themselves with “proper design” are generally about 5-10 years into their career and trying to prevent juniors from shooting themselves in the foot, but don’t yet have a proper appreciation for the cost of complexity and how code changes over the long run. Conversely, after you’ve been doing this for 20+ years you learn to value simplicity over most other technical factors. Questions like “how early do we branch” and “what is the actual job this has to do” end up being the ones whose answers tend to have the most long-term value. Questions about abstractions and encapsulation tend to lead to the type of argument you describe. And the “the big picture” people are the ones with the most security issues in their code, because they don’t really understand what the properly architected codebase is really doing.

Tainnor 3y ago
> Questions like [...] “what is the actual job this has to do” end up being the ones whose answers tend to have the most long-term value. How is that not "big picture", proper design and abstraction/encapsulation? You seem to be arguing against a strawman. I didn't write "complexity". But if you want to fix security issues in your database access patterns, you better not have SQL distributed across your whole codebase.
- t8sr 3y ago
  I don't think I am. You seem to disagree that things like where to branch are worth talking about, but you haven't given examples of what you mean by the big picture that is worth talking about. In this thread, you've told a few people they don't understand what you're saying - so what are you saying? Re: SQL. Maybe? Maybe not? It's a lot easier to do bad things to a database if you let an ORM generate the query. Writing SQL directly is not an anti-pattern, as long as you parametrize the query. But then again, maybe an ORM is not what you're suggesting - once again, you're saying what you don't like, and others are left to draw conclusions about what you think is good style.
  - 3y ago