artemisyna

Oh?

It's fun seeing how much threads like this are mostly folks' hot takes on the title as opposed to anything in specific to do with the article.

If it works it works?

A fun little story, especially in the era of folks talking about alignment/AGI/superintelligence, etc...

None (or at least few) of the folks you’re gonna see on HN are going to be in the income bracket where they’re going to be living in East Harlem. It’s about half an hour from the places where things happen, at least, and might as well be an outer borough for most intents and purposes, given transit times, even if it’s technically within the stated geographical limits of Manhattan.

Well, that's some dedicated griefing lol

Yeah, the places that go for "the great race for comp" is sort of what this question was trying to get at.

A bunch of the comments here seem to be talking about what's in the headline (a game being realistic + feeling like work) without really noticing some of the broader social commentary in the article (the workaholic — and sort of toxic — culture of tech in China).

Seems like a potentially good game to train oneself in figuring out how to spend investor money though lol.

The thing articles like this miss is the problem is not will there be some set of skills gained on a given path, but what skills are gained (and at what opportunity cost) versus alternatives.

I appreciate how this post gets resubmitted every couple of years. It's been a go-to bookmark for ages now and really does help give some visual intuition for what's happening.

Say the middle point is M. We know that for each person the ratio of time to go between M->A should be the same as to go between M->B since the distance is fixed only the rates are different.

First lady got to B at 4 pm so her M->B is 4. Second lady got to A at 9 pm so her M->B is 9. Since they both left in the morning, if we call the first lady's M->A time to be x, we know that the second lady's M->B has to be x as well.

Using the fact that the ratio of M->A : M->B should be the same for both of them, we can set up the equation

4/x = x/9 ==> x^2 = 36 ==> x = 6

Since getting to M was at noon and 12-6=6, dawn was at 6 am.

(For what it's worth, I did trial and error too cause I was lazy and didn't feel like thinking... then noticed the nice pattern and back justified it. :P)

Porque no los dos?

Trends have changed and so have my preferences. It’s the same primitives but we’re allowed to change.

There's a meandering article here but not much of a thesis.

Even when the author addresses the title of the article itself ("So again: Why this book—for ninety-six years, over and over?") he goes back to meandering.

It seems like the author is trying to say something between "we read it because it's like watching celebrity drama and awful people are fun to watch" or "we read it because it's the American Dream" or "something along those lines, but again, it meanders so badly between unrelated (probably true, or at least opinion) statement to other (probably true, or at least opinion) statement where it ultimately ends up going nowhere.

I don't get this question. Automation is the job.

We (mostly) don't code in assembly anymore because there are compilers. Your can say that writing high level code (merely "configuring things" in your parlance) is more "boring" than say, register hacks, but that's a bit shallow. (Also, something something leaky abstractions making the whole "it'll only be configuring things!" kind of a moot point.)

Consider programmers from the 80s/90s or early 00s. The ones that still have jobs today are the ones that have kept up with trends and adapted, or otherwise had the luck of being at a place that hasn't. It's the same for the future. Stagnate on old tech, have your career die on the old tech.

Not the OP, but as an example:

Take a flat earther argument that's explanations within explanations within explanations to cover whatever "what about x?" type of questions you have.

Change "flat earther" to whatever conspiracy theory/controversial topic of the day, and there you go.

I suppose the question then becomes "should the things that FB did with WhatsApp and Instagram since acquiring them be considered a crime"?

I could see eyebrows being raised around interop work, but I'm not sure about the rest.

Not a lawyer, but I'm really curious to see how this plays out. This case has a lot of confounding factors:

* other companies/entities that can be considered "competitors" (Twitter, TikTok, LinkedIn, etc)

* the acquisitions in question (Instagram and WhatsApp) being approved by the suing entity (namely, the FTC) themselves back in the day

I wouldn't be surprised if an outcome of this were to be say, limits against cross-linking acquisitions together or the like in the future. However, having existing companies be forced to be spun out in their entirely... I have a hard time imagining that being the outcome, given the chilling effect it could have on the rest of the industry.

Seems like the difference between being fine being wrong in the short term (the "strength" part) in order to be right in the long term.

Well. This is a random post to be seeing on the HN front page.

Yup, Caltech is small.

Another possibility: Perhaps one of y'all ended up bringing up the topic of cereals (and those cereals in specific) because of a new ad campaign one of y'all saw.

You hadn't seen it yet, but lo and behold, you did later.

You might be underestimating the number of folks that would be willing to install an extension for $10 and expose the private data of themselves and their friends and family in the process...

Depends on the area and the team.

For product web-related teams, it’s often “pick something decent that will get you shipping the fastest”, with product-y infrastructure teams generalizing/cleaning/more carefully designing things up later, assuming the investment doing so makes sense. Documentation happens minimally if at all; architecture conversations happen but are somewhat on the fly (ie a few folks making a drawing on a white board before moving on). This is generally the pattern for anything new/hot/needs to get out of the door yesterday.

Larger scale infra code tends to be a bit better. Newer iterations on older systems (which may have a bit less pressure) tend to have a bit more time for structure. Many teams will have architecture review structures in place, though it is by no means mandatory. There is no separate architecture role. Who is doing what architecture depends on the complexity of the system/subsystem. Documentation here tends to be better though, IMO, it’s only really the open source stuff -— or that 20% of the engineers in the company are using, and only maybe API-level at that -- that has “good” documentation.

(There is also some code that the company has which is tightly coupled with hardware. Due to the longer timeline of these projects and how hard it is to change things, these have more architecture and process.)

Overall, everyone is responsible for their own code quality/architecture. How much it’s important depends on “where a feature is in the product cycle” and “how critical is it to get this component correct”. Folks are free to use whatever design they want as long as it makes sense. The constraints of “what is reasonable for the product/what already exists/what will others on a given team understand”, however, will tend to strongly imply some best practices. These best practices generally end up being codified in an internal searchable wiki/message board, usually in a team’s onboarding doc or in a “how do you use this” doc for a feature.

Pros to this are relative freedom, speed, and ability to adjust as a situation deems fit. Taking a theoretical approach here, you can think of it as there being a “best-appropriate-velocity” that a given team/organization can function at given their product/environment constraints. Rather than being prescriptive about what this should be by inducing artificial tangential constraints, letting folks choose the structure that makes the most sense tends to increase the likelihood these teams will approach this “best velocity”. To this end, I would say doing so (and structuring a culture around it) has been a large part of this company’s success.

Cons are that oftentimes code is not documented (which can be a struggle for folks unused to the culture); particularly spaghetti systems may remain untouched for years. Systems that could be unified may be left un-unified for longer than they should be. It can also be hard to push for large systemic changes without a lot of effort, though whether that is a bug or a feature (and whether some of the missteps these cause are about “architecture” versus “product intuition”) is another question.

Not sure what you mean by “business architecture” —- if here you mean the structure of large divisions within the company, there are plenty of directors/VPs/etc for that.

This project doesn't quite have the layers on top as some open source projects[1] but it is sort of amusing to see how much of Calibre is built on the back of one guy (funded via Patreon![2]) and a handful of volunteers.

[1] https://xkcd.com/2347/

[2] https://www.patreon.com/kovidgoyal

Hmmmm... you didn’t happen to start the 2-seater car physics major trend, did you?

Threads like this is cause 2/3rds of it will end up being “what’s something that folks have heard about in the news but hasn’t gotten big (enough for more press) yet”.

Rephrased, this question is also more of a product-market fit one (“which market exists/will exist but doesn’t have its demand satisfied yet”), whereas a lot of answers are focused on the tech.

Hm. I recently bought a Garmin Inreach Mini (satellite emergency communication device), intending to use it for some long backcountry hiking/backpacking trips I'm planning on taking.

Really hope this isn't effecting their emergency service/emergency communication devices. Subscription management, at a minimum, was via the Garmin website.

Man this makes me sad. I got a membership about a year ago with the intention of bringing along some friends (after visiting with family), but looks like that won’t be happening.

Playing Oregon Trail on some oooold machines was good.

This is a nice summary of commentary the astronauts have given since arriving at the space station, but I wish this article would cite the original events. =/

Iirc, this is some combination of a the “SpaceX press event” that they did as well as some words exchanged upon arrival. (I’m not 100% on that, though I do feel like all the quotes came from videos from their first two days in the shuttle.)

The city has put in Port-a-potties and there are maps of nearby businesses friendly and with restrooms. Iirc, there is also some sort of plan for trash collection.

The coronavirus bit still isn’t good, but the city has learned for the hygiene bits.

Not sure how easy/difficult this would be from am implementation perspective, but perhaps transcription could be provided as a pay-as-you-go service. Ie, users could pay into a pool for live transcription of a stream for a certain period of time or to retroactively transcribe specific streams.

I'd have to imagine that stream listening follows some sort of power (or otherwise 80/20) law, so hopefully that would help with the expense?