The Roland TR-808 drum machine doesn't have a kickdrum.
Instead it has a BassDrum. It's not as warm as the TR-909 nor as infectious as the LinnDrum, and it can't be tuned and it has no MIDI or swing option. But when tweaked just right it can bellow out a teeth-rattling low register note that make da cars go BOOOOOOOM.
It was a happy feature of a device that Roland obviously conducted zero market research for, in that the first run of these units actually had a longer decay time which meant it was even more bass-heavy. Subsequent releases "fixed" the decay issue because Roland didn't think to ask anybody why they would need that much bass in their drum kicks.
Little did Roland realize that to residents of South Florida there is no such thing as too much bass. When producers wanted more out of the machine, they took to opening it up and fiddling around with the factory default settings (Richie Hawtin did this once and the result was Spastik [1]). Those who were more electronically inclined took a soldering gun to the circuit board to tune the kick circuit and increase the decay time to the point of self-oscillation (it's not hard to do that -- the instructions are right here [2]).
Can you expand on that? I haven't the strength of body to endure climbing any more (though I do have a local indoors climbing wall). Why climbing? What does the rest of your WFH day look like?
Looking back on my replies a few days later I think I missed every mark I tried to hit. The arc of the "narrative" was about the nascent devops bleed into the frontend space which our team appreciates from now - but failed to make any real sense of it. I'm not a good writer.
> But how do you know these things actually improves code maintainability? How do you quantify it's effect?
Trends. Trends in Client retention, trends in fewer user-submitted bugs. Trends in error rates garnered from logs. Trends in employee retention. Simply stated, Statistics. Imagine: you code a Minimum viable product (MVP) and get to market! Then you're inundated with user-submitted and computer monitor-submitted issues (i.e. AWS alarms) – you have a "shit show" of a product. So, how do you improve this MVP to reduce the Trends of failures? The solution is expressed in the ways I outlined above (but with vigor): CI, Tests, utilizing language linters such as TypeScript's tsserv, etc. (and so much more).
> Code reviews and linting is just applying some opinions to code. How do you prove these opinion are valid?
It's not an "opinions on code", it's a culture which is predetermined by the org (assuming the culture is healthy enough to understand its necessity and/or recognize its deficiency of the same). EVERY org needs to "scale". Orgs asked themselves: how do we effectively "scale" and what is "scale" org-wise? The tenets vary, but the history has painted a portrait of domains: SRE, DevOps, Data Analysts, Frontend, Backend, Product, Systems, Networking, SDET, etc. Each is not encumbered by the need for tests/CI/pre-deploy shtuff (arguable), but is released from "toil" because they recognized scale went beyond "opinions on code."
Validity of code is tests and there are many, many, expressions of tests: End-to-end, Integration, Regression, Smoke tests, Unit, etc.
> How do you prove empirically that immutability is not just a fad like so many others?
I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil. I hope the YC community can expand on the necessity of immutability from a maths perspective (as I cannot), but it's eminently scalable (read: understandable and practicable from an FE dev perspective).
(It's late and I gotta cut off here, hopefully someone can expand and/or redact everything I've said).
I have to disagree with you on this point (and your third point)
I've seen so many examples where developers DID improve Code quality (CQ) from of the numerous automated/personal quality checks available. (Though what follows is from a Frontend dev perspective)
- CI is CQ
- Code Review is CQ
- IDE w/ Linters is a form of CQ
- `tsserver` is an real-time type CQ
- Immutability is a passive CQ
Idk, maybe Frontend-space is a world away from what you're working with every day, but CQ in my domain has both technological and cultural tools available before code ever reaches the end-user.
> So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money.
This is really interesting to me as a problem statement: how can devs unfold/make known the value of CQ as a critical function in this math? (I don't have an answer, but I think about it a lot). What are we not sharing – or, worse, what methods/language/etc. are we using that don't fully translate between teams?
I feel it's the job of the org to be able to identify this kind of bottleneck. What position within an org is responsible for explicating the properties of this kind of issue? (Again, I don't know)
Thank you for sharing; your insight is human and approachable.
I'd like to ask, though: looking back, what were (or have become) the best resources to you - read: books, articles, conference videos, etc. - which have unequivocally helped you in the years since?
Absolutely stunning work. Love that it's able to work so well with TS. Also please tell Puppetmaster Pumpkin 'Hello' on my behalf and give some head scritches :3
My (layperson) estimation is that Apple knows the rewording of it is liable pass both House/Senate in some way either in the 2022 or 2023 sessions and are attempting to get ahead of the issue. (most likely as a "rider" bill at this point)
That's my thought process on what may have precipitated Apple's move toward "CSAM"; and I welcome it in some ways (unequivocally, children should not be subjected to sexual abuse) and am wary of it in others (ML is in its infancy in too many respects, and if a false-positive arises who's to say what's liable to happen on the Law Enforcement level).
There are infinitely many concerns to be discussed on both sides of this argument, and I want both to succeed in their way. CSAM, however, feels like an attempt to throw a blanket over Apple's domains-of-future-interests while playing an Altruism Card.
One thing is certain, though: they've opened the floodgates to these discussions on an international level...
So I thank you for sharing your thoughts because what you stated gave me pause: I agree with you in part, felt your conclusions are linked in a way, but it's clear that I have a long way to go to understand the topic.
That said, and from the article, "Coincidences involve juxtaposition and incongruity, but they aren’t counterfactual and don’t involve pretense." The syntax/logic statements in this sentence make my head spin :(
Beyond the book linked, if anyone has further suggestions on readings on Irony please share. Thank you.
What really jazzes me here is this:
> "(People learn this stuff via the number theory gossip grapevine apparently?)"
With the panoply of dev-oriented social platforms I find it curious that – to my knowledge – nobody who's studied Number Theory, Category Theory, Set Theory, etc. have established a kind of social network for sharing ideas formally.
Between LaTeX for Markdown and the limitless Compsci-leaning Maths experts you'd think there would be a thriving online community out there!
I only have an undergrad's (very limited) understanding of these topics but feel the ability to create a network for effective communication on these topics is 100% doable.
(Isn't this the kindof thing the DAT and IPFS protocols were supposed to solve? P2P protocols/networks for bettering communication?)
I've seen Notion discussed on HN for a time now, and while this seems to be well received I'm not really sure what it's for.
What are the use-cases here? What's Notion being used for that this new API functionality will help in? How are you using it either personally or professionally?
https://www.cs.cmu.edu/~dst/LispBook/book.pdf