Ask HN: What change in your programming technique has been most transformative?

Order has as many flaws as disorder. There's a balance in between.

Many of us are familiar with that balance in our daily lives; e.g. we don't mop the floor so clean we can eat off it. But code is often continually polished, refactored, documented as soon as there is the slightest smell.

We do keep tidy enough. The standards for office cleanliness never qualifies to surgery standards, and yet a lot of people like to compare their code to medical device safety levels.

Besides that, there is a clear structure to mess. Too much or too little order and you lose control. The right amount will give you the correct structure.

This is exactly what I do, with one addition: Sometimes I don't check everything in as I go because I'm doing a lot of experiements at high speed. However, I will locally do "junk" commits for trivia such as comment typos and short, obvious bugs that are noticed.

At this stage I don't worry much about the commit message, as it's purely local, and many of them will be squashed (discarding the message). So the trivial ones get one-liner messages like "WIP: Adder: Comment fix" or "WIP: Parser fix '...', needs testcase'. "WIP" commits are a useful tag for me: They are never allowed to be pushed to a shared repo.

Then the "git add -p" stage.

When a task, feature or bug has been dealt with, I'll start using "git add -p" to separate out parts of files, and commit them as logically independent changes. At this stage, I don't mind separately committing even very scrappy little changes, such as comment typos, as separate commits because I will merge them later. The key is to separate out logically separate kinds of things in the delta from worktree to HEAD. During this I will usually find a few things that are untidy or comments that could be worded better, and add tiny commits for those changes.

The "git add -p" stage is a great time to get some perspective on what logical units were actually needed for the main task, and what else was refactored or fixed in passing, and this "pick up the pieces later" method frees me up to fix things and do small refactors without having to switch context while doing it.

Then the "git rebase -i" stage.

When the adding is done, "git rebase -i" to reorder into a sequence of logical, coherent and explainable changes. Ideally in an order where things still work if they are partially checked out in that order (bisectability), and squash together separate "git add -p" chunks that really must be one logical unit. Also, squashing trivial fixes such as typos in comments, whitespace etc into logical commits.

I may then go back and clean up and flesh out some of the commit messages before pushing the lot upstream for review. Or, in practice, there's usually no review of my work other than testing it, but so that others can at least read through the commit messages and patches to see what was done and how; hopefully learn from it.

The above cycle is usually done about every 1-2 workdays, but it can be longer if there's a tough problem being debugged or a complex new feature (but for big new features a branch is more useful). If something turns out to be too big, though, it doesn't matter because I can always commit any work in progress to a new local branch or stash, and rewind back to a stable worktree.

The final, logically coherent and documented set of commits is very satisfying to push, and rarely contains "junk" commits or unexplained changes, even though what I commit locally at first is often like that. I guess it helps to know Git quite well.

KISS + YAGNI + constant refactor. Code is a means to an end and I suck at futurology.

Yes, learning other paradigms is useful.

For me, introducing immutability of data (functional paradigm) helped clean up many interfaces and made the code feel resilient. I realized I rarely passed the input data back to the caller (it was often a new and different structure). At the end of it all, I was somehow more confident in the 'run time' of the app and reasoning about issues is much easier. Currently I am not using any language features to enforce immutability - I just code the receiving function to not change any input structures (or in rare cases, return a new one). I suspect there are some exceptions lying around but having most of the code behave this way has helped.

No, the one I saw was different. They were walking around the world and shooting stone building walls. They also weren't part of a conference. The video was just their screen split with their code on one side and the game window on the other. I'm pretty positive it was Common Lisp too because I think I was looking for SLIME videos at the time.

Thank you for the links.