jsbg

> Is this goodbye to @ElonJet?

No. [0]

[0] https://twitter.com/elonmusk/status/1589414958508691456

"The truths of mathematics would be the same, because they're true by definition" means that "(x => y) AND x" means y is true based on the definition of => and AND. There's no "philosophy" behind this.

I hadn't heard of it but it's a good rule! There are too many examples of code that was abstracted out to be shared between uses that end up evolving independently, and the abstraction ends up with a bunch of if-statements and confusion.

> over-refactoring into tiny one-line functions

It's relatively rare to refactor a single line of code into its own function, unless it's really hard to read, e.g. some nasty regex.

> even if they're supposedly so self contained you don't need to look at them individually - that's rarely true in practice

If a long function is broken up into smaller functions only for the sake of having smaller functions, then you end up with functions that don't really make sense on their own and, sure, the bigger function is better. But if the broken up functions are named well enough like in the example above, then it shouldn't be necessary to see how it's implemented, unless you're tracking down a bug. After all, it's very rare to look at e.g. how a library function is implemented, and for some libraries/languages it's not even possible.

> When faced with a file with dozens of tiny functions, it's much harder to get a top level understanding than if it has a smaller number of longer functions.

Most languages have facilities to help with that, e.g. function visibility. Your smaller number of large functions can remain the public API for your module while the "dozens" of tiny functions can be private. In either case, long files are harder to take in no matter how many functions they're composed of.

> If breaking up the code makes it slightly less easy to understand right now, but will make it easier to add some feature later that you know you know you're definitely going to need, then hold off.

This. Your code shouldn't be documenting what it will do in the future: it should be clear what it's doing right now. Otherwise some other engineer maybe from another team will come upon it, misread it, and bugs ensue. Trying to save yourself time in the future ends up wasting time for others, and likely for yourself as well.

Into the Inferno - Werner Herzog. Documentary on volcanoes where the director allows the filming locations to bring other topics to the forefront.

Lo and Behold, Reveries of the Connected World - Werner Herzog. Film about the internet.

The Thin Blue Line - Erol Morris. Film about a murder of a police officer that comes to a different conclusion than the court did about who the murderer is and led to the release of an innocent man and the incarceration of the guilty one.

The Civil War - Ken Burns. There's a reason it's a classic!

Good Intentions - Walter Williams. Film about how economic policies that sound good often have the reverse effects that they intend to have.

tl;dr: the algorithm splits the audio into blocks (default is 4096 samples per block). Then a polynomial is used to approximate the wave for the block, and residuals are calculated for each sample by subtracting the approximation. The residuals, because their magnitude is smaller than the original signal, require fewer bits to encode. Hence the smaller file without loss of information.

> There's nothing more demotivating than spending 8 hours on a problem, feeling good about your solution, and then having some "senior" developer come along and tell you to rewrite it "for readability."

While a senior engineer just asking you to rewrite it without further details is bad, it's good practice to follow the "make it work, make it right, (optional) make it fast" approach. The "make it right" part is where you make your code readable after you've ensured that it works and before you submit it for review. If you find later that you need to make it fast, it is expected that readability will have to be traded for performance.

What's wrong with dry air in the winter? Humidity + cold is unbearable. I'd much rather have to put on lotion.

Someone wrote an implementation of COMEFROM (a joke response to the Dijkstra article) along with GOTO in Python for an April fools' day joke as well.

https://en.wikipedia.org/wiki/COMEFROM

Tea contains l-theanine, which, when combined with caffeine, has been shown to improve concentration. You can get the same effect by drinking coffee and taking l-theanine pills.

This part, though somewhat unrelated to the topic, is pleasantly insightful:

> Saying yes as often as possible is, famously, the first rule of improv, vital to maintaining energy, imagination, and humor. It is also, I have long thought, a sure sign that you’re falling in love, not to mention crucial to sustaining that love over the long haul. And, while sometimes impractical, dangerous, or just plain dumb, saying yes to as much stuff as possible is, over all, a pretty good strategy for getting through life.