Comment by naikrovek | Hacker News Reader

Comment by naikrovek | Hacker News Reader

Parent Full thread

> My anxiety around coding has reduced a significantly when I learned about TDD and started writing code made of very small, composable chunks.

you definitely do not have ADHD, then. I find these absolutely impossible to trace through when I want to find out what a program is actually doing, in reality.

if I have to find the actual logic used in main or whatever event handler, and it's in a function called by a function called by a function etc., then I will forever despise the developer who felt that this was anything approaching an acceptable design, or even an acceptable idea.

codebases like that are impossible for me to absorb.

put the logic where it fucking goes, inline with its use! right there! nowhere else! don't nest it behind abstractions you don't NEED.

functions that are very small and used in 100 places in the codebase should be inlined in the source code so I can read it. there is no function used this much in an application I've ever even considered working on, anyway.

I always prefer to copy and paste a little bit of logic around than to wrap 5 lines in a function and call it from everywhere.

if the function is 100 lines of complex code, put it in a function and call it ONLY if it is used in more than 2-3 places, and NEVER if it is only used once.

today's "best" practices serve only to shut me and others like me out of participation and are exclusionary.

this does mean that I have to take the time to find very good names for everything, which takes time, but always pays off in readability, for everyone, not just me.

> you definitely do not have ADHD, then

I do have ADHD (clinically diagnosed), and I disagree 100% with this statement (at least the certainty of it). In my experience, TDD and writing small chunks greatly reduces my anxiety and increases my productivity by helping me to narrow the scope of the task I'm working on.

Different people have very different experiences despite having the same diagnosis. What is exclusionary for one person may be the exact opposite for someone else.

>you definitely do not have ADHD, then. I find these absolutely impossible to trace through when I want to find out what a program is actually doing, in reality.

You cannot determine if people have adhd on whether they agree with you on big vs small functions. Its not how it works and all, and your preference is just a preference and not an universal truth for everyone with adhd.

This is why I like more bottom-up approaches to coding. Code broken up sorta arbitrarily, that's compressed moreso than abstracted, is hard to follow. But, when there's a reasonably small set of solid domain abstractions (even extremely complex ones in implementation), that's totally fine. This is where preferences vary; some folks have committed nuances of various helper libraries to memory, and find it easier to process a `fuse_zip` combinator or whatever than a loop, but for the readers who'd need to look that up, it's an attention land-mine.

API design, abstraction design, is a type of UX design, and like other forms of design, accessibility is a concern. Keeping the vocabulary fairly small and the abstractions well-behaved and consistent help nearly everyone, but particular ADHD folk.

The thing is that you shouldn't really care about the details of these small functions until you for some reason, need to. At a high level it's easier to understand stringing together a bunch of small functions and assume how they work. If you have ADHD it seems like abstracting away the details in the small functions should help you, but it seems like you aren't able to ignore the details of how each small function works even when in context it doesn't matter, which is where it hurts you.

Hehe, I agree with what you're saying here, but I think you might've misunderstood me.

> put the logic where it fucking goes, inline with its use! right there! nowhere else! don't nest it behind abstractions you don't NEED.

What you're talking about here looks more like over-abstracting. What I'm talking about is having understandable components with simple, easy to understand behaviour. I think we're on the same page.

I want to be able to understand what the component does at the first glance. I also want to be able to understand what a larger part of the system does at the first glance. But, overall, I'll always err on the side of _under-abstracting_ and duplication, like you.

One might argue that software development is about 1) defining a business problem, _then_ 2) communication (usually with "ghosts" i.e. another developer who is not in the room with you[1]), then writing the implementation. My philosophy on the subject is like this: https://sonnet.io/posts/code-sober-debug-drunk/

TL;DR it's always easier to write code than to read it, be kind to the next person reading it (it might be you)

[1] https://sonnet.io/posts/emotive-conjugation/#:~:text=Ghost%2...

Reply on news.ycombinator.com