kareemsabri

At our last startup we told people during the first interview that if they joined it would be the hardest they'd ever worked in their life. Some people opted out. Some people were excited and energized by the challenge. I don't see what's wrong with there being more than one company culture in the world. Not everyone wants to work at Google.

I wouldn't actually do that again, my views have evolved a bit, but I don't regret it.

You don't have to be all that skilled (depending on the field). You do need the money to self-petition though. Many pretty average people use the O-1.

I found it useful conjecture. It presents evidence and states the conclusions it draws, with appropriate disclaimers. Based on the facts, the conclusions are not unreasonable.

- Apple has kneecapped ads from competitors, this is acknowledged fact

- Apple services revenue has grown significantly since, which includes ad revenue, this is acknowledge fact (to the SEC no less)

- Apple does not disclose ad revenue as proportion of services revenue, but it's reasonable to think it would grow as well

Digital marketers have personally told me app install ads and the like on Facebook are no longer effective, so we'd expect those dollars to move to other areas.

So if they don't use your marketplace are the royalties not collected?

Why did you want to do this in the first place?

What sort of errors? You're talking about eventual consistency issues?

Well, what you said is this.

> FM does not guarantee most mortgages, only certain govt types like FHA and VA loans, which the govt decided to back in order to help low income people get loans (otherwise the rates would be even higher for them).

And this.

> The OP claimed they guaranteed mortgages, which they do not.

So it read to me like they don't guarantee mortgages save for the "special" mortgages for underserved groups (FHA/VA). In fact, they do. They guarantee all the loans they buy, as far as I know. They only buy conforming loans. Conforming loans are another way of saying, loans that they will buy (and guarantee). Of course they don't guarantee loans they don't buy.

I used to work at a mortgage originator, and we sold the majority of our loans to Fannie and Freddie.

> Of all conforming loans made, Freddie and Fannie end up purchasing about 60% of those.

This is true, because private investors pay more than Freddie and Fannie for conforming loans.

I don't think this is true.

> At Fannie Mae, we provide liquidity to the single-family market by purchasing and guaranteeing mortgage loans made by lenders and issuing debt securities and mortgage-backed securities that attract global investors to finance U.S. housing.

https://www.fanniemae.com/about-us/what-we-do#:~:text=At%20F....

I disagree with the author (and stated as much as recently as yesterday: https://news.ycombinator.com/item?id=32485460#32489682).

> With thousands of geometries in an interactive map, with lists and tables of items filtered by bounding box and categories, sorted by geodetic distance from wherever you were interested in, the performance issues that arose were never too many uses of useCallback or useMemo. The opposite caused issues multiple times however, of the app running haywire (or to a halt) kind.

The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo, it's a best practice". Memoized functions are more complicated to reason about and therefore more bug prone than their alternative. Most client-side apps don't have thousands of records they're iterating over, they have dozens. Throwing around memo because one might one day become big, and you'd pay some performance penalty, doesn't seem prudent to me.

We use a mux router https://github.com/gorilla/mux#matching-routes

I've used many languages in my career, including Java, Scala, Ruby, and Node. I didn't really consider Java, for a couple of reasons.

- I didn't love the Java tooling at the time. Maven for example. - I don't love OOP. Go has just enough OOP patterns for me.

I tried Go as an experiment, but didn't know it would become my go-to language. What I found was super fast build times (big win), built in testing, and a simple language that almost anyone can understand (versus the relative sophistication of something like Scala).

The "affordable housing" in Atherton would likely be $2.5M townhomes. Dunno what sort of ruffians you think would be buying those.

It's not a function, it's an immediately-invoked function expression.

Edit: I guess it would be a bit inefficient to invoke the IIFE every render just to initialize the value once. Probably better to use useMemo with [] as the dependency list then, either one achieves the same result.

Yes, in 2017 and 3 companies later I've never looked back. Current application is an event-sourced system that includes a REST API, asynchronous event processing over SSE, and a scheduled job runner.

It's been great. We don't use any frameworks, just the http package. It's blazing fast and highly reliable (low bug occurrence and easy refactors due to the safety provided by strong typing).

So if we fed an AI with Beethoven we'd get to Miles Davis and 2Pac?

Why do you have to use current everywhere? You can do const { current: myStableValue } = useRef(computation);

Not sure what you mean by one time constructor function, but you can pass the result of a function to initial value.

const { current: myStableValue } = useRef((() => { //called once })());

useRef is useStableValue

He touches on this in the piece briefly.

> I think as developers, we tend to overestimate how expensive re-renders are. In the case of our Decoration component, re-renders are lightning quick.

Certainly it's there for a reason, and you may have expensive operations, but in my experience developers reach for useMemo much too early and often, and it just adds complexity to their functions. The cost of checking the parameters for changes adds overhead that may be more expensive than just re-doing the "expensive" operation. My rule of thumb is if the operation is less than O(n) where n < ~5000 I don't reach for useMemo.

There have been some benchmarks done on this, and when it pays off to use.

Yeah, this is not to belittle the complexity of React under the hood. But they are functions, and it seems you can assume they will be called in a straightforward manner when they render (whether they are invoked as explicit function calls or via returned JSX).

The only real complexity (for the developer) is the use of hooks, effects etc. if you don't mess with useMemo (which you generally shouldn't). Certainly they aren't pure functions, they have side effects and are stateful, and that has some nuances, but (kudos to the React team) once you understand hooks as a reference to the instance value and a setter for that value, they're pretty easy to understand.

I guess I don't personally find thinking of them as a class as that useful, my mental model of "it's just a function with some external references (via hooks)" gets me there.

Good article.

What I've found interesting is how many developers think a React "component" (which since hooks is just a function) has some special privileges or abilities that a normal JS function does not. Like, whether it will be selectively executed or what variables are created anew versus reused between subsequent calls. It seems unclear that a React component is just a function, and displays all the behavior expected in a plain old function.

While I agree it was hard to know when React would re-render in the old, class component paradigm, it seems much easier to know when a function will re-render, since it has to re-render whenever the function is called.

This is really not true. How do you think people start companies together when they don't have capital? By splitting 50-50 and working on something "for free" on nights and weekends.

OnDeck is a pretty good community for this https://www.beondeck.com/

I also think working at early-ish startups, Series A-C, will help you find people more interested in the founder path than FAANG type companies. From there you can work on something growing fast, learn a domain, test your relationship under pressure, and then leave to start something together.

I don't have this experience at all. I have a car in NYC and am a daily subway rider. Regularly comparing estimated time via Google Maps (which doesn't even include parking) the subway is almost always faster, certainly during hours when there is congestion (which is obviously when most people tend to travel).

NY subway for virtually any destination is faster than driving, during busy hours.

I like OneMedical (I'm a customer) but I don't know how much "innovation" it's done in healthcare. That's not to say it's their fault, healthcare is a startup graveyard, but you can't really go to OneMedical for anything beyond the most trivial, and you can book some stuff / send messages using an app.

Kaiser arguably did more innovation than OneMedical, as far as I can tell.

A boy/man and his dog is a pretty classic American archetype (Old Yeller, Where the Red Fern Grows). I don't think it's evo-pysch really, but it does indicate you are somewhat active probably, you have your shit together enough to care for a living thing, and you are capable of affection / emotionally available to another living thing.

There's a lot of dog breeds. Some are aloof and distant, some are needy and anxious (which people do confuse as affection/love). I prefer the former.

I don't think that's what I implied.

He appeared on the author's podcast. The author seems generally supportive of him.

I'm not sure that's an inside-out acquisition as Larry Page would not have control of Excite in any meaningful way.

My point was more that if a guy wants to start a company to create passive income to fund his massively ambitious research projects, he would need the foresight to know the company would be massively successful, like throw off enough cash to pursue projects that would appear frivolous successful, and I don't think the Google founders had that foresight. Obviously I wasn't there, but trying to sell it to multiple suitors (they were also open to selling to Yahoo as late as 2002 afaik) indicates they didn't. My understanding is nobody knew search would be as lucrative as it it today.

Not to say you're fabricating your story, I'm sure they said that, but perhaps it's some revisionist history.