4 ms·

> The biggest lesson so far is that code is very dense. A half hour presentation is just enough time to present maybe a dozen meaty lines of code and one main i

> The biggest lesson so far is that code is very dense. A half hour presentation is just enough time to present maybe a dozen meaty lines of code and one main idea. It is also almost certainly the case that the presenters, who have to actually really dig down into a piece of code, get more out of it than anybody. But it does seem that a good presentation can at least expose people to the main ideas and maybe give them a head start if they do decide to read the code themselves. Which exposes the disconnect: A computer program is not about expressing an idea; it's about doing a thing. It's a very specific set of instructions that explain how to do a thing; often having to handle corner cases that a human would not need explained to them.

ilrwbwrkhv 3y ago
100%. A lot of new programmers who didn't program back in the day have been used to this idea with abstractions and "clean code" and that causes so much issues these days. Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible. A computer program is an instruction set as you rightly said. It is not a long winded story with many "nouns" (objects).
- mochaki 3y ago
  [dead]
- pixl97 3y ago
  >t I am trying and how can I make that happen with the fewest lines of instructions as possible Isn't that the compilers job?
  - gwbas1c 3y ago
    The compiler doesn't know how to reduce three database round trips into one database round trip. Modern compilers are awesome, but they still can't read your mind to understand your intent and suggest changes that would objectively change the program, but do what your intent is in a much better way. Perhaps someday artificial intelligence could, but I think that is a long ways off.
  - ilrwbwrkhv 3y ago
    The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code.
    - chefandy 3y ago
      > The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code. Human-readable is a spectrum. If something can be more human-friendly while being compacted into an equivalent instruction set at compile time, then what is the benefit of writing extremely terse code?
      - ilrwbwrkhv 3y ago
        Less maintenance the fewer lines of code. While it shouldn't be unreadable, it should be succinct. Basically using abstractions sparingly, letting the data flow through the system and not wrapping things within each other are all great ideas. If you are instantiating a bunch of objects, you can simplify things.
        chefandy 3y ago
        Maybe there are domains/languages/paradigms where using the smallest possible number of lines to achieve a given compiled instruction set really makes things more efficient, but to me it sounds more like code golf. Using 1 very terse line to accomplish the same thing that 3 readable lines can accomplish should require the same exact amount of maintenance but would be much harder to read and modify.
- scubbo 3y ago
  > Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible This is true for performance-critical code which will be written once and never modified or reviewed. For "living" code - code in a system which will be updated and extended as it is operating - it is crucial to at least pay attention to the human-readability of your code, in order to improve the efficiency of the future developers. Both extremes of the "inscrutable optimization" and "prolix verbosity" spectrum are incorrect - the correct midpoint is a judgement call.
  - blindhippo 3y ago
    It's often debated but in my mind, you know you're talking to a "senior" dev when nearly every response they have to a question is "well, it depends..." Every software project is different since software is a physical manifestation and codification of human process. And human process is... messy as all hell and doesn't like to be constrained by a lot of rules no matter how much effort and management goes into things. So, I prefer to advise teams build software that can be replaced easily, however that works. Isolate the points of change, make the system components replaceable (because they will be), but keep mind of where things need to be focused on efficiency and less on abstraction. This applies to a single code file all the way up to large scale distributed systems. In larger orgs, this helps since inevitably we all fall into the trap of Conway's law, and re-orgs inevitably lead to refactoring of systems along new ownership/communication lines. So, the right way to do something will always conform to the unique situations in which a system is developed -- "it depends"/
    - agentultra 3y ago
      I think abstraction is key to efficiency. In order to have efficient systems we need to be able to prove properties of the software we write are correct with regards to our specifications. This is what abstractions do for us: they enable us to think in new semantic layers that are precise in the mathematical sense. This isn’t my idea, I just agree wholeheartedly with Conal Eliot. Resiliency is what we get when we want reliable systems but we cut corners with proving the correctness of the software we write: we add process supervisors, memory managers, tooling, exception handlers, etc: things that all cost us some efficiency in order to make our systems reliable enough to be useful. If we want efficiency, at scale, we need tools (languages really) that allow us to write proofs and generate code from these specifications.
chrisjj 3y ago
> A computer program is not about expressing an idea; I firmly believe anyone holding this view needs to get out more. Start here: www.shadertoy.com > it's about doing a thing. That's just one kind.
anononaut 3y ago
I agree with you to some degree, but it needs to be said that _good_ code is very expressive. It should reveal the developer's intent clearly. "Doing a thing" is fine for amateurs or a quick script, but for large enterprise application development, it doesn't go nearly far enough. Good names, good function arrangement, plus everything else we should be studying needs to be applied well. If done well, it certainly should not take a half hour presentation to present a dozen lines of code. That tells me that the code is too complicated, too dense, too many levels of abstraction together, too much I have to keep in mind to understand some main idea. Very dense code is, more often than not, bad code. I don't think reading codebases is an exercise worth doing often, but all the same good code should read like well written prose. It's difficult to appreciate that if an individual hasn't poked through a number of codebases of varying quality.
- gwbas1c 3y ago
  Lots of good responses here. One thing I'd like to point out: In my prior job I joined early enough that I was able to keep the codebase very readable. As the team grew, I started running "office hours" to help allow newcomers to onboard. We were a globally distributed team, so it was hard to have the casual interruptions that happen when most of the team is in the same place at the same time. In my current job I inherited a very crufty codebase, and I've spent a lot of time improving readability. Working with .editorconfig helped; and that initiative took ~1 month! There are a lot of habits that can be learned by reading code; but mostly the reading is to look at style instead of function or "ideas." One example of a good habit: My prior role involved a file synchronization product. We followed a naming convention whenever an object represented a file or directory. Merely naming a variable "file" or "directory" would be very confusing, because it lost a lot of context: Is "file" the entry in the SQLite database? Is it the in-memory type that we used to communicate known state about the file? Is it an object that's used to get things about the file from the file system, like last time accessed? But, and this is where code != literature: The file synchronization product wasn't an "idea." The program was a very detailed set of instructions on how to synchronize files. It handled all the corner cases, because the computer has no ability to make assumptions when it follows these instructions.
- ragona 3y ago
bdowling 3y ago
＞ A computer program is not about expressing an idea; it’s about doing a thing. A computer program expresses the idea that a computer will do the thing described in the way described.

ilrwbwrkhv 3y ago

100%. A lot of new programmers who didn't program back in the day have been used to this idea with abstractions and "clean code" and that causes so much issues these days. Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible. A computer program is an instruction set as you rightly said. It is not a long winded story with many "nouns" (objects).

mochaki 3y ago
[dead]
pixl97 3y ago
>t I am trying and how can I make that happen with the fewest lines of instructions as possible Isn't that the compilers job?
- gwbas1c 3y ago
  The compiler doesn't know how to reduce three database round trips into one database round trip. Modern compilers are awesome, but they still can't read your mind to understand your intent and suggest changes that would objectively change the program, but do what your intent is in a much better way. Perhaps someday artificial intelligence could, but I think that is a long ways off.
- ilrwbwrkhv 3y ago
  The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code.
  - chefandy 3y ago
    > The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code. Human-readable is a spectrum. If something can be more human-friendly while being compacted into an equivalent instruction set at compile time, then what is the benefit of writing extremely terse code?
    - ilrwbwrkhv 3y ago
      Less maintenance the fewer lines of code. While it shouldn't be unreadable, it should be succinct. Basically using abstractions sparingly, letting the data flow through the system and not wrapping things within each other are all great ideas. If you are instantiating a bunch of objects, you can simplify things.
      - chefandy 3y ago
        Maybe there are domains/languages/paradigms where using the smallest possible number of lines to achieve a given compiled instruction set really makes things more efficient, but to me it sounds more like code golf. Using 1 very terse line to accomplish the same thing that 3 readable lines can accomplish should require the same exact amount of maintenance but would be much harder to read and modify.
scubbo 3y ago
> Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible This is true for performance-critical code which will be written once and never modified or reviewed. For "living" code - code in a system which will be updated and extended as it is operating - it is crucial to at least pay attention to the human-readability of your code, in order to improve the efficiency of the future developers. Both extremes of the "inscrutable optimization" and "prolix verbosity" spectrum are incorrect - the correct midpoint is a judgement call.
- blindhippo 3y ago
  It's often debated but in my mind, you know you're talking to a "senior" dev when nearly every response they have to a question is "well, it depends..." Every software project is different since software is a physical manifestation and codification of human process. And human process is... messy as all hell and doesn't like to be constrained by a lot of rules no matter how much effort and management goes into things. So, I prefer to advise teams build software that can be replaced easily, however that works. Isolate the points of change, make the system components replaceable (because they will be), but keep mind of where things need to be focused on efficiency and less on abstraction. This applies to a single code file all the way up to large scale distributed systems. In larger orgs, this helps since inevitably we all fall into the trap of Conway's law, and re-orgs inevitably lead to refactoring of systems along new ownership/communication lines. So, the right way to do something will always conform to the unique situations in which a system is developed -- "it depends"/
  - agentultra 3y ago
    I think abstraction is key to efficiency. In order to have efficient systems we need to be able to prove properties of the software we write are correct with regards to our specifications. This is what abstractions do for us: they enable us to think in new semantic layers that are precise in the mathematical sense. This isn’t my idea, I just agree wholeheartedly with Conal Eliot. Resiliency is what we get when we want reliable systems but we cut corners with proving the correctness of the software we write: we add process supervisors, memory managers, tooling, exception handlers, etc: things that all cost us some efficiency in order to make our systems reliable enough to be useful. If we want efficiency, at scale, we need tools (languages really) that allow us to write proofs and generate code from these specifications.

chrisjj 3y ago

> A computer program is not about expressing an idea; I firmly believe anyone holding this view needs to get out more. Start here: www.shadertoy.com > it's about doing a thing. That's just one kind.

anononaut 3y ago

I agree with you to some degree, but it needs to be said that _good_ code is very expressive. It should reveal the developer's intent clearly. "Doing a thing" is fine for amateurs or a quick script, but for large enterprise application development, it doesn't go nearly far enough. Good names, good function arrangement, plus everything else we should be studying needs to be applied well. If done well, it certainly should not take a half hour presentation to present a dozen lines of code. That tells me that the code is too complicated, too dense, too many levels of abstraction together, too much I have to keep in mind to understand some main idea. Very dense code is, more often than not, bad code. I don't think reading codebases is an exercise worth doing often, but all the same good code should read like well written prose. It's difficult to appreciate that if an individual hasn't poked through a number of codebases of varying quality.

gwbas1c 3y ago
Lots of good responses here. One thing I'd like to point out: In my prior job I joined early enough that I was able to keep the codebase very readable. As the team grew, I started running "office hours" to help allow newcomers to onboard. We were a globally distributed team, so it was hard to have the casual interruptions that happen when most of the team is in the same place at the same time. In my current job I inherited a very crufty codebase, and I've spent a lot of time improving readability. Working with .editorconfig helped; and that initiative took ~1 month! There are a lot of habits that can be learned by reading code; but mostly the reading is to look at style instead of function or "ideas." One example of a good habit: My prior role involved a file synchronization product. We followed a naming convention whenever an object represented a file or directory. Merely naming a variable "file" or "directory" would be very confusing, because it lost a lot of context: Is "file" the entry in the SQLite database? Is it the in-memory type that we used to communicate known state about the file? Is it an object that's used to get things about the file from the file system, like last time accessed? But, and this is where code != literature: The file synchronization product wasn't an "idea." The program was a very detailed set of instructions on how to synchronize files. It handled all the corner cases, because the computer has no ability to make assumptions when it follows these instructions.
ragona 3y ago

bdowling 3y ago

＞ A computer program is not about expressing an idea; it’s about doing a thing. A computer program expresses the idea that a computer will do the thing described in the way described.