Hacker News Reader

Comment by revskill | Hacker News Reader

I use one rule: If it's easy to remove, then it's fine.

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.

View on HN

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.

EDIT: The Sandi Metz talk I mentioned: https://www.youtube.com/watch?v=8bZh5LMaSmE

The main problem with repetion of code is that someone always forgets to change in at least one place when the requirements change.

It's more about having only one place where the logic is defined than anything else.

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.

I love that. :)

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.

It's not much about relationship with $$$.

It's about how we could improve our life as a developer in general.

I guess we are motivated by different things.

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.

Still when I look at my old code and I see the better approaches I could have taken, it makes me think about the fact that my skills have grown

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 $$$.

Bingo.

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?

I sell my own software.

Does your software have a website?

This reminds me the talk:

https://maximilianhoffmann.com/talks/programming/the-art-of-...

If it's easy to remove, then you can think about the thing you can remove in isolation.

I think that the ability to partition code in such a way as to think about each bit in isolation is the mark of high quality code.

Reply on news.ycombinator.com