5 ms·

the last three entries are great and need to be drilled into folks head. too much of CS training (and leet-code driven interviewing) encourages people to get cl

the last three entries are great and need to be drilled into folks head. too much of CS training (and leet-code driven interviewing) encourages people to get clever. but reading somebody elses clever code sucks. write code that's meant to be easily read and understood. that's not just about algorithms and code comments -- variables/functions named descriptively, formatting is consistent, things don't get too nested, design things to be modular in a way that lets you ignore irrelevant sources of complexity, etc

zikzak 2y ago
Kernighan's Law - Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
- bilekas 2y ago
  I feel as an outlier to this I need to make a comment.. Debugging (with source) to me at least, it’s so much more easier as you have all of the stack with you along the chain.. It’s very rare, not impossible though, to find crazy behavior during correct debugging.. This law is new to me though.
  - geewee 2y ago
    I think it depends on how thorny the thing you need to debug is. Race conditions, intermittent bugs that crash the process leaving no trace, etc. Debugging is much more than using a debugger
    - parpfish 2y ago
      I like to differentiate between “bugs that stem from a recent code change” (easy to fix) and “bugs that suddenly appear out of nowhere” (hard to fix)
- marcosdumay 2y ago
  That, of course, is only valid if you are using your cleverness to optimize for something that isn't readability.
  - immibis 2y ago
    A lot of clever code thinks it's optimizing for readability when it's really optimizing for the feeling of cleverness itself.
- cies 2y ago
  "Do not write today, that what you cannot debug tomorrow."
LegionMammal978 2y ago
I'd be a bit wary of taking 'simplicity' as a goal. Some people read that and think to write shorter, cleverer code instead of longer, more straightforward code which might have a few redundancies. (E.g., people often praise FP languages and Lisp-like languages for their very flexible control flow, but adding custom abstractions can result in shorter code that is difficult for newcomers to understand.) On the other hand, too much modularity and factored-out code can also obscure the behavior of a program, even if each module has a well-defined role and satisfies its interface. (E.g., big Java programs can have hundreds of classes with small method bodies and lots of calls to other classes and interfaces. If you see an interface call, but the object came from somewhere several classes away, then good luck figuring out which implementation gets called.) I'd say that the ultimate moral is "Keep the flow of logic and data relatively linear (or at least, no more complex than it needs to be to solve the problem). Avoid dicing it up between a dozen different spots, or performing crazy stunts with it, so that only an expert can understand what's going on. And just because some logical constructs (like dynamic dispatch) are unwritten doesn't mean they don't create mental load."
- bilekas 2y ago
  > but adding custom abstractions can result in shorter code that is difficult for newcomers to understand I’ve worked at places where the lead would abstract everythiNg possible, it made tracing the flow not just difficult but almost intentionally obfuscated. When calling him up on it he would sing the principles and say it’s the source of robust code. I’m sure out 100 customers appreciated that. I do appreciate your comment on keeping the flow right, I would add to that I guess by making sure your domains and boundaries are well established and respected.. mistakes will always happen, but if they’re “gated” by domains, the person who fixes it will definitely buy you a beer/coffee.
- winwang 2y ago
  I think it's fine if code is difficult for newcomers to understand (of course, to a point). Most programmers are taught in C-like languages and paradigms. Using FP (ML-like) languages is already "difficult to understand". The question then becomes: how large is the disconnect between the "theory" in the mind of the newcomer(s) vs. the "theory" they need to be useful in the codebase -- and is this gap worth it? For example, programming with explicit effects (i.e. `IO`) or even just type-safe Futures. There's not too much difficulty with simply getting started, and it builds up a general theory of effects in the newcomer, which would presumably be useful in many contexts of the codebase even outside of async effects, e.g. error-handling with `Either`.
bilekas 2y ago
A great rule of thumb I found useful while learning under great tutorship (way back when) was, look at your check-in, (svn at the time) if you think you will remember it in 5 months in less than 15 mins then it’s okay.. But still have someone put eyes on it before clicking. SVN made us careful maybe..
boogieknite 2y ago
i inherited spaghetti code written by a geography phd and some fresh out of coding boot camp flunkies. i really enjoy finding "clever" code, even code they only think is clever. its entertaining! might as well be entertained at work. if its legit clever code, just add a link to the source for the theory behind it and that's enough for me

zikzak 2y ago

Kernighan's Law - Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

bilekas 2y ago
I feel as an outlier to this I need to make a comment.. Debugging (with source) to me at least, it’s so much more easier as you have all of the stack with you along the chain.. It’s very rare, not impossible though, to find crazy behavior during correct debugging.. This law is new to me though.
- geewee 2y ago
  I think it depends on how thorny the thing you need to debug is. Race conditions, intermittent bugs that crash the process leaving no trace, etc. Debugging is much more than using a debugger
  - parpfish 2y ago
    I like to differentiate between “bugs that stem from a recent code change” (easy to fix) and “bugs that suddenly appear out of nowhere” (hard to fix)
marcosdumay 2y ago
That, of course, is only valid if you are using your cleverness to optimize for something that isn't readability.
- immibis 2y ago
  A lot of clever code thinks it's optimizing for readability when it's really optimizing for the feeling of cleverness itself.
cies 2y ago
"Do not write today, that what you cannot debug tomorrow."

LegionMammal978 2y ago

I'd be a bit wary of taking 'simplicity' as a goal. Some people read that and think to write shorter, cleverer code instead of longer, more straightforward code which might have a few redundancies. (E.g., people often praise FP languages and Lisp-like languages for their very flexible control flow, but adding custom abstractions can result in shorter code that is difficult for newcomers to understand.) On the other hand, too much modularity and factored-out code can also obscure the behavior of a program, even if each module has a well-defined role and satisfies its interface. (E.g., big Java programs can have hundreds of classes with small method bodies and lots of calls to other classes and interfaces. If you see an interface call, but the object came from somewhere several classes away, then good luck figuring out which implementation gets called.) I'd say that the ultimate moral is "Keep the flow of logic and data relatively linear (or at least, no more complex than it needs to be to solve the problem). Avoid dicing it up between a dozen different spots, or performing crazy stunts with it, so that only an expert can understand what's going on. And just because some logical constructs (like dynamic dispatch) are unwritten doesn't mean they don't create mental load."

bilekas 2y ago
> but adding custom abstractions can result in shorter code that is difficult for newcomers to understand I’ve worked at places where the lead would abstract everythiNg possible, it made tracing the flow not just difficult but almost intentionally obfuscated. When calling him up on it he would sing the principles and say it’s the source of robust code. I’m sure out 100 customers appreciated that. I do appreciate your comment on keeping the flow right, I would add to that I guess by making sure your domains and boundaries are well established and respected.. mistakes will always happen, but if they’re “gated” by domains, the person who fixes it will definitely buy you a beer/coffee.
winwang 2y ago
I think it's fine if code is difficult for newcomers to understand (of course, to a point). Most programmers are taught in C-like languages and paradigms. Using FP (ML-like) languages is already "difficult to understand". The question then becomes: how large is the disconnect between the "theory" in the mind of the newcomer(s) vs. the "theory" they need to be useful in the codebase -- and is this gap worth it? For example, programming with explicit effects (i.e. `IO`) or even just type-safe Futures. There's not too much difficulty with simply getting started, and it builds up a general theory of effects in the newcomer, which would presumably be useful in many contexts of the codebase even outside of async effects, e.g. error-handling with `Either`.

bilekas 2y ago

A great rule of thumb I found useful while learning under great tutorship (way back when) was, look at your check-in, (svn at the time) if you think you will remember it in 5 months in less than 15 mins then it’s okay.. But still have someone put eyes on it before clicking. SVN made us careful maybe..

boogieknite 2y ago

i inherited spaghetti code written by a geography phd and some fresh out of coding boot camp flunkies. i really enjoy finding "clever" code, even code they only think is clever. its entertaining! might as well be entertained at work. if its legit clever code, just add a link to the source for the theory behind it and that's enough for me