3 ms·

Bracing for down votes but I think that’s garbage. Once the system has been precisely defined in code (even poorly, especially when poorly!), refactoring it is

Bracing for down votes but I think that’s garbage. Once the system has been precisely defined in code (even poorly, especially when poorly!), refactoring it is a much smaller task, it’s also a ‘smooth’ problem (there are no hidden problem mountains that sap your drive as you discover your expectations were way off week after week) because the problem is all there in front of you, in ascii. You are also motivated to look good because people do mis-compare these non-comparable tasks. I’ve refactored my own code, I’ve refactored others’ code, I’ve had my own code refactored. Every refactoring iteration is almost always a lot faster than the last, and there is almost always a benefit in performance, though maybe only iteration #2 provides a really big boost when #1 was a rush job. You just need to be a good engineer who knows how to write well organized, well patterned, and performant code. It’s important to remember that engineering, like design in general, is an activity done under time constraint, every iteration is an opportunity for more time, and it’s also a fresh break/perspective on the problem. I love refactoring code.

gumoro 8y ago
It's not just about code. In any non-trivial system you have a bunch of components, and any minor occurrence of "bad design" that affects boundaries, protocols, configuration, deployment, persistence schema, upgrade procedures, etc, can lead to huge complications down the road if there's no one to catch this early. Mediocre engineers will only make it worse and worse, and you'll get something super complex that costs big bucks to maintain. If you have someone capable of detecting & fixing such bad patterns early enough, in extreme cases that person can be considered a 1000x engineer.
rifung 8y ago
I agree completely. Also I feel what usually happens is that requirements change over time, and things get repurposed as "hacks" because ain't nobody got time to rewrite the entire thing. But at some point the effort to rewrite is worth it and at that point even the same engineers who did the original implementation should be able to write a much cleaner and faster version. When I was new I thought I was so awesome when I saw how I could write better code than I read. It was only way later I realized people usually had good reasons for writing it that way originally but those reasons disappeared.
MauranKilom 8y ago
In my experience so far, good code strives for elegance. Not only "few LoC" but elegant design, abstractions, structure. With a sufficiently awful design (and "wild growth" by engineers just trying to add features), refactorings become tedious because the dependencies, interactions, assumptions etc. that have grown over time are painful to untangle with only equivalence transforms of the code in between. And you can't change easily change the other side of whatever the code interfaces with because it's similarly ingrown.

gumoro 8y ago

It's not just about code. In any non-trivial system you have a bunch of components, and any minor occurrence of "bad design" that affects boundaries, protocols, configuration, deployment, persistence schema, upgrade procedures, etc, can lead to huge complications down the road if there's no one to catch this early. Mediocre engineers will only make it worse and worse, and you'll get something super complex that costs big bucks to maintain. If you have someone capable of detecting & fixing such bad patterns early enough, in extreme cases that person can be considered a 1000x engineer.

rifung 8y ago

I agree completely. Also I feel what usually happens is that requirements change over time, and things get repurposed as "hacks" because ain't nobody got time to rewrite the entire thing. But at some point the effort to rewrite is worth it and at that point even the same engineers who did the original implementation should be able to write a much cleaner and faster version. When I was new I thought I was so awesome when I saw how I could write better code than I read. It was only way later I realized people usually had good reasons for writing it that way originally but those reasons disappeared.

MauranKilom 8y ago

In my experience so far, good code strives for elegance. Not only "few LoC" but elegant design, abstractions, structure. With a sufficiently awful design (and "wild growth" by engineers just trying to add features), refactorings become tedious because the dependencies, interactions, assumptions etc. that have grown over time are painful to untangle with only equivalence transforms of the code in between. And you can't change easily change the other side of whatever the code interfaces with because it's similarly ingrown.