
The 80/24 Rule - nreece
https://blog.ploeh.dk/2019/11/04/the-80-24-rule/
======
alkonaut
I have started to move in the other direction for C#. A long sequence of code
that flows in one direction should be kept in one method if possible. Good
reasons to break up a method are things that are _not_ readability but other
things such as re-use testability. If the methods are only called in one place
and not performing a piece of work that is testable, then they shouldn’t be
methods.

But

    
    
       DoAll() {
         DoA();
         DoB();
         DoC();
       }
    

Is simply not better in any way than

    
    
        DoAll() {
          // A
          ...
          // B
          ...
          // C
          ...
        }
    

Private methods will blur this somewhat. The key to readability is not having
to jump around. Ideally of course methods are both short _and_ reusable,
readable without jumping etc, but given the choice between a 100 line method
or the same code broken into 10 methods of 15 lines each (yes, more lines),
where each method is only called once from a main method, I’d rather read the
first. The 100 lines might indicate some _other_ problem with the api (a
chatty Dx12/win32-like API for example).

This obviously varies from case to case, I think one of the worse things a
team can do is enforce hard rules that invariably lead to “style rule-induced
damage”.

~~~
dgb23
I very much disagree. The in-lined version can easily be confusing, harder to
change, harder to test and even error prone.

By splitting code into functions you have a more well defined scope for each
of them and they can be understood in isolation.

You also get the benefit of getting a quicker overview (if you care to name
your functions well) in your calling function (DoAll).

Then there is the issue of maintainability. When I have to change something in
a big (in-lined) function then I'm much more anxious about the whole context.
My instinct is often to refactor it into smaller pieces so I can narrow down
the changes and isolate them correctly and exactly from the context.

This might very well be a thing of preference?

~~~
horsawlarway
I suspect this is mostly preference.

Personally, I really dislike pulling everything out into small methods - it
literally forces you to remember a crap load of names. I find remembering
names to be extremely high cognitive load.

Worse, the names WILL lie to you. Especially if you weren't the one doing the
naming.

So not only are you forced to remember a bunch of labels that better fit
someone else's mental model, you're still not off the hook for understanding
what the code in those tiny methods is doing, and considering how it might
impact the task at hand.

So now you're stuck with twice the work - Remembering which name goes with
which functional piece of the task at hand, and then remembering how that name
actually accomplishes the task (the actual code).

Worse, because functions are moved out of line, I find it much harder to jump
between relevant bits of actual "doing things" code.

Basically - The ONLY time I want to split code off into named chunks is when
the alternative is copying/pasting code somewhere. I look for code which is
getting reused and break that out.

The in-lined version is faster to read, faster to understand (and by
understand I mean REALLY understand, not some hand-wavey "I trust this name"
understand, but as in you actually know the operations and changes to the
system that the call will result in)

The downside to inline code is you have to actually read it. I find a lot of
the folks who really like short methods struggle to parse the language they're
working in and fall back on the name without actually understand what the
chunk of code does. But I think they're also the folks who have a better
memory for names.

~~~
davvolun
Reducing cognitive load by breaking things into digestible pieces can be hard,
and at times it's hard to say if option A is better than option B, but it is
_not_ preference.

If `extractId` is an eight-step process that's only used once, but I step over
it and check locals to find that the variable was correct before the call, and
wrong after, then I just found my problem. That would be faster than stepping
over each step to find the problem -- basically the debugging version of
divide and conquer (for finding the solution, optimal would be binary search,
but for readability and maintainability, that should _not_ be the goal).

Another example is if I have a boolean condition that incorporates extremely
complex logic but is only used once, if I assign it to a variable called
`nameWasPreviouslySet`, that is easier to read and understand, and if I'm
debugging and expect `nameWasPreviouslySet == true` at _this_ point, and it's
not, then I've figured out the bug is in setting `nameWasPreviouslySet`. So
DRY shouldn't be the only reason to refactor -- refactor for readability also.

~~~
horsawlarway
Ok, so lets take your example at face value. You have an extremely complex
step of code that you only call once.

Already, you have invariants that are easy to break. You're assuming it's only
called once. That's relatively safe if you're inline, that's bogus as soon
you've broken it out into a named function.

Some other dev WILL come along and re-use your helpfully broken out code
somewhere, and that invariant no longer holds.

Even assuming no one else has re-used it, what ensures that the problem is
actually in that method? Particularly if that method itself calls out to many
small named methods.

So you have some complex code that does something, but the "things" it does
are call out to other small chunks of code.

so now you have

DoComplexThings => { DoSubThingA DoSubThingB DoSubThingC DoSubThingD
DoSubThingE return }

So you're back to binary search - The problem is in there somewhere, but "in
there" is actually calls out to many other functions again. Which one is
broken?

And wait! DoThingD got changed at some point and will now fail if you run it
before DoThingC, but there's nothing in the names that tells you that.

So you have hidden deps between chunks of code that are all trying to
accomplish a single goal.

If you're debugging that, you almost certainly have to go through all the code
in that method again, except you have to page back and forth in your editor to
get the meaningful pieces into view. All so some OTHER dev could give it name
that was meaningful to them, but likely not that helpful when you're debugging
because the mental model they have of the system resulted in the bug in the
first place.

\---

Now, rant aside - I think we agree more than we disagree, I think good names
matter, and I think there's a lot of wiggle room around when a thing should be
broken out.

But if the code is trying to do a single thing, and it's not re-used, I'll
take a single cohesive method over 8 tiny abstractions ANY day.

~~~
davvolun
> if the code is trying to do a single thing

What is a single thing? Login? Initialize db? One line of code, 3 lines of
code, ...

If you have 100 lines of code and 6 nestings, even if none of that is or, as
far as you can tell, should ever be re-used, you should break that into
smaller, digestible chunks of DoSubThingA, etc.

It's kind of an aside, but you mentioned e.g. `DoThingD` got changed or "some
other dev WILL come along" \-- if some other dev comes along and doesn't
bother to check where and in what context `DoThingD` is being used, and
changes it in a way that breaks `DoThingC` or `DoThingE`, they aren't doing
their job. Particularly, if `DoThingD` wasn't written to be re-used, and they
just use re-write it and use, particularly in a way that breaks its original
invariance... I would be having strong words with that developer.

------
wruza
The question is, why didn’t the author write his article in smaller 50-word
block tree, conveniently connected by a-hrefs and/or separated to multiple
pages, all links well named.

It is a straight wall of text instead, that is hard to follow and using
implicit references all across.

~~~
cjfd
Actually, the more technical a text is the more likely it is to contain
references and (sub)headers. Also, I certainly would not describe this text as
a 'straight wall of text'. A straight wall of text would be a text without
paragraphs or headers.

~~~
BigJono
Breaking text up like that is the equivalent of chucking some line breaks in a
function and a few comment headings, not creating a bunch of pointless
functions and scattering them around the file (or codebase).

------
pubby
I've seen this idea cargo-culted way too often. There's nothing wrong with
long functions. In fact, long functions are often easier to grok than ones
split apart into dozens of pieces.

Create useful abstractions. Don't create abstractions for the sake of creating
abstractions.

~~~
bransonf
I share your sentiment. Some of the programmers I’ve worked with would build
functions for every thing within a larger function.

Need to chunk the data? Function. API Call? Function. Parse the response?
Function.

So I asked: “Are you ever going to use these internal functions for anything
outside of this function?” And their response was: “No, but it makes debugging
easier.”

It does not. It makes it exponentially more difficult. Maybe I just work with
too many terrible programmers...

~~~
Nition
One middleground option if you have a long function but also want to break it
into chucks for easy readability: In C# and some other languages you can put
braces around a block of code without actually having any condition on it.

Or just throw some big comment headers in.

~~~
aptwebapps
VS Code has regions, which look like preprocessor instructions but I don't
think they actually have any affect on the code. They do, however collapse
while providing a nice label.

~~~
scns
Jetbrains IDEs have those too

~~~
aptwebapps
Thanks, I've been using PyCharm for years and didn't know that.

------
blowski
> Novice Programmer: "Putting all this code in one function would be easier to
> write."

> Master Programmer: "You fool! You can't just stuff all your code into one
> function because it's easier to write!"

So the Novice Programmer separated all the code out into different functions
and showed the results to the Master Programmer.

> Master Programmer: "You fool! Why have you broken this out into different
> functions when it all belongs together in the same function?"

And in that moment the Novice Programmer achieved enlightenment.

~~~
tempguy9999
> achieved enlightenment

I haven't. What are you saying?

~~~
gibagger
I believe that it means that some things aren't always very clear cut, and one
could make a reasonable argument to do it either way.

~~~
tempguy9999
The best I could interpret it is to have it both ways; break it down into
small private functions, then nest (edit: encapsulate) these in a larger one
where they can't be seen by anyone else.

~~~
blowski
Both and neither.

It depends on you and your team, the project requirements, the rest of the
codebase, and so many other things. The choice you make is less important than
_why_ you make it.

~~~
tempguy9999
Maybe the western approach of actually giving useful information beats the zen
approach of confusing the fuck out of people.

~~~
blowski
You’re going to hate reading this:
[https://www.mit.edu/~xela/tao.html](https://www.mit.edu/~xela/tao.html)

------
siscia
I would argue exactly the contrary: [https://redbeardlab.com/2019/02/07/write-
long-function/](https://redbeardlab.com/2019/02/07/write-long-function/)

Very seldomly the problem is to understand one function, most of the time the
complexity is in understanding how everything fit together. Having dozen of
little functions does not help at all.

On the contrary having few, well designed, well interfaced functions that
takes care of all corner cases and just work helps tremendously. Those
functions are almost always long.

------
Mikhail_Edoshin
I find this an artificial metric. Normally code just gets split organically as
you notice that you can reuse this bit here or that bit there. Some functions
won't split and that's OK. (Reference to the 2k-plus-line main interpreter
loop in Python.)

Actual reuse is the primary drive for this. Trying to adhere to some other
concept instead is dangerous. I've lost countless hours trying to make code
"properly object-oriented", or "isolated", or "pythonic" until I realized it's
all a delusion.

~~~
jfengel
It wasn't always artificial. When you really were working on a screen that
showed 24 lines of 80 characters, it was a good practice to be able to view
your entire function at once. That was especially important since at the time
we lacked tools like debuggers, and so there was more focus on being able to
find bugs by reading.

Today the hardware improvements make those numbers obsolete, but the numbers
were picked in the first place because a "screenful" was picked to be a
reasonable amount of information to handle at one time -- not just for code,
but also for code.

I was never religious about the rule, but it still feels like a good code
smell to keep an eye on. If a function gets too big, I start wondering if it's
really still doing one thing.

------
whoisthemachine
I prefer 120 characters of width, modern monitors are wide-screen, I think
it's ok to adjust a little to accommodate this reality.

~~~
rypskar
You don't even need a wide-screen monitor for that. I like to turn my coding
screen 90 degrees, to portrait mode, to get more vertical space and still can
see the line at 120 characters.

I call it the TIE-fighter setup, the screen in the middle is in landscape mode
and the two others are in portrait mode, gives a lot of screen-space without
having to turn the head much to see it all

~~~
enriquto
> I call it the TIE-fighter setup,

I have the exact opposite setup, with the vertical screen in front of me. How
would you call that setup?

~~~
VistaBrokeMyPC
Satellite setup! (side monitors are solar panels?)

~~~
enriquto
not as awesome as "TIE fighter setup", but it does the trick

------
User23
This is one of those things that is older than the printing press. We learned
a long time ago that there is a more or less optimal column width for text and
it's based on the physiology of the eye. I haven't been able to find a great
reference online in a brief search, but this[1] has the basics.

[1]
[http://maxdesign.com.au/articles/em/](http://maxdesign.com.au/articles/em/)

------
tylerl
I first saw this in the Linux kernel style guide back in the 90s. The idea was
that you should be able to read a function without scrolling. So that meant it
would fit on screen in a standard terminal. It's a bit extreme for practical
use, but the concept is important to keep in mind.

I was helping a Jr programmers with a code review a few months back. He'd been
told that a particular chunk of code was "unclear", with specific emphasis on
4-line bit of logic in a 30-ish line function. He had no idea how he could
make the code "more clear". It did what it did; the logic was a bit complex
but the code was exact and correct.

The solution: factor out the 4 lines of code into a function. It was only ever
called from that one place, but by making it a function you give the code a
name, with clear inputs and outputs. Nothing changed about what the code did,
but it became a lot easier to reason about.

It's a helpful lesson that generally doesn't really sink in for the first few
years.

~~~
Gunax
Do you think that's a good practice? I have always been conflicted.

For one, writing a new function isn't just for vanity--it changes the actual
machine code generated (unless an optimizer is smart enough to fix it). I
don't like changing the actual operation just to make a program more readable.

But sometimes it just is easier to move a bunch of crap to a function and
abstract it away.

~~~
usr1106
> For one, writing a new function isn't just for vanity--it changes the actual
> machine code generated (unless an optimizer is smart enough to fix it). I
> don't like changing the actual operation just to make a program more
> readable.

Inlining should, but does not always prevent this. Because compilers have all
kind of limitations when they are no longer able to inline. From what I read I
have got the feeling it got better in recent years, but I have not studied the
issue.

That said for > 99% of the code written a function call has no measurable
performance impact. Few of us write code in a hotspot of an operating system
or a very tight loop of some number crunching application. A bit more than 1%
might possibly write vectorized code, but still the huge majority never does.

Programming suffers much more from bugs than performance issues. And if there
are performance issues, they are typically because of improper algorithms,
wrong I/O patterns or high memory consumption, not because of a couple of
additional function calls.

------
paggle
Terrible advice. A method perform one coherent action... if that action takes
1000 lines of code due to some wacky business logic, then the function should
be 1000 lines, not split into multiple functions just for the sake of some
weird rule.

~~~
kevinrav
did not agree about it, Wacky business logic can break up into small function
or smaller business logic. The way to keep track in a huge function will make
your brain struggle/question in middle of way. The good engineer need to find
out where need to break. We need write code for readable and archive business
logic.

------
kstenerud
Or, to understand this one level deeper: Functions/methods should do one
thing, and do that one thing well. In general, each of those one things should
be smallish things that you use to compose bigger things, which also do one
thing and do it well.

24 lines is as good a rule of thumb as any, as long as you're not actually
counting the lines. Your goal is flow and readability (ultimately:
maintainability), not some countable metric.

------
stefanfisk
John Carmack's take on this seems a lot more sensible to me: [http://number-
none.com/blow/blog/programming/2014/09/26/carm...](http://number-
none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html)

------
tomxor
There is a lot of disagreement here with the ideas presented, but i think most
of the arguments are taking the ideas too literally and extremely... as with
any advice there are no hard and fast rules.

I have some guiding principles similar to the author which make me end up
essentially doing the same thing (I also like to keep under 80w and roughly
24h, but there are many exceptions)... yet my principles are seemingly
contradictory e.g: 1. minimalism, 2. holism.

Notice that they are not imperative, they are merely principles / desirable
attributes, by minimalism I usually mean what the author is talking about but
in a more general way, keeping small code blocks is one such desirable... but
this does not mean split everything up into micro functions that cause a
horrible nest of layered calls, because that goes against the principle of
holism... this I believe is also similar to what the author wants - holism is
part of legibility, whereas reducing your function scope and interface are
only immediate legibility of the local code.

Ultimately what i'm talking about is balance, which is why I think it's better
to present these ideas to people as principles rather than imperative rules
which can be followed rigidly (wrongly).

------
sethc2
If his point is that you should dogmatically reduce long functions into a
bunch of small functions, I think he is completely wrong. If his point is that
when the clearest way to implement some functionality is with a single long
function and not several small ones, and that that is likely indicative of
poorly architected code and/or data models, I probably agree with him.

Iff you have some poorly architected code that results in you writing a 500
line function, breaking that poorly architected code down into 20 small
functions will only make things worse. However it might be that you could re-
architect the code and data models in such a way that functions don't need to
be large to be clear then that is probably a good thing.

So please don't go breaking a long function into a bunch of smaller ones,
where your small functions' names are effectively code comments, but if you
can, rearchitect the code so that a set of smaller functions can accomplish
the same task in a more clear way, I am all for it.

------
inertiatic
Me and my coworkers are working with multiple, widescreen monitors. These can
display, even in a crowded IDEs with larger fonts hundreds of characters in a
line. Oh, and they have the capability of _wrapping_ text.

Yet, a lot of the purported best practices, a lot of the frequently used
linters etc. complain about that 80 character limit.

Now, when I'm reading Python that follows the actual best practices of named
arguments and descriptive variable names, I might have to follow a function
call so far down that I forget what it's name even is.

Fun!

I've also had the experience of trying to follow code that follows the other
best practice of breaking out everything into a separate function. It's always
a joy to have to follow that trail out of the call stack when trying to debug,
and having to back out potentially tens of files while trying to navigate some
unfamiliar code, losing all the rest of the context on each single jump.

~~~
scoutt
> wrapping text

Oh my. Who uses wrapping text for coding?

~~~
twic
Why wouldn't you?

You do need some sort of indication in your editor that the line is soft-
wrapped. If you have line numbers in the gutter, then you already have that.

------
AdrienLemaire
> You've probably heard about the 80/20 rule, also known as the Pareto
> principle. Perhaps the title lead you to believe that this article was a
> misunderstanding. I admit that I went for an arresting title; perhaps a more
> proper name is the 80x24 rule.

You got me there.

The 24 lines convention is interesting. Made me realize that linting rules
exist for function length: javascript: [https://eslint.org/docs/rules/max-
lines-per-function](https://eslint.org/docs/rules/max-lines-per-function)
Can't find the equivalent for python though

------
raverbashing
Sorry, this sounds a lot like motivational "feel good" advice that's in
essence empty and confuses more than helps.

"write small functions" sure, how does it help managing complexity? Now you
have several tiny functions and need to jump across files and functions to
understand how everything works (+ the overhead each function adds -
parameters, return values, etc)

Sure, small functions have their place, but sometimes it is easier to have a
big block of code that does what you need. Or as another comment said, write
small functions but big procedures.

Now for my favourite pet peeve: that 80 columns is some kind of "best
practice". In reality it has been cargo culted since the days of the initial
IBM PC and there is no reason for such an arbitrary number to exist. But the
church of 80 columns keep repeating their mantra mindlessly, mindlessly
uglyfying lines of code which go over only a couple of characters beyond 80
columns and wasting coder time with this instead of actually asking the
question: is the code actually easier to read now or not?

Because to me, calling a function with one parameter in each line is extremely
ugly (especially under-indented as the examples presented in the article)

Is a line that's 85 characters essentially harder to read (especially now with
multiple screen sizes and widths) than an 80 char one? No.

I'm not advocating for writing 200 character lines of code, but to not be
absolute about it.

------
9214
Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096
bytes and fits into disk block).

Makes no sense in the modern world of course, but, in the context of block
editors, it creates a development environment where making complex and bloaty
word definitions is actively discouraged -- an idea that Aaron Hsu briefly
mentions in his APL talks [1].

[1]:
[https://www.youtube.com/watch?v=gcUWTa16Jc0](https://www.youtube.com/watch?v=gcUWTa16Jc0)

~~~
zentiggr
Of course, in the Forth environment, the more any word definition bloats, the
harder the stack tracing you have to do in order to understand the operation
flow, so keeping things neat and to the point is even more important.

It might be a failing of my own, but I've always wanted a concatenative
language IDE to have a stack window, with manual labeling, so I could see what
all is on the stack and follow the information flow better.

------
js8
I prefer another rule for short functions. You should be able to explain what
the function is doing in one sentence. If you need two sentences, you should
break it into more functions.

On the other hand, if your descriptive sentence is basically just duplicating
the statements in the function, then your function is most likely too small or
too granular. Depending on situation, you might be able to fix it.

------
mhd
I tend to have a rule/aspiration that I could frame as "80 || 24": don't force
me to read too much in two axes. So a longer routine that does maths, maybe
even with nested loops, but using short variables and few function calls is
quite easy to follow.

As are short routines that have long identifiers. Like your average OOP or
Lisp code.

I even think that multiple statements per line are falsely maligned. Wirth
used them quite a lot, and not just in stuff meant for publication. If you've
got everything on a few lines, it's not that hard to follow.

Interesting sidenotes for this would be syntactic elements beyond
functions/methods. Starting with nested functions, where I actually found the
function-hoisted JavaScript variant better than Lisp's flets/labels or modern
JS arrow functions.

Other areas that don't seem to be investigated a lot would be inner-procedural
_refinements_ (ELAN, some C preprocessors), folding/structured editors and
Knuth-style Literate Programming.

------
rileyt
This is really good advice. There are a ton of different reasons why you can
end up breaking this rule and almost all of them are things you want to avoid:
multi-purpose functions, adding to old functions that should be refactored,
adding an extra case to an if statement that should be broken down, etc.

------
gorgoiler
I love this. For as long as code needs to be maintained, code will always be
just as much about communicating with people as it is about people
communicating with machines.

One thing I still enjoy about message passing OO (by which I really mean Ruby)
is how it’s really easy to separate concerns to the extent that each file
contains one module/class with one public and a few private methods in it. I
went a bit bonkers this year and found myself doing one method per module,
which is the extreme version of this.

Languages with mixins are great for this too. Mixins are, amongst other
things, a nice shortcut around composition that lets you put individual facets
of functionality in separate files, albeit with fewer guarantees about code
remaining uncoupled.

It’s a shame Ruby’s module system doesn’t better support _private_ for modules
though.

~~~
Gunax
According to the SICP “Programs must be written for people to read, and only
incidentally for machines to execute.”

------
ken
> Most mainstream languages, however, seem to be verbose to approximately the
> same order of magnitude. My experience is mostly with C#, so I'll use that
> (and similar languages like Java) as a starting point.

I see this, too. For a couple decades, all mainstream languages had roughly
the same order-of-magnitude verbosity, and then when GC languages arrived, it
took a big leap. Now we've plateaued here for a while. When closures became
mainstream, that was a smaller leap.

This leaves me optimistic for the future. I find Lisp to still be much more
compact than mainstream languages. Maybe once this generation has fully
accepted the current level functionality, and gotten tired or frustrated with
it, we'll see another jump in mainstream language expressivity.

------
disposedtrolley
A reasonable line width contributes so much to readability.

While I'm fortunate enough not to experience much of it in the code I read, I
do see a lot of websites which grossly violate sane line width rules by
stretching the body text to the full width of the browser (looking at you
Wikipedia ). Take
[https://en.wikipedia.org/wiki/Cyclomatic_complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity)
as an example.

Edit: Martin Fowler's blog
([https://martinfowler.com/](https://martinfowler.com/)) is probably a good
counterexample to this.

------
azernik
> Like all other programmers, other people's code annoys me. The most common
> annoyance is that people write too wide code.

> This is probably because most programmers have drunk the Cool Aid that
> bigger screens make you more productive. When you code on a big screen, you
> don't notice how wide your lines become.

This is part of why I only _ever_ edit code in a half-screen-width window; the
other half of the screen is always filled with either another editor, or a
terminal. This ends up coming out to more like 100 characters per line rather
than 80, but the principle is the same.

------
jitendrac
I disagree with article. For me function is an abstraction of re-usable code
to achieve a single goal(or Intended state). Think of the list of function in
system as a list of APIs for a service, the more you create for unintended
purpose, the more likely it is a tech-debt.

so, I will say make function for a Goal/Intend in mind, abstract only generic
logic to small functions, which have guessable behavior through identifiable
by name. Long functions are good if they need to be.

------
keymone
Here’s a case for 80rule: our vision is (mostly) two dimensional, research
shows reading comprehension drops as lines get longer, that’s why books and
newspapers mostly have fairly narrow columns, comprehending code is less about
reading but more about scanning and picking up context for things, much easier
to do when perimeter is minimized.

Lots of gut instinct here, not enough citations, maybe one day I’ll compile a
more substantiated post about this.

------
davvolun
Agree fully, and as mentioned in the article

> I tend to stay within it, but I occasionally decide to make my code a little
> wider.

No coding rules should be religiously held. If you're trying to re-write an 81
column line to fit the rule, even though it's concise and more readable at 81
columns, you're doing it wrong.

------
seaish
I don't know how everyone uses such small font sizes. I think mine is set to
16pt.

The one thing that frequently makes me ignore line lengths is URLs. They seem
to be most readable when on one line, even if it's 200 characters long.

Also, what kind of variable name is `maîtreD`? I doubt many regions have î on
their keyboard.

~~~
thrower123
Their eyes must be much better than mine. I think I would probably have
eyestrain and be even more tired at the end of the day if I had to squint at
8pt font all day.

------
k__
I had some issues when giving 80 char wide code into print. 70 worked.

Just as a small info :)

------
dimino
I cannot overstate how important this concept is. Write code (and DESIGN
SYSTEMS) that fit in your brain, because the faster you can reload it back
into your brain, the quicker you can dispatch bugs and new features down the
line.

Nothing in my professional career has caused me more anxiety than encountering
complex code to solve a simple problem. It's infuriating, and has _long
lasting_ deleterious effects for the life of that code.

What's especially insidious about this problem is that for folks who value
short term success over sustainability, they'll struggle with this for a long
time, and have all kinds of reinforcement to be skeptical that any of this is
even a problem. Once you get used to struggling with complex code some people
start to think it's all that can be written.

~~~
NohatCoder
Artificially slicing up functions does not make the code fit in my brain, it
just means that I have to load in more functions in order to have the required
context.

~~~
dimino
Definitely, which is why doing it just to get small blocks of code won't work.
It has to be part of the entire design, and sliced at real, logically separate
spacings.

It's hard! But immensely rewarding if you get it right. You have to be
thoughtful as you design and build.

