xenomachina

> I especially dont see what is gained by writing the test after.

I assume you mean versus writing it first, rather than versus not writing it at all.

I've found that TDD works well for bottom-up coding, but not so well for top-down.

With bottom up, I can write the test for a piece at the bottom, write the code to pass the test, and move on. With top-down, if I write the test first, it might be a long while before I have that top-level working, because the bottom bits don't exist yet.

When I feel it's better to write things top-down, I'll often use TDD for the bottom bits I need to write, but for the bits above that, I'll write the tests "on my way back up".

How?

s/Below/Above/ ?

Sure. My point was just that contrary to what programmers typically think, people don't use binary search to look up things in a dictionary.

Or a web app?

When people search through alphabetical listings, they usually don't use plain old binary search, but instead use something like interpolation search. For example, if you want to find the word "xylostroma” in the dictionary, you aren't going to start in the middle. Instead, you'll start about 90% of the way through, and then make adjustments based on how far off you were.

About 20 years ago I had two computers at work: a Windows PC and a Sun workstation. I used Vim on both. I knew about the vi ]] command, and I'd learned some Vim script. I thought it would be great to have a key binding to take me to the innermost surrounding curly braces, so I wrote a vim script to do this. I picked ]} and [{ as the key bindings.

One day I used the key binding and then realized a few minutes that I hadn't installed the script on that computer yet. After some searching in :help I realized that I'd not only reimplemented a feature that already exists in vim, but I mapped it to the exact same keys.

One other thing in recent years: if you used Stripe Atlas to get incorporated, they made it very easy to get an SVB account.

I agree with most of this, except:

> 5. When merge happens a dev's PR is squashed into one commit that gets appended to `main`

I don't know if GitHub supports this, but GitLab has a semi-linear history feature. When enabled, it won't let you merge unless a fast-forward merge is possible, but it never does a fast-forward merge.

This give you (IMHO) the best of both worlds: your history is pretty linear and easy to reason about. The "first parent" of each commit on the main branch is a linear chain of the main branch history. However, for more complex changes you don't have to squash. Those intermediate commits will be on the second parent of merges, so they're easy to filter out:

    M─┐ [main] merge
    │ o commit
    M─┤ merge
    │ o commit
    M─┤ merge
    │ o commit
    │ o commit
    M─┤ merge
    │ o commit

> If you want interactive rebase then make 2 PRs.

What do you mean?

> Yes, it can be annoying if your developers are committing nonsense, but then just tell them to not do that, or to rebase locally before pushing.

I'm pretty sure rebasing locally is exactly what the person you're arguing with is arguing for. The original comment in this thread was saying you should never rebase, always just merge.

Years ago, a friend and I talked about a similar idea. We called it a log file "audiolizer" (as opposed to visualizer). The idea is was you'd tail log files through it, and it would produce sound based on the log lines. The hope was that you'd learn what things should normally sound like, and if it started to sound "weird", you could investigate.

Even C89 supports block-level variable declarations. I think many C programmers are unaware of this, though, and mistakenly think that declarations are function-level only.