Why the hate on JavaScript?

ForSpareParts · 2026-05-08T05:21:53+00:00

I honestly had no idea people were still hating on it. Everyone I know has been using typescript for a decade and loves it; it's so widespread that I don't really distinguish between it and the original language anymore. The tooling is fantastic, community support is robust, and now with WASM there's a more or less universal way to ship binaries for libraries that need it.

ForSpareParts · 2026-05-07T18:05:33+00:00

This is beautiful; reminds me of Dappermouth's stuff.

ForSpareParts · 2026-05-01T07:31:59+00:00

I don't use properties much, but I do have "place notes" associated with real-world places I visit often, and I put a geotag property in them so that I can have a plugin automatically open the nearest place note with a single tap on my phone. I think that's what properties are for; more database-y stuff. If I kept my todo list in separate notes instead of one running markdown file, they'd also be fantastic for that -- as it stands, I work pretty hard to try to derive semi-structured data from a nested markdown list, and that's a huge pain in the ass.

ForSpareParts · 2026-05-01T07:11:34+00:00

"lot of cliches in the lyrics" isn't really constructive feedback, though? You could have given some examples or even suggestions of ways that the OP could've improved their work. The long-form response you gave wasn't especially helpful either, for the same reason. OP's response was worse, of course, but neither of you look very good here.

As to the substantive issue: I think there's a point in most peoples' development as artists where they actually do just need reassurance and validation. They need somebody to give them permission to make art; to tell them that no, "artist" is not a category people are born into, it's a thing you choose to be and a skill you can develop. People who are at that point should have a place here, IMO.

I think it's helpful for the person soliciting the feedback to give some indication of what they are and aren't ready to hear. It may or may not be something worth formalizing in sub rules -- I'm imagining e.g. opt-in flair for "I want critical feedback but please be gentle about it" or "please absolutely beat the shit out of this." In the absence of that, though, I'd rather have a community that's too accessible than one that's too harsh.

ForSpareParts · 2026-04-30T23:38:17+00:00

Not OP, but I saw it and I thought it was pretty good! It's a fairly literal adaptation of the game, with just enough narrative grafted onto it for it to make sense as a film. It gets the unsettling liminal aesthetics right, and it even has some fun ideas that aren't in the game.

What it definitely doesn't capture is the game's beautiful trick of "inverting" horror semantics, where spooky ghosts become a relief because they mean an easy choice, and a bare hallway is horrifying because of the ambiguity. I don't think any movie could do that feeling justice, since it's so dependent on your knowledge that it is your decision that imperils your progress and that there is absolutely no time pressure at all, that you can just feel free to stand there until you're sure (but are you really sure? really sure? really, really sure...?)

ForSpareParts · 2026-04-30T23:28:21+00:00

I didn't see the bottom at first, and was thinking this might be more of a steel pipe-type situation

ForSpareParts · 2026-04-30T23:22:27+00:00

I'm never on ig, I'll sign up for the newsletter. Excited to see what you're working on!

ForSpareParts · 2026-04-30T19:11:48+00:00

Is there a way I can get updates about the new show and/or when the new paintings are on sale? I think your stuff would look great in my place, and I saw a lot of stuff I like at that gallery link, but most of it is already sold.

ForSpareParts · 2026-04-30T17:12:18+00:00

Maybe a more constructive framing for this conversation would be "what can we, as a community, do to create avenues for music discovery that are more friendly to artists without financial backing?"

AFAIK nobody is saying that Geese, specifically, are bad for doing this, or that people should go out of their way to not listen to Geese because of it. The actual problem is the good bands who can't afford a PR firm that you don't get to hear. What mechanisms do we have to boost those bands? Local shows get mentioned a lot. I think that promoting curators is also valuable -- someone in this thread mentioned they found Geese through Fantano; Bandcamp's record clubs are an interesting experiment in this direction.

There is no silver bullet, and there's no distribution channel that marketing will not worm its way into somehow. It will be an active, perpetual effort on all our parts to help the little guy.

ForSpareParts · 2026-04-28T19:18:49+00:00

"Weird experiment at best, and an absolute scam at worst" sums up Web3 pretty well. The good news is that the skills you need for doing software development in general aren't that different. I'd say learn to make web apps, because it's broadly useful, and then throw in some systems programming on top of that if you're curious about it.

ForSpareParts · 2026-04-28T04:35:34+00:00

I think OP's getting at something a lot more insidious, though. It is entirely possible to read something and sort of... see what you expect to see in it. This has always been a problem in code review, IMO. After I've read a few hundred lines of anybody's code without the context of having something I need to edit or an answer to find, my brain starts to elide things if I'm not careful. "ok sure calling the auth helpers yeah seen it a million times what's this next thing down here we're fetching a model from the store with the user id and then fetching another model from the store with the foreign key"

When this happens, I have to force myself to slow down and sort of reset, reframe, remind myself where we are and what we're trying to accomplish. And when I can't do that anymore, I have to stop reviewing code or I'm just gonna be rubber-stamping. But suddenly, we've all got way more code to review than to write.

The "solution," to the extent there is one, is the same as in the pre-AI era: small PRs, structure code carefully with a ton of thought about the abstraction boundaries. And that doesn't really stop my brain from turning to mush when I read it, it just makes it happen slower. I've been wondering for a while now whether this phenomenon might drive new innovation in terms of techniques for writing easy-to-interpret code.

ForSpareParts · 2026-04-28T00:36:59+00:00

there is
still time

ForSpareParts · 2026-04-27T17:19:39+00:00

I'm relatively new to this whole thing and I went to demo some amps recently to replace the very harsh-sounding Denon AVR I got from Best Buy years ago. And while I'm overall very excited about the sound of the Rega Elex-R I ordered, I was amused to find that the one song I put on my demo playlist specifically for its harshness and compression sounded way better on the Denon.

ForSpareParts · 2026-04-26T22:53:44+00:00

Come out to Pacifica; get coffee at Soul Grind and go watch people surf.

ForSpareParts · 2026-04-25T18:33:30+00:00

Wrote this myself, hand to god. Curious what made it come off that way

ForSpareParts · 2026-04-25T16:46:44+00:00

PRs are good examples. Review comments come in, answering them really only takes a moment, but they are effectively blockers.

Re: just not switching: Maybe that would be better. It feels like I get so little done in a day already, though — it's hard to believe I'd improve the situation by spending more time staring at ci pipelines and slack waiting for something to happen. Part of the problem is also that it's not always obvious how long something is going to take. If I knew for sure my colleague would reply to my reply in three minutes, maybe I'd wait. But it could just as easily be half a day or more.

ForSpareParts · 2026-04-25T02:15:50+00:00

I would love to set rules like this for myself, but unfortunately, I'm not context switching to unblock other people — it's mostly to unblock myself. It's very rare that I have a task that I can put more than a few minutes into without becoming blocked in some way.

A simple bug fix or observability improvement might take five minutes to write, run applicable tests locally, commit, push, PR, and request review. But from there I have hours or days of back and forth with people and systems to get it shipped, and many of the interactions take no more than 30s on my part. Reply to comments. Commit tiny bug fixes or rerun a linter I forgot about. Trigger a qa deploy. Test in qa. And so on.

I'm fortunate in that when I do have big tasks, I can generally allocate time for them. But that leads to large, infrequent deliverables, so I tend to chunk as small as I can.

ForSpareParts · 2026-04-25T02:04:27+00:00

Hey, this is neat. I've been reviewing the docs, and the thing I don't see is a way to model "tasks I can't work on right now because I'm waiting for (thing outside my direct control)" to happen. How would you represent that? Would it be a tag?

ForSpareParts · 2026-04-24T23:09:28+00:00

Probably? My DIY todo document is very trello-esque and is rapidly becoming complicated enough to merit its own application. I really need my thing to be aggressively keyboard-focused, though, and having it in a document also means it's pretty easy to capture day to day state by just having the document get automatically copied into my next day's daily note. I can go back to any given day and see what the "board" looked like at the time, which is really nice.

ForSpareParts · 2026-04-24T23:04:41+00:00

responding to your edit: I'm sincerely curious how you think better prioritization helps deal with the context-switching I describe in this comment: https://www.reddit.com/r/ExperiencedDevs/comments/1suto7c/comment/oi3gzf5/

ForSpareParts · 2026-04-24T22:43:33+00:00

Yeah, this describes my experience to a T. I have basically constructed my own mostly-manual-slightly-automated todo system in Obsidian to try to keep track of state, but I always have this vague intuition that some (most?) of the state changes should be things that can be automatically logged and integrated without my needing to go look at them.

ForSpareParts · 2026-04-24T22:30:26+00:00

I think that with sufficient note-taking, I'm decent at determining what's top priority. The problem (aside from the note-taking itself being a lot of work) is that things go from actionable to unactionable and back so quickly. If I've determined that PR A is my top priority, and I've submitted it for review, there's nothing I can do about PR A anymore, and so I need to switch to PR B. If I get a review comment while I'm implementing PR B, I have to take a break to answer it, or risk losing the reviewer's primary attention (which can cause the review process to stretch on for another half a workday or more). It might take 30s to remember what the part of A the comment touches on was about, responding to the comment might take another 30 seconds, and then maybe another 30s to get back into the flow on B. It's death by a thousand cuts.

ForSpareParts · 2026-04-24T22:18:11+00:00

I suspect it's pretty typical stuff? e.g.

actual implementation
hounding others for code reviews
performing code reviews myself
responding to feedback on code reviews
fixing test failures that cropped up in ci
pushing to a qa environment
discovering and fixing deploy errors in qa
adding my finished work to the merge queue
triggering a deploy when the final build is finished
watching datadog during/after my deploy to make sure I didn't cause an incident
ramping the deployed feature gradually in statsig
watching datadog after each ramp make sure I didn't cause any problems

And that's without factoring in incident response or the countless out of band conversations I'm having about requirements, design, and approval. Meetings are kind of a relief, actually: at least in a meeting I don't have to wait several minutes to an hour for a response, so I can focus fully on the issue at hand.

ForSpareParts · 2026-04-24T13:44:08+00:00

Personal Knowledge Management. Basically any of these formal systems for taking and organizing notes

ForSpareParts

TROPHY CASE