4 ms·

I can feel my IQ dropping at a steady rate when I program for long stretches of time.

adam_arthur 6y ago
In my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment. I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments. It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
- dmitriy_ko 6y ago
  So it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code. Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.
  - adam_arthur 6y ago
    Not a solo project. I was an early dev at a startup and owned that feature area. Later on others took over the code. How to judge whether a codebase is high quality? Consistency of design and abstraction. Does the code use the same abstractions and design throughout? Consistency is one of the most important things in quality. How many unique concepts and abstractions do you have to learn to understand the code? E.g. in frontend context, do you use the same pattern for managing business oriented state? How is that state updated? Are those patterns consistent throughout your codebase? The biggest problem I see with the spaghetti codebases is they lack consistency in design. Separation of concerns. What's the blast radius of any given change? If I change render logic, can it impact business logic, and vice versa? A big problem I see is that codebases do not appropriately separate these type of things out. Meaning the code is fragile and it's easy to introduce bugs inadvertently. Anyway, I can list many points, but I'm on mobile now. High level indicators would be: How quickly can new devs jump into the codebase? Is it easy to diagram and explain to others how the code is structured? How many bugs come out of your codebase? How quickly can you add new features to that codebase? What is the "blast radius", or is it possible to break something seemingly unrelated to a change you're making? How do I know my codebase was good quality? I was extremely self critical when writing it and ended up rewriting it a few times before it was in a state I was satisfied with. Number of bugs are extremely low and feature velocity is high, relative to other areas of the code.
DesiLurker 6y ago
Been coding about 20yrs, In my case its not as much as the IQ but the ability to switch perspectives. I have seen that when I code or debug for long hours often I lose that critical ability and I often repeat the same mistakes. Eventually I take hours to accomplish what I would in 30mins, thats when its time to wrap up. but I should point out that long stretches of time are different from quite (context switch free) streches of time.
uhhhhhhhhhhhhhh 6y ago
I get this but it usually just means I need to eat some food

In my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment. I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments. It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.

dmitriy_ko 6y ago
So it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code. Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.
- adam_arthur 6y ago
  Not a solo project. I was an early dev at a startup and owned that feature area. Later on others took over the code. How to judge whether a codebase is high quality? Consistency of design and abstraction. Does the code use the same abstractions and design throughout? Consistency is one of the most important things in quality. How many unique concepts and abstractions do you have to learn to understand the code? E.g. in frontend context, do you use the same pattern for managing business oriented state? How is that state updated? Are those patterns consistent throughout your codebase? The biggest problem I see with the spaghetti codebases is they lack consistency in design. Separation of concerns. What's the blast radius of any given change? If I change render logic, can it impact business logic, and vice versa? A big problem I see is that codebases do not appropriately separate these type of things out. Meaning the code is fragile and it's easy to introduce bugs inadvertently. Anyway, I can list many points, but I'm on mobile now. High level indicators would be: How quickly can new devs jump into the codebase? Is it easy to diagram and explain to others how the code is structured? How many bugs come out of your codebase? How quickly can you add new features to that codebase? What is the "blast radius", or is it possible to break something seemingly unrelated to a change you're making? How do I know my codebase was good quality? I was extremely self critical when writing it and ended up rewriting it a few times before it was in a state I was satisfied with. Number of bugs are extremely low and feature velocity is high, relative to other areas of the code.

DesiLurker 6y ago

Been coding about 20yrs, In my case its not as much as the IQ but the ability to switch perspectives. I have seen that when I code or debug for long hours often I lose that critical ability and I often repeat the same mistakes. Eventually I take hours to accomplish what I would in 30mins, thats when its time to wrap up. but I should point out that long stretches of time are different from quite (context switch free) streches of time.

uhhhhhhhhhhhhhh 6y ago

I get this but it usually just means I need to eat some food