robust-cactus

Lots of great answers here, the other thing I'd say is consumers are not Ticketmaster's customer the promoters are. 75% of the time that prompter is livenation which is now merged with them, who they themselves went on a promoter acquisition spree. The rest of the time people pay Ticketmaster to be the bad guy.

Can confirm, recently saw all the dick etchings in the wall in Pompeii

Happened to me too, I was surprised when it just stopped hurting one day and healed

Aside: My wife recently had a kid and the experience taught me how much work gets done to you just because you're being monitored that you may not actually need. You definitely need to know your own body and trust yourself to some degree. At least pregnancy is having a resurgence in "natural" birth.

Is dentistry the same? I could see this as plausible. My assumption at times has been that people's teeth all just fell out immediately before the 1900s lol, which is probably further from the truth

Eh - sometimes you gotta solve hard problems and no amount of simplification is going to net good results.

Works fine until you try to do it on a mobile device

The only thing I want out of some of these tools is either teaching or giving me out of the box configurations that help me get a reallllly good mix. Why shouldn't every record today sound pro? Talent aside, I think they should be implementing some the typical tricks sound engineers/producers use automatically.

I mean we're really talking about wave analysis then cutting of frequencies, boosting others. This can be automated based on a desired "genre/sound".

OK will give it one more shot - been trying different things here

This is awesome, the only thing I'd recommend tweaking is that $ global. I think every post using this would have to explain it to its reader.

Two options: 1. Make every exported function a global, or just look like a global. 2. Force users to import and name the blocks

I think option 1 for this use case might actually be just fine.

There's another fundamental problem we often don't talk about. It takes years for developers to learn how to accept feedback and even longer to know when to reject it.

Comparing this with designers, they go through rounds of feedback constantly in college. They come out as feedback/revision machines.

That's my point. They fixed and defined the ecosystem which is great. I feel like everyone is forgetting what a mess Node is right now.

At this point, given the state of module loading on node and other ecosystem problems, my reasons for switching to deno (or bun) are dwindling.

Ok so, different take - if this what people call "gaming the system" I'm all for it.

All this article says is that hackernews likes interesting, informative posts that actually tell a real story. And I for one am here for that all day. So yes, everyone take this strategy and make great content.

I don't let myself burnout anymore. And I'd still say I work hard afterhours. I think what happened for me was disconnection from my sense of purpose mixed with being overworked leading to a "what's the point" vibe.

1. It probably took me 3-4 years in my late 20s, early 30s to recover. I just worked 9-5 then.

2. For me "work-life" balance as a concept was even causing me stress. It conflicted with my sense of purpose. My advice is to actively prune and reject advice/suggestions that weigh on you and disconnect you from who you are.

3. Jiro dreams of sushi as a movie saved me. It reminded me of who I wanted to be and what I want to do with my life. This 90 year old is a sushi making expert works day in and day out at his craft. How does he have that energy? This isn't about hustle it's about motivation, inspiration and deeper purpose. So I recommend finding yours or reconnecting with it!

Ya def take a break, but I think there's often a deeper issue that's being exacerbated by being over worked. For me, I feel stronger than ever, but as others have shared, I feel like a different person. There's definitely pre-post self.

> innerText is hard to spec

I think this post basically spec'd it, did the competitive analysis and outlined a clear why tho!

How do these standards processes work? It seems like there's demand.

The history here is a little misleading. Client side bundling happened before node/npm. It's a performance optimization to reduce the number of requests the browser has to make. Typically people were just concatenating files. Concatenating was a painful dependency management challenge for larger code bases. Subsequently there were module systems like requirejs that also sought to fix some problems like these and ran without a build step in dev. Browserify really changed the perspective here and people started to think a build step wasn't sooo bad.

I do think, based on the requirejs code that commonjs/browserify didn't really need to be compiled anyways.

Also fwiw, the technique mentioned here is a way a colleague and myself introduced babel to a large company as well, we just transformed + reverse proxy cached in dev. And fwiw, webpack basically does this anyways these days.

It's definitely fraud and it's definitely detectable when a 10000 block prefix of numbers sends 100x more SMS than every other prefix out of the blue.

It's basically a referral marketing campaign where the fraudster does revenue share with local sketchy infrastructure providers.

That's my point - all these things get labeled as tech debt. Sounds like we're agreeing

One of my favorite quotes from a former colleague is "conversation creates its own weather patterns". For me, anytime if seen the words "tech debt" thrown around it starts to just weigh everyone down. People just start repeating the words over and over for all sorts of very tractable issues. The amount of time I've seen it falsely attributed/claimed is obscene.

1. Switched to microservices or a new language or anything more modern in 1 part of the codebase? Yea everyone now calls anything not that tech debt.

2. Have a performance problem and want to add more features? "Tech debt"

3. The code is just bad - "tech debt"

In all of these cases I feel like clean-up should just be constant and mostly opaque. The campfire rule is so great for these things - "just make the campground a little better than when you got there". It often does not take more time to just clean-up as you go. Then once you have your barings on a certain part of the codebase bigger changes will seem smaller and you can fix those up as well OR buy yourself that 2 weeks with a specific plan/ask. Eng cultures that worked this way seemed to work the best.

Separating signal from noise is going to be interesting here. Startups founded by friends, former co-workers or network all fail. Exiting isn't guaranteed, nor is product market fit or any amount of success. Most startups fail.

Yes it will be cool when we can see stats like "co-founder matching has created X startups, and you're Y% more likely to succeed." Those stats take time to reach significance. For now, it's OK for it to ride on vision + early indicators like "# of startups founded".

I've heard it works and it has caused companies to form and get funded.

I signed up like 1 week ago and I'm a 2nd time founder. It depends on your expectations and how you configure it is my read. For me, even though I'm technical, I'm mostly looking for other technical founders. Other than that, the thing I mainly want to feel when I read a profile is a sense of "oh this person would be fun to jam on ideas with" and in addition, "yea I think they got the same level of hustle/urgency as I do." Concurrently, I want to get a sense of the person's motivations - are they all about the $$, I'm a pass usually in that scenario. I just want to build something people love.

I think I've already seen a few people who match that criteria.

Aside: kinda worried about how many people are looking to start an "ai startup" rather than solve a problem which might involve AI.

Interesting fact - valve no longer works this way because it didn't work.

I've literally never experienced this with react. This sounds like an infinite loop of some sort.

Waiting for Jeeves to enter the chat

Another one, desktop webviews don't exist either. Everyone does something custom right now and there's an epic vent fest in one of their GitHub issues. This causes about 1 new package to get released every few months too that tries to address it.

I mean making the price of iron and other materials crash has value in and of itself. All of a sudden a $100M skyscrapper could cost half as much or something. Yet the end value of the product would still be worth just as much.

There's no real benchmark for developer experience. Performance only matters up to a point. And it depends what you're building. If you're building pages where people just read content - sure - server render + vanilla js it. If you're building something more interactive where you think you'll have greater than 50k lines of JS prepare for pain.

Last note - picking the right tool for the job is a quote we repeat often in the industry, realistically though that sort of optimization actually makes it harder to reason about writing code especially in a large org. The great thing about these frameworks is that it's a single way to build and you get server and client rendering. I remember back in the day folks would ask "how do you build a page here" and it would kill me to say "it depends I have 10 questions for you"

Hmm instead of patching node, is there any tech that lets you make a virtualized file system on top of existing files? With that we might be able to design a system that resolves some of these module requests in a better way.

You're working too hard. Just make a linter or auto formater do the work. Agree on the rules. If the rule doesn't exist don't comment on style. You can make/debate new rules but don't mix it into code reviews - separate problems.

As a manager:

1. The most value I get is when people complain. It can be about the tech stack or about processes or lack of change. I then choose whether to solve the problem or teach the individual how to solve (coaching or teaching).

2. When the individual uses me to make organizational change happen. This usually happens with managers or staff engineers.

3. Gives me enough context to pull on threads and refactor the organization.

If you don't wanna do any of that and we don't even have fun stuff to talk about (once a month'ish) then I end the convo early.

Also, I often tell employees that it's their time, not my time and to come armed with topics and I'll do the same. But not everyone does this so I end early maybe 20% of the time.

Even if it is similar, target audience matters