Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet anyone who actually values replaceability. I don't even mind some repetition of code so long as groups of code aren't tightly-coupled and parts of an application can be easily replaced with rewritten versions.
I had a boss once who was dumbfounded that I actually wanted to refactor code. I guess a lot of people want to write things "perfect" from the very start, but that perfection seems to be a delusion most of the time. The best way to know perfection is to see it in hindsight.
This line of discussion reminds me of a great quote by Sandi Metz, who's pretty well known in the ruby community for harping on the topic. One thing I saw in a talk of hers that really stuck with me: Repetition is preferable to the wrong abstraction.
The first thing that's drilled into a new programmer is DRY. It's easy to understand and it works reasonably well. The next step up seems to be knowing when _not_ to roll stuff up, and how to tell when you're looking at a distinct piece of logic that needs to be reified into it's own entity or function.
I usually state it as "Optimise Code for Deletion" - the best code is code that can be removed completely because that means it can be rewritten cleanly.
Indeed. I love it when the amount of money I make is tied to the quality of my code somehow. Easy to modify, easy to repurpose, easy to replace. These often make it possible to serve customers better -> more $$$
It's why I can't really take a regular job. There is no relationship between the quality of my work and what I get paid.
In my experience, even programmers are poor judges of good quality of code. Usually the criteria they are using to evaluate quality is: "Can I do what I want to do quickly?" This tends to boil down pretty quickly to "Is the code similar to code I've worked on recently?" Understanding the long term consequences of your actions is pretty tough and the ground keeps shifting under your feet. In that environment, having someone else evaluate your performance is really difficult. A manager who isn't actually working on the same code you are working on has absolutely no chance.
Lately, however, I've been trying to shift my approach to design when doing paid work: I try to make things that seem like they should be easy, easy. This is quite challenging in itself, but it's subtly different than trying to write high quality code. My goal is not so much highest possible throughput, or even programming ease. It's to make the process of programming less surprising to the paying customer. Of course, most paying customers have expectations far above what I could possibly achieve, but I see this has allowing myself room to improve.
I believe that if you are able to consistently achieve a result of "projects with this person tend to have fewer problems than projects without this person", it will translate into more $$$.
Yes, I'm always extremely wary of programmers who claim they advance so fast in the art that code they wrote in the last year or two is "garbage". It's more likely that they are just no longer familiar with that old code.
Yeah, being able to recognise the garbage I wrote yesterday is an increase in learning. It doesn't necessarily imply that I won't write different garbage today ;-)
> I believe that if you are able to consistently achieve a result of "projects with this person tend to have fewer problems than projects without this person", it will translate into more $$$.
What nonregular job do you do? What kind of code do you deal with, for what kinds of customers? If you're a freelancer or consultant, how often do you end up revisiting code that you write a year or more later?
Because only then, i don't fear refactoring later.
So i'll get my goal: Easy refactoring for fun and profit.
Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.