atom_arranger

This is a good one. Also think about how confident you are you aren't breaking anything with your new feature, and how confident you would be that the next person won't break your feature.

I think the best case scenario here is something like the iPhone, yes the Androids did come, but they took a long time to catch up (some would say they still haven't), and owning the platform is very lucrative.

It's about being the first one to reach mass market, and holding onto that position as long as possible.

On the other side, the ops team sets up a system of slow and complicated deployments, but they don’t have to deliver features with it, they don’t feel the pain of working with it as much as the feature devs.

The other people on/joining your team probably don’t know.

If the people working with tools like ESLint or TypeScript don't appreciate what they're doing for them, then yeah they'll work around them.

I guess you need to teach people like that how they can work with the tools to get things done, with higher quality results.

For my part I very much appreciate that ESLint and TypeScript can help me write better code, they're helpful and consistent reminders. I understand that I should use ===, I understand I should check for null, but without the tools I won't remember to do it in 100% of the cases I should.

The only possible Revolution I see is not using the DOM. JS + WASM is fast enough, the DOM is not fast enough, or good enough, enough here meaning enough for creating highly dynamic 60FPS experiences. Main issue with leaving it behind is A11Y though.

I care about ops because if the ops are bad it affects how quickly and effectively I can deliver new functionality and resolve issues.

I don't want to do ops, but I will if they're holding back development.

Learning about these kinds of things is one thing motivating me to try for a big tech company job.

I want to build my own company, but I want it to have this kind of tooling, that I don’t fully understand yet.

Sounds really interesting, would love to see it used more.

An alternative is a multi step build, then running with Google’s Distroless https://github.com/GoogleContainerTools/distroless

This has saved me many times. Memory is cheap these days, this should probably be a more common editor feature, on by default.

I wonder if part of why microseconds work for some companies is the hype helps justify the work to management.

> We need to convert to microservices.

Sounds like a cool shiny new approach enabling better scaling and organization.

> We need to refactor this mess.

Sounds like complaining, why is it a mess anyways?

These two things may essentially be doing the same thing, organizing/breaking up the code logically, one just might sound more appealing to management.

There will always be incompatibilities between versions. Ideally the tool would manage its own version, maybe with vendoring. Yarn does this optionally and it works well

At least with this you wouldn’t need to manage versions of the package manager and runtime separately

What you talk about last is referred to as documentation driven development or readme driven development

I think it's great for greenfield work. Forget existing solutions, if you were looking for a solution, write out how you'd ideally like it to work, after it's written, figure out if you can create something that works like that

One of the best PMs I have had used to be a dev. The company we were working with used a terrible Jira like piece of software I don't remember the name of, but he had the devs just use Trello. He would go through and update the other thing for stakeholders. Worked great

Browsers should implement setting the preferred scheme per site at some point.

It would also be interesting if they could support more than just light and dark.

Moving into a building where I'll have Beanfield in about a week. Looking forward to symmetric gigabit for $50/month.

It is possible people who would pay to remove ads are also people who are less susceptible to them in the first place. No idea if that’s true though.

Similar to this article: The first few episodes of the Cracked podcast are pretty interesting.

> but having to write 5-deep queries (because of the edge indirections) by hand is way more of a pain in the ass than performing two GET requests with a few parameters munged in the URLs. And then I still have to go and retrieve the information 5-deep in the resulting document.

I usually write my queries in GraphiQL (check some boxes) and then paste them into the app after I have them working right.

Unfortunately there is something preventing this from working, not entirely sure what.

A lot of people have tried, and nobody has gotten 4k@120hz working on an M1 over HDMI (or a cable converted to HDMI).

Been trying to use a C1 with my M1 MacBook. I think I'm going to return it.

  - There's no way to get above 60hz.
  - Have to use an HDMI connector because the C1 doesn't support thuderbolt or displayport.
  - The sound doesn't work for some reason.
  - The TV features get in the way a bit, menu overtop of things when you turn it on.

This is all kind of Apple's fault for not including HDMI 2.1 support.

I might get something referenced on this site: https://tonsky.me/blog/monitors-mac/

I did like the move towards less ports, although it was inconvenient at times. I do wonder if Apple had incentivized the ecosystem to move more to USB-C if things could have gone better. If there were lots of monitors and TVs actually supporting USB-C/Thunderbolt it would be nice, it's a thinner nicer cable, also has more bandwidth.

IMO MS should focus on making tsc faster, browsers shouldn't have this added complexity for no benefit. This would also seem to encourage shipping extra non-functional code to users. If the only benefit is in development then that could just be served by sourcemaps.

One of the most compelling things about Solid.js is that it integrates some of React's most important (IMO, probably aside from the central idea of UI as a function of state) ideas for writing applications, Suspense, ErrorBoundary, useTransition.

We could at least be experimenting, maybe implement a $100/month UBI in one state, see how it affects their productivity/health/budget, consider trying other numbers in other locations.

Check the percent of the population involved in agriculture over time, or involved in fishing. From a quick Google search something like 90% in 1800 vs 2% now.

We definitely have machines, not saying there’s no labor involved but it’s certainly less than it has been historically. It really is similar to the village where one person operates a fish catching machine.

There are plenty of people who might still think that's bad value. Trades put a lot of stress on your body, and are not that easy, especially masonry from what I've heard.

If you think of people working in the service sector, like fast food, or retail, I don't think most of them would cut it as a mason.

Aside from that anyone who has a way to make similar money another way would probably do so instead, I certainly would.

That might be what comes to pass in the far future. It's possible for something to be a good and creative tool and also capable of terrible things.

I think the gain of function research that may have lead to covid could possibly have had interesting applications, but it also (possibly) lead to something terrible, probably best to regulate it more.

In fiction AI is banned in Dune and Warhammer 40k because of past events. It makes sense that if something really bad happened because of AI you might want to put regulations on development of it.

I haven’t worked in big tech but do levels not cover people doing basically the same thing with different competencies?

I suppose people can fight over the levels but at least you could say SDE 1 gets $X SDE 2 gets $Y, and SDE 2 is just a more competent SDE 1.

Could be a good argument for putting the ratio on the homepage and search results too.