Comment by franciscop | Hacker News Reader

Comment by franciscop | Hacker News Reader

This is so well written, I just wish it expanded a bit more in the end. I'll tell my experience rocking from one side to the other:

When I started as a self-taught programmer I was basically fighting the code all the time and reading about these better practices and all. I followed a top-to-down learning focusing first on the deliverables. As I started learning more and more and constantly struggling with my own code, the ideal implementation (of course involving OOP) seemed further and further far off, always elusive. You could always add an extra layer, an extra abstraction here and there.

At some point I realized I was lost in an abstraction sea and not getting anything done. I abandoned some of the projects at mid-size and made https://picnicss.com/ as an example of the opposite. Oh boy, what a difference. A single stylesheet made in few days with great adoption and feedback from the community. I just saw a video of Google IO 2017 and they used it there in a demo! It also helped that I switched from PHP to Node.js around that time.

So I kind of got hooked to that. I have made quite a few tiny-sized, one-off projects ( https://github.com/franciscop/ ) and learned a lot about this quick-iteration coding. I wouldn't say it's the same as the OP's description of nihilist since that seems to be based on a large codebase. What I made was nihilist in the sense that some projects superseeded the previous ones. Example: first I made https://umbrellajs.com/ , then decided to re-implement it all and created https://superdom.site/ with an alternative syntax.

Now I think I've found a balance in the middle as I'm finishing https://serverjs.io/ ; the library's public API should be fairly stable, but the implementation details can have their shortcomings and be kind of messy at places. To finish off with a great saying for the situation:

Perfect is the enemy of good.

"Perfect is the enemy of good"

Could not agree more. Self taught programmer here too. For such a long time chasing "perfection" had me stuck where I was not finishing any projects.

Taking a step back I decided that finishing projects is what really gives me happiness. They don't have to be perfect or world changing. That coupled with detachment from how the project is received has helped me so much.

Congrats on all your projects. Inspiring!

Same here. Although it was rewarding to write "perfect" code, getting constantly hung up on the tiniest details was quite a soul-drainer.

Nowadays I see more beauty in the end product and refactoring. I still keep that idea of perfection in my mind and do my best to write good code from the start, I just don't let any of it become a blocker.

I'm more efficient, stress-free and productive as a result. And I don't feel as repulsed when working with other people's code.

Good thing you do not work on security or real time critical or life critical applications then.

Seriously, the only kind of perfect code is the one that has been proven correct. Or in fact the proof itself.

Otherwise you're talking about "code we think does the thing and looks nice".

In many, many circumstances, code that "does the thing [well enough]" is more than enough. Not everyone works on avionics or pacemakers.

I enjoyed your comment, and just want to point out that there are two separate issues at play here:

1) The quality of the end product (what the target audience sees and interacts with)

2) The quality of the underlying implementation (the hidden stuff that makes it work)

They are not completely independent (e.g. uncertainty in the product design has strong implications about time spent polishing the code). But the distinction is important, and it can be worthwhile to analyze them separately.

I've cottoned on to the idea of focusing on feedback loops instead of "practices" lately as a way to deal with the kinds of evolutionary changes projects tend to go through.

Practices tend to emerge within a specific project situation as a pragmatic way of addressing concerns. When the practices are communicated across projects a game of telephone is played, the nuances lost, and the meaning is eventually replaced with dogma.

Consider which would be more useful: a workout log that suggests how much additional difficulty you should add each week, or a fixed plan found in a magazine that says that you should be performing an exact workout in each week?

This is the struggle I think programmers really face, because the codebase at any moment in time needs an appropriate "workout plan" to successfully reach the next stage. Sometimes a form of cheat can be used to accelerate it towards a goal, but the concrete progress is reliant on a similar formula to progressive overload cycles.

This focus on feedback also guides healthy cutoffs between prototyping and production solutions: the production solution only makes sense once prototype learning has been done, and the prototype likewise stops making sense when it conflicts with the demands of feedback.

Besides "perfect" and "good" there's also "better" and as long as you can do that, your results are guaranteed to improve.

I would even go as far as to say that, if you do the same thing over and over again, you can only avoid getting better at it if you try, really hard, to be worse at it.

The original English saying was with "better" instead of "perfect". That said, both have the same meaning: you can keep improving it forever, there will always be a "better" way of doing it.

What I think it means is that you have to know your objectives, as everything is a trade-off. Time you spend refactoring is time you don't spend testing or documenting it, for instance. Or it might be better to have two features at 90% "perfection" than one at 99%. Or spend that time with better marketing/landing page/etc.

Reply on news.ycombinator.com