3 ms·

I'm a fan of using the least number of language features to get the job done. If a language is simple and can be stepped through easily, one benefits from the r

I'm a fan of using the least number of language features to get the job done. If a language is simple and can be stepped through easily, one benefits from the removal of the added cognitive load of knowing a large number of language features. This provides extra brainspace to understand the problem space and the system one is working on. Most importantly, it makes it easier to have the whole shebang in your mind while you add code (correctly.) And it adds to maintainability (so long as done in a balanced way!) I had a boss who saw me looking out a window say, "You look like you are concentrating. I'll come back later." I document EVERYTHING I think straight away into their appropriate documents so I can forget about it while I'm loading as much of a system's design into my head as I can. It allows me to write good code during that small window of available zen. After years of doing that, I made a document about documentation. Hope it's of use. https://pcblues.com/assets/approaching_software_projects.pdf https://pcblues.com/assets/approaching_software_projects.pdf

pcblues 2y ago
Also, it's important that you make your own templates for each of the document types, because thinking about them is part of the design process. It reduces the cognitive load of understanding yet another set of design document templates, and they are malleable in your own hands :)
at_a_remove 2y ago
I agree and will add in a few bits: although I will obey the language's idiom, in general, I like to keep the number of "things it does" per line of code to the minimum. Kind of an anti-code golf. I also document (or comment code) when I am waiting for the flow to kick in. For me, the documentation starts at the appendices. One for input files or api source tricks or describing the input tables in a database. Another for the relevant outputs. Maybe a "justify overall design decisions" section. Just stuff someone would wish if they had to handle it in five years.
- pcblues 2y ago
  I wonder why people boast they can do ten things in one line. Less lines of code doesn't mean less bugs. The debugger just stops at each symbol instead of each line which I think adds to the cognitive load. Documenting while waiting for the flow is like stretching before exercise. It gets you to that place :) I got my experience/slaps by fixing my own code in the same codebase for more than ten years. I have empathy for the future maintainers :)
  - at_a_remove 2y ago
    I have passed on at least a few codebases. Sometimes, people get bright ideas and just dump what's working to do greenfield stuff. This is why an ex-coworker recently wanted me to come back to braindump on something I finished in 2009. After I left, some bright spark wanted to start from scratch and now there are continual complaints when the previous thing just worked, aside from a per-semester update, which the software would nag you about, as new departments appeared and such. On the other hand, I had an apartment-renting suite I had written get passed on to students. While it was written in Perl (a famously "write once, read never" language according to critics), because I did just one thing per line and had comments at multiple levels (a block header for each function, comments within functions, a changelog at the top), they called back and said it was the easiest thing in the world for them to convert it, despite not knowing Perl at all. Although I had been programming for years and years by the time I took a FORTRAN course in high school, I had a particularly exacting teacher with a Ph.D. in Computer Science and he drilled us on how we would have to deal with the code of others, or our old code, or code when we did not want to come into work with a cold. Cleverness is held in reserve for data structures and algorithms, when you have no other options. He was very firm on that.
userbinator 2y ago
I'm a fan of using the least number of language features to get the job done. Some people seem to love doing the opposite, which IMHO is the biggest problem with the software industry --- there's a huge number of developers who think that the more complex (or in their words, "structured") software is, and the more latest language features it has, is somehow better than the simple "deprecated" stuff that's been working for decades. I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side.
- namaria 2y ago
  Funny thing is, humans have a huge bias towards traditions that seems to have reversed in the last century or so. My take is that consumerism did a number on our psyche.
- whilenot-dev 2y ago
  > I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side. What are your thoughts on aync/await then (available in Python/JavaScript etc.)?
  - normie3000 2y ago
    > What are your thoughts on aync/await then (available in Python/JavaScript etc.)? Not the OP, but I find it hard to have an absolute opinion on this - IMO some recent additions to javascript significantly decrease cognitive load. async/await is a great example of this (vs then/catch/finally chains), and also: * spreading of arrays, props, and more arguably args * shortcutting prop/value pairs, e.g. { x:x } as { x } Some stuff it seems are more confusing, e.g. * similar but subtly different things like for/of vs for/in vs forEach vs iterating Object.keys(), Object.values(), Object.entries() * what are generators and the yield keyword for?
    - whilenot-dev 2y ago
Tainnor 2y ago
> If a language is simple and can be stepped through easily, one benefits from the removal of the added cognitive load of knowing a large number of language features. Things that you know and have internalised don't occupy your brainspace. That's why you can read this paragraph without having to think about every word individually.
- qw 2y ago
  > Things that you know and have internalised don't occupy your brainspace Some "10x" developers are extremely productive because they know the software stack inside and out. There are also "10x" teams where they share an institutional knowledge of the software stack and are constantly improving and finding more efficient ways of solving a problem. When someone finds a better library, more efficient CI/CD or establish new code practices it is easy to apply it when they have a single stack to focus on. It's hard to replicate this in teams where they are responsible for 10 micro services, each written in their own language and using different software stacks that are more "optimal" for some use case.
  - Tainnor 2y ago
    I agree. The constant push for constantly solving 100 problems with 50 poorly understood technologies instead of doing a couple of things and understanding them really well sometimes really makes me hate modern software development.

pcblues 2y ago

Also, it's important that you make your own templates for each of the document types, because thinking about them is part of the design process. It reduces the cognitive load of understanding yet another set of design document templates, and they are malleable in your own hands :)

at_a_remove 2y ago

I agree and will add in a few bits: although I will obey the language's idiom, in general, I like to keep the number of "things it does" per line of code to the minimum. Kind of an anti-code golf. I also document (or comment code) when I am waiting for the flow to kick in. For me, the documentation starts at the appendices. One for input files or api source tricks or describing the input tables in a database. Another for the relevant outputs. Maybe a "justify overall design decisions" section. Just stuff someone would wish if they had to handle it in five years.

pcblues 2y ago
I wonder why people boast they can do ten things in one line. Less lines of code doesn't mean less bugs. The debugger just stops at each symbol instead of each line which I think adds to the cognitive load. Documenting while waiting for the flow is like stretching before exercise. It gets you to that place :) I got my experience/slaps by fixing my own code in the same codebase for more than ten years. I have empathy for the future maintainers :)
- at_a_remove 2y ago
  I have passed on at least a few codebases. Sometimes, people get bright ideas and just dump what's working to do greenfield stuff. This is why an ex-coworker recently wanted me to come back to braindump on something I finished in 2009. After I left, some bright spark wanted to start from scratch and now there are continual complaints when the previous thing just worked, aside from a per-semester update, which the software would nag you about, as new departments appeared and such. On the other hand, I had an apartment-renting suite I had written get passed on to students. While it was written in Perl (a famously "write once, read never" language according to critics), because I did just one thing per line and had comments at multiple levels (a block header for each function, comments within functions, a changelog at the top), they called back and said it was the easiest thing in the world for them to convert it, despite not knowing Perl at all. Although I had been programming for years and years by the time I took a FORTRAN course in high school, I had a particularly exacting teacher with a Ph.D. in Computer Science and he drilled us on how we would have to deal with the code of others, or our old code, or code when we did not want to come into work with a cold. Cleverness is held in reserve for data structures and algorithms, when you have no other options. He was very firm on that.

userbinator 2y ago

I'm a fan of using the least number of language features to get the job done. Some people seem to love doing the opposite, which IMHO is the biggest problem with the software industry --- there's a huge number of developers who think that the more complex (or in their words, "structured") software is, and the more latest language features it has, is somehow better than the simple "deprecated" stuff that's been working for decades. I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side.

namaria 2y ago
Funny thing is, humans have a huge bias towards traditions that seems to have reversed in the last century or so. My take is that consumerism did a number on our psyche.
whilenot-dev 2y ago
> I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side. What are your thoughts on aync/await then (available in Python/JavaScript etc.)?
- normie3000 2y ago
  > What are your thoughts on aync/await then (available in Python/JavaScript etc.)? Not the OP, but I find it hard to have an absolute opinion on this - IMO some recent additions to javascript significantly decrease cognitive load. async/await is a great example of this (vs then/catch/finally chains), and also: * spreading of arrays, props, and more arguably args * shortcutting prop/value pairs, e.g. { x:x } as { x } Some stuff it seems are more confusing, e.g. * similar but subtly different things like for/of vs for/in vs forEach vs iterating Object.keys(), Object.values(), Object.entries() * what are generators and the yield keyword for?
  - whilenot-dev 2y ago

Tainnor 2y ago

> If a language is simple and can be stepped through easily, one benefits from the removal of the added cognitive load of knowing a large number of language features. Things that you know and have internalised don't occupy your brainspace. That's why you can read this paragraph without having to think about every word individually.

qw 2y ago
> Things that you know and have internalised don't occupy your brainspace Some "10x" developers are extremely productive because they know the software stack inside and out. There are also "10x" teams where they share an institutional knowledge of the software stack and are constantly improving and finding more efficient ways of solving a problem. When someone finds a better library, more efficient CI/CD or establish new code practices it is easy to apply it when they have a single stack to focus on. It's hard to replicate this in teams where they are responsible for 10 micro services, each written in their own language and using different software stacks that are more "optimal" for some use case.
- Tainnor 2y ago
  I agree. The constant push for constantly solving 100 problems with 50 poorly understood technologies instead of doing a couple of things and understanding them really well sometimes really makes me hate modern software development.