13 ms·

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstractio

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find all the entry points and follow the flow of code from beginning to the thing I am interested in. One person's beauty is another person's mess. It's harder to change an existing codebase than to write a simple program that does the new thing but not in the context of the original program. A reference implementation of the various components is far easier to understand than one big ball of mud. Fitting problems together is hard. You need to understand the old thing before you can introduce the new thing and it ends up being forced or hacked in if the design doesn't support the new thing. I tend to write reference implementations of everything, then combine them together as a separate project. I find an empty file far more reassuring than a large codebase.

awild 4y ago
I try to encourage newcomers to refractor the code into a form they understand, fix the problem and then undo that refactoring as much as possible. If they actually come up with a better abstraction I'm up for it. Refactoring will give them the chance to see what the actually moving parts of code are.
- samsquire 4y ago
  I like your use of the words moving parts. Eventually code ends up looping over memory locations, copies, moves, adds, subtracts, multiplies, divides, reads, writes data or memory locations. All the files and code on the way to get this to happen such as Classes, parameters, arguments, variables, functions, methods, closures, objects are ideas of the languages compiler to abstract the instruction stream. Command line arguments, class constructors, URL query parameters, marshalling, JSON field names, method parameters, function arguments, HTTP headers, cookies, request objects, events are just complicated variations of passing data in the right shape. They are not the above list of "moving parts" or computation that is easy. In other words modern coding is just configuration. I feel the complexity of modern code is a problem we created. And I feel there's something missing. It's hard to update code. When I find the loop that does the thing, I feel I can understand the codebase such as the magic +1, -1 or the relationship of objects linked together in a data structure or the assignment to a list or array or variable. "How does that get to here"
hinkley 4y ago
Maybe I'm weird but a lot of my refactoring actually concretizes overly abstract code. It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to use a thesaurus to find a better word for something. Too often we end up recycling jargon in situations where they are not quite doing the same thing but nobody could be arsed to open thesaurus.com and find a word that telegraphs, "B is like A but is not actually A."
- nicoburns 4y ago
  > It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. This is why Sum Types are so great. They give you an option between "concrete type" and "any type that implements this interface": "one of these specially enumerated types".
- the_other 4y ago
  I had to look up "telegraph" to confirm I'd understood you correctly. I don't recall seeing it used in the context of describing language, so I doubted my interpretation. I've heard it used most in discussions of boxing: a boxer's posture or their sequence of muscle activations _telegraph_ their planned attack such that their opponent has time to block or counter. I like the way you used it. I'll try to use that myself.
  - layer8 4y ago
    It means communicating something quite clearly but by indirect means (and possibly inadvertently).
    - hinkley 4y ago
      I've had this argument in code reviews a couple of times: Them (on the subject of 4 new methods): hey why did you make method 3 look "weird"? You should make it look like the other three. Me: because one of these methods can set the building on fire, and the rest can't. I bet you can guess which one is the dangerous one. Works as expected.
efa 4y ago
>>People abstract before an abstraction is necessary. This!
alphanumeric0 4y ago
> I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?
- samsquire 4y ago
  At one point in time I used OpenGrok to try understand large projects. Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees. What's the model of this program? What are the core principles that the author is using? Do I really need to read every file to understand what is going on? With Leetcode style programs there's one file with everything in it and I can usually find the entry point. The problem is well defined. I can see the moving parts in a Leetcode style problem. The looping, the data structure creation and control flow, arrays and recursion. Large mature codebases such as Java projects have thousands to millions of small files and packages it can be difficult to see how things fit together, every file seems to be 10-20 lines long. I like C projects as they have lots of code in one file. Everything I need to understand a module is in one file and I can use vim folding.
  - alphanumeric0 4y ago
    I could see this working with vim folding. That's an interesting approach. I never really used folding in IDEs.
  - josephg 4y ago
    I’ve been programming for nearly 30 years and I feel the same way. 1000loc+ files are increasingly common in my code bases. I find it really hard to read code with lots of tiny files that individually don’t do anything. It’s like the programmer is embarrassed by their code so they’re making me search for the core logic. Splitting code into multiple files really only makes sense to me when there’s a clear division of responsibilities. That can mean a lot of things - like client / server, utility methods / core algorithm or class A / class B. But plenty of complex data structures are much easier to read and understand all at once. For example, I have a rust rope library which implements a skip list of gap buffers. The skip list is one (big) file. The gap buffer is another file. Easy.
xedrac 4y ago
> People abstract before an abstraction is necessary. This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. > ... not all refactorings improve the code. While true, I have a low tolerance for code that requires constant bug fixing, or is so overly complex that the thought of modifying it makes you want to cry. Some projects truly require that level of complexity. But in my experience many do not, and once you've gained a solid understanding of the problems it is trying to solve, incremental refactoring is a fantastic way to improve the code's stability and maintainability. This is especially true in C++.
- mark-r 4y ago
  >> People abstract before an abstraction is necessary. > This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. I worked with a guy who did that. He had a plan for what the project would look like 5 years down the road, and he built abstractions to support that. He could get away with it because he could hold it all in his head and it all made sense to him. When version 1 was half finished he was called away to work on another project, and those of us who followed in his wake struggled to make any sense of what he left behind. A year later he was laid off. The project was a success, but nobody ever asked for version 2.
- zelphirkalt 4y ago
  > This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. Mastery will be, when you write code in a way, that does not impose unwarranted limitations from the start, and still keep it readable and only containing mandatory complexity. Usually this can be achieved through deep understanding of the problem, mapping to simple concepts or finding or making that one concept that captures things well. Not always it can be done. Not always can a masterful solution be found, which keeps complexity low. However, it is definitely a mistake to draw a black and white picture of "if you want to make it work for the future, you must add complexity". Often people simply choose bad abstractions or wrong ones and will only realize, when the future has become the present and the system they built cannot fulfill some requirement.
he0001 4y ago
> One person's beauty is another person's mess. This is so true. Also I believe that when the original author wrote the code he had a (hopefully) clear vision of the solution. He wrote it as tidy and fitting to the problem as he saw it. Then sometime later someone else comes in and is supposed to alter the code in a way which does not fit the original author’s idea of the problem. This creates a mismatch. The new guy can’t and won’t change the code too much, as it is too risky/much to do and therefore will only do as little as possible to make his change. Then some other comes along and do some more changes, which again isn’t enough etc etc, et voilà, you have a ball of mud that screams of a rewrite.
- hikarudo 4y ago
  Spot on. You've described Peter Naur's "Programming as Theory Building" paper exactly.
pyrolistical 4y ago
> I tend to write reference implementations of everything, then combine them together as a separate project. This is how I write software. My stackblitz is full of domain independent experiments https://stackblitz.com/@Pyrolistical https://stackblitz.com/@Pyrolistical. I then copypasta this into private projects once I figured out how the individual piece works.
- josephg 4y ago
  Yeah I love this approach too. I’ve been learning CRDTs lately and I’ve gotten so much value from making tiny, inefficient reference implementations of things before diving in and optimizing. Toy implementations shake out all your misunderstandings of your design, and you can refactor like crazy. Going from simple code that works to complex code that works is much easier than creating the complex code correctly from scratch, in situ.
  - pyrolistical 4y ago
    Also I've discovered (and reported) so many bugs when I realized my very simple toy example was broken
OJFord 4y ago
Is it deliberate that your comment itself is like an instance of the methodology you describe? Small separate stand-alone thoughts vs. a well-understood description (harder to write, to consume) in longer form commentary? That's not a criticism at all by the way, I just found it striking.
- samsquire 4y ago
  It was accident and not deliberate but you may reveal how I think. Thank you for this insight. In hindsight if you focus on three questions: is it good? Is it right? Is it true? You'll head toward a good direction Synthesis of ideas is really important and the building blocks of understanding are fascinating. Programming and mathematics is taught as building blocks and then deliberate practice. I really enjoy reading plain descriptions of things, especially of other people's code. If you understand the core insight, difficult things can be easier to understand and apply for you. I really want to understand how tracing compilers work and LuaJIT, JVM and V8 but I found the code a bit too hard to understand as I jumped into the wrong locations. There has been two instances where Wikipedia was enough for me to understand and write an algorithm that implemented the description. Wikipedia doesn't have pseudocode for multiversion concurrency control but it does have an accurate if subtle description. I did the same for btrees but I did read some other people's implementations to get a feel. I of course wrote mine completely differently. I want people to document their code enough so that the core principles or idea behind their code could be reimplemented by someone else just by reading the description of how it works. Rpython and Pypy documentation is good but I still don't understand it enough to implement what it does. Which means I'm missing some detail or core insight.
spaetzleesser 4y ago
"In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code." Same for rewrites. Often the rewrite will have the same number of problems, just different ones.
joe_the_user 4y ago
One of my recent coding experiences was teach a friend in grad school(MA) to code sufficiently well to finish his Master's project. Refactoring was absolutely necessary for this. He was writing a single simulation program that was single file in size. But once he'd created ten subroutines all changing a raft of the global variables, the slightest changes produced hair-raising bugs that he'd obsessively dive into debugging. The intuitions of structured programming and object oriented are more important than absolute fidelity. My points were: "If you can't have an object here, at least have a well defined, standard interface to values that need to be in a consistent state" and "decompose long action sequences into subroutines and if you can't do that, least group similar actions with similar actions in that long action sequence". Which is to say a given piece of code might not the structure you want but if has a structure, that can be enough. But then again, that piece of code might not structure at all and then rewriting it really is necessary and often is easier than debugging it a few time. And working with a large piece of "bad" corporate code, I've more than once that you something with one sensible if idiosyncratic structure that was refactored more than once by people who didn't understand the structure and imposed their own structure on just part of the code. But through an exercise in archeology, one can make the whole artifact work. But that doesn't mean you can't have code that is a true mess when the writer has no experience and no concern with structure.
galdosdi 4y ago
What a great way to do it, too, because once you're done, your "reference implementations" can later serve as test harnesses if need be. > I tend to write reference implementations of everything, then combine them together as a separate project.
pmarreck 4y ago
No mention here is made of test coverage (hopefully because everyone already knows); to refactor without near-100% test coverage is insanity.
intelVISA 4y ago
Generally most of my refactoring is cutting out code; I love an excuse to chunk down excessively verbose classes.. maybe I'm weird but I generally prefer a lean, concise codebase that might share a few free functions than a perfect OOP pyramid.
jb_s 4y ago
>I find single file dense leetcode style code easier to understand I find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff. For reference, my cognitive abilities are heavily skewed towards verbal/abstract reasoning - like several standard deviations above the norm - and my spatial/concrete reasoning is nearly the inverse of this, it's terrible. I wonder if this has something to do with it!
- ParetoOptimal 4y ago
  > find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff. Understanding lots of code at a module, function, or even more granular level with a magnifying glass feels more productive than struggling to understand the full picture. It also rewards you with instant gratification. Reading and writing ncrete code gives much more immediate gratification.
ParetoOptimal 4y ago
> People abstract before an abstraction is necessary. Sometimes an abstraction cuts to the core of the reason why. See for example https://algebradriven.design/ https://algebradriven.design/ Good abstractions can communicate intent better than mounds of concrete code because they speak at a higher level. However, mounds of okay concrete code is way easier to deal with then poorly thought out abstractions. This means pragmatists get little practice in abstractions, where their pragmatism is needed most to uncover the useful abstraction and avoid the overly complex invented abstraction. Abstract code also has the advantage of parametricity in strongly typed programming languages.
- samsquire 4y ago
  I started designing an algebraic language by writing code. https://GitHub.com/samsquire/algebralang https://GitHub.com/samsquire/algebralang It's designed to be expressive and powerful and practical. The core insight to a problem is rarely what we spend most of our programming time doing.
  - ParetoOptimal 4y ago
    > The core insight to a problem is rarely what we spend most of our programming time doing. I believe that is a mistake. I'll have to check your language out though!
  - arunix 4y ago
    Are those code samples formatted correctly? (they are difficult to read as is)
ransom1538 4y ago
If you are out there and WANT to write terrible code, An amazing essay: https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Unmaintainable%20Code.html https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un... I cried the first time i read this.
codethief 4y ago
> In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. That's a great point. I once read (here on HN I think) that the value behind a piece of software is not the code but the team whose members all have the same mental model of the problem and can successfully map it to the code. Lose the team and you lose that map. > One of the first things I do when I study a new codebase is find all the entry points I follow the same strategy but… Good luck with that when you're facing a Spring application. :)

awild 4y ago

I try to encourage newcomers to refractor the code into a form they understand, fix the problem and then undo that refactoring as much as possible. If they actually come up with a better abstraction I'm up for it. Refactoring will give them the chance to see what the actually moving parts of code are.

samsquire 4y ago
I like your use of the words moving parts. Eventually code ends up looping over memory locations, copies, moves, adds, subtracts, multiplies, divides, reads, writes data or memory locations. All the files and code on the way to get this to happen such as Classes, parameters, arguments, variables, functions, methods, closures, objects are ideas of the languages compiler to abstract the instruction stream. Command line arguments, class constructors, URL query parameters, marshalling, JSON field names, method parameters, function arguments, HTTP headers, cookies, request objects, events are just complicated variations of passing data in the right shape. They are not the above list of "moving parts" or computation that is easy. In other words modern coding is just configuration. I feel the complexity of modern code is a problem we created. And I feel there's something missing. It's hard to update code. When I find the loop that does the thing, I feel I can understand the codebase such as the magic +1, -1 or the relationship of objects linked together in a data structure or the assignment to a list or array or variable. "How does that get to here"

hinkley 4y ago

Maybe I'm weird but a lot of my refactoring actually concretizes overly abstract code. It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to use a thesaurus to find a better word for something. Too often we end up recycling jargon in situations where they are not quite doing the same thing but nobody could be arsed to open thesaurus.com and find a word that telegraphs, "B is like A but is not actually A."

nicoburns 4y ago
> It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. This is why Sum Types are so great. They give you an option between "concrete type" and "any type that implements this interface": "one of these specially enumerated types".
the_other 4y ago
I had to look up "telegraph" to confirm I'd understood you correctly. I don't recall seeing it used in the context of describing language, so I doubted my interpretation. I've heard it used most in discussions of boxing: a boxer's posture or their sequence of muscle activations _telegraph_ their planned attack such that their opponent has time to block or counter. I like the way you used it. I'll try to use that myself.
- layer8 4y ago
  It means communicating something quite clearly but by indirect means (and possibly inadvertently).
  - hinkley 4y ago
    I've had this argument in code reviews a couple of times: Them (on the subject of 4 new methods): hey why did you make method 3 look "weird"? You should make it look like the other three. Me: because one of these methods can set the building on fire, and the rest can't. I bet you can guess which one is the dangerous one. Works as expected.

efa 4y ago

>>People abstract before an abstraction is necessary. This!

alphanumeric0 4y ago

> I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?

samsquire 4y ago
At one point in time I used OpenGrok to try understand large projects. Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees. What's the model of this program? What are the core principles that the author is using? Do I really need to read every file to understand what is going on? With Leetcode style programs there's one file with everything in it and I can usually find the entry point. The problem is well defined. I can see the moving parts in a Leetcode style problem. The looping, the data structure creation and control flow, arrays and recursion. Large mature codebases such as Java projects have thousands to millions of small files and packages it can be difficult to see how things fit together, every file seems to be 10-20 lines long. I like C projects as they have lots of code in one file. Everything I need to understand a module is in one file and I can use vim folding.
- alphanumeric0 4y ago
  I could see this working with vim folding. That's an interesting approach. I never really used folding in IDEs.
- josephg 4y ago
  I’ve been programming for nearly 30 years and I feel the same way. 1000loc+ files are increasingly common in my code bases. I find it really hard to read code with lots of tiny files that individually don’t do anything. It’s like the programmer is embarrassed by their code so they’re making me search for the core logic. Splitting code into multiple files really only makes sense to me when there’s a clear division of responsibilities. That can mean a lot of things - like client / server, utility methods / core algorithm or class A / class B. But plenty of complex data structures are much easier to read and understand all at once. For example, I have a rust rope library which implements a skip list of gap buffers. The skip list is one (big) file. The gap buffer is another file. Easy.

xedrac 4y ago

> People abstract before an abstraction is necessary. This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. > ... not all refactorings improve the code. While true, I have a low tolerance for code that requires constant bug fixing, or is so overly complex that the thought of modifying it makes you want to cry. Some projects truly require that level of complexity. But in my experience many do not, and once you've gained a solid understanding of the problems it is trying to solve, incremental refactoring is a fantastic way to improve the code's stability and maintainability. This is especially true in C++.

mark-r 4y ago
>> People abstract before an abstraction is necessary. > This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. I worked with a guy who did that. He had a plan for what the project would look like 5 years down the road, and he built abstractions to support that. He could get away with it because he could hold it all in his head and it all made sense to him. When version 1 was half finished he was called away to work on another project, and those of us who followed in his wake struggled to make any sense of what he left behind. A year later he was laid off. The project was a success, but nobody ever asked for version 2.
zelphirkalt 4y ago
> This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. Mastery will be, when you write code in a way, that does not impose unwarranted limitations from the start, and still keep it readable and only containing mandatory complexity. Usually this can be achieved through deep understanding of the problem, mapping to simple concepts or finding or making that one concept that captures things well. Not always it can be done. Not always can a masterful solution be found, which keeps complexity low. However, it is definitely a mistake to draw a black and white picture of "if you want to make it work for the future, you must add complexity". Often people simply choose bad abstractions or wrong ones and will only realize, when the future has become the present and the system they built cannot fulfill some requirement.

he0001 4y ago

> One person's beauty is another person's mess. This is so true. Also I believe that when the original author wrote the code he had a (hopefully) clear vision of the solution. He wrote it as tidy and fitting to the problem as he saw it. Then sometime later someone else comes in and is supposed to alter the code in a way which does not fit the original author’s idea of the problem. This creates a mismatch. The new guy can’t and won’t change the code too much, as it is too risky/much to do and therefore will only do as little as possible to make his change. Then some other comes along and do some more changes, which again isn’t enough etc etc, et voilà, you have a ball of mud that screams of a rewrite.

hikarudo 4y ago
Spot on. You've described Peter Naur's "Programming as Theory Building" paper exactly.

pyrolistical 4y ago

> I tend to write reference implementations of everything, then combine them together as a separate project. This is how I write software. My stackblitz is full of domain independent experiments https://stackblitz.com/@Pyrolistical https://stackblitz.com/@Pyrolistical. I then copypasta this into private projects once I figured out how the individual piece works.

josephg 4y ago
Yeah I love this approach too. I’ve been learning CRDTs lately and I’ve gotten so much value from making tiny, inefficient reference implementations of things before diving in and optimizing. Toy implementations shake out all your misunderstandings of your design, and you can refactor like crazy. Going from simple code that works to complex code that works is much easier than creating the complex code correctly from scratch, in situ.
- pyrolistical 4y ago
  Also I've discovered (and reported) so many bugs when I realized my very simple toy example was broken

OJFord 4y ago

Is it deliberate that your comment itself is like an instance of the methodology you describe? Small separate stand-alone thoughts vs. a well-understood description (harder to write, to consume) in longer form commentary? That's not a criticism at all by the way, I just found it striking.

samsquire 4y ago
It was accident and not deliberate but you may reveal how I think. Thank you for this insight. In hindsight if you focus on three questions: is it good? Is it right? Is it true? You'll head toward a good direction Synthesis of ideas is really important and the building blocks of understanding are fascinating. Programming and mathematics is taught as building blocks and then deliberate practice. I really enjoy reading plain descriptions of things, especially of other people's code. If you understand the core insight, difficult things can be easier to understand and apply for you. I really want to understand how tracing compilers work and LuaJIT, JVM and V8 but I found the code a bit too hard to understand as I jumped into the wrong locations. There has been two instances where Wikipedia was enough for me to understand and write an algorithm that implemented the description. Wikipedia doesn't have pseudocode for multiversion concurrency control but it does have an accurate if subtle description. I did the same for btrees but I did read some other people's implementations to get a feel. I of course wrote mine completely differently. I want people to document their code enough so that the core principles or idea behind their code could be reimplemented by someone else just by reading the description of how it works. Rpython and Pypy documentation is good but I still don't understand it enough to implement what it does. Which means I'm missing some detail or core insight.

spaetzleesser 4y ago

"In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code." Same for rewrites. Often the rewrite will have the same number of problems, just different ones.

joe_the_user 4y ago

One of my recent coding experiences was teach a friend in grad school(MA) to code sufficiently well to finish his Master's project. Refactoring was absolutely necessary for this. He was writing a single simulation program that was single file in size. But once he'd created ten subroutines all changing a raft of the global variables, the slightest changes produced hair-raising bugs that he'd obsessively dive into debugging. The intuitions of structured programming and object oriented are more important than absolute fidelity. My points were: "If you can't have an object here, at least have a well defined, standard interface to values that need to be in a consistent state" and "decompose long action sequences into subroutines and if you can't do that, least group similar actions with similar actions in that long action sequence". Which is to say a given piece of code might not the structure you want but if has a structure, that can be enough. But then again, that piece of code might not structure at all and then rewriting it really is necessary and often is easier than debugging it a few time. And working with a large piece of "bad" corporate code, I've more than once that you something with one sensible if idiosyncratic structure that was refactored more than once by people who didn't understand the structure and imposed their own structure on just part of the code. But through an exercise in archeology, one can make the whole artifact work. But that doesn't mean you can't have code that is a true mess when the writer has no experience and no concern with structure.

galdosdi 4y ago

What a great way to do it, too, because once you're done, your "reference implementations" can later serve as test harnesses if need be. > I tend to write reference implementations of everything, then combine them together as a separate project.

pmarreck 4y ago

No mention here is made of test coverage (hopefully because everyone already knows); to refactor without near-100% test coverage is insanity.

intelVISA 4y ago

Generally most of my refactoring is cutting out code; I love an excuse to chunk down excessively verbose classes.. maybe I'm weird but I generally prefer a lean, concise codebase that might share a few free functions than a perfect OOP pyramid.

jb_s 4y ago

>I find single file dense leetcode style code easier to understand I find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff. For reference, my cognitive abilities are heavily skewed towards verbal/abstract reasoning - like several standard deviations above the norm - and my spatial/concrete reasoning is nearly the inverse of this, it's terrible. I wonder if this has something to do with it!

ParetoOptimal 4y ago
> find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff. Understanding lots of code at a module, function, or even more granular level with a magnifying glass feels more productive than struggling to understand the full picture. It also rewards you with instant gratification. Reading and writing ncrete code gives much more immediate gratification.

ParetoOptimal 4y ago

> People abstract before an abstraction is necessary. Sometimes an abstraction cuts to the core of the reason why. See for example https://algebradriven.design/ https://algebradriven.design/ Good abstractions can communicate intent better than mounds of concrete code because they speak at a higher level. However, mounds of okay concrete code is way easier to deal with then poorly thought out abstractions. This means pragmatists get little practice in abstractions, where their pragmatism is needed most to uncover the useful abstraction and avoid the overly complex invented abstraction. Abstract code also has the advantage of parametricity in strongly typed programming languages.

samsquire 4y ago
I started designing an algebraic language by writing code. https://GitHub.com/samsquire/algebralang https://GitHub.com/samsquire/algebralang It's designed to be expressive and powerful and practical. The core insight to a problem is rarely what we spend most of our programming time doing.
- ParetoOptimal 4y ago
  > The core insight to a problem is rarely what we spend most of our programming time doing. I believe that is a mistake. I'll have to check your language out though!
- arunix 4y ago
  Are those code samples formatted correctly? (they are difficult to read as is)

ransom1538 4y ago

If you are out there and WANT to write terrible code, An amazing essay: https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Unmaintainable%20Code.html https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un... I cried the first time i read this.

codethief 4y ago

> In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. That's a great point. I once read (here on HN I think) that the value behind a piece of software is not the code but the team whose members all have the same mental model of the problem and can successfully map it to the code. Lose the team and you lose that map. > One of the first things I do when I study a new codebase is find all the entry points I follow the same strategy but… Good luck with that when you're facing a Spring application. :)