Oh?
357 karma · joined December 22, 2015
Seems like a potentially good game to train oneself in figuring out how to spend investor money though lol.
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)
Trends have changed and so have my preferences. It’s the same primitives but we’re allowed to change.
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.
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.
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 could see eyebrows being raised around interop work, but I'm not sure about the rest.
* 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.
Yup, Caltech is small.
You hadn't seen it yet, but lo and behold, you did later.
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.
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.
Really hope this isn't effecting their emergency service/emergency communication devices. Subscription management, at a minimum, was via the Garmin website.
Playing Oregon Trail on some oooold machines was good.
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 coronavirus bit still isn’t good, but the city has learned for the hygiene bits.
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?