Hacker News Reader

Comment by reaperducer | Hacker News Reader

They make it sound like the clouds parted and a ray of sunshine struck the programmers at Facebook and they realized that they didn't have to ride the framework-go-round to hell.

These are supposed to be the smartest people in SV, but from the outside, it strikes me more as a "No shit, Sherlock" moment.

View on HN

Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?

“I was instrumental in making Messenger twice as fast?”

Well yeah, but first someone has to get the credit for creating some "high-productivity" hog of a framework to make it slow, then someone else can come tear all that crap out and claim they made it fast.

Why not be both people? "I made React and I made Messenger twice as fast [by ditching it]"

because that sentence can be read within the time span of human attention span and the problem with it easily identified.

I've made a bunch of things twice as fast people forget almost immediately.

I guess it depends on if you frame it: "I was instrumental in adding complexity under the false promise of ease of development" versus "I was instrumental in saving the company time, money, and improving the product for our users."

Things like this are why I'm glad I'm not in the bubble anymore.

"I was instrumental in a major rewrite for [REASONS]" vs "We kept it the way it was because it was good enough and a rewrite would've improved [X] but hurt [Y]"

At a previous employer, I was dumped a client lib and server whose purpose was to maintain a data cache with realtime updates. It was fragile and slow as fuck.

When I got ahold of the source and started diving into it, discovered the client had 2 copies of the data, which was kept in memory. The server had 3 copies of the data in memory! Worse yet, the primary cache would be updated, then a multicast message was broadcast to update all the clients and the server's secondary and tertiary caches...thats right: the server would update the 2 other caches by broadcasting a multicast message, receiving it, then updating the other 2 after message receipt. A re-architecture was definitely in order. Took 3 months. Took another 3 months to get the interface to be backwards compatible with the original version.

Mind, the server was responsible for serving up relatively static market data for finance. But, considering we traded globally, we had +400 objects we cached, more than a few had 100ks of record. Memory usage for the server was many GB.

The rewrite involved moving to a single cache, instead of multiple for both client & server. It was also architected to handle large volumes of updates. Original implementation could even handle 100 updates per hour without bringing the server's and all clients to their knees. The write could handle +10k updates per second amd clients would barely notice a slowdown. Write locks were only held for a pointer swap. Memory usage for the server went down by close to 2/3. Client memory usage by 1/2.

During that time, also moved from static libs to dynamic on both Linux and Windows, so I could make nonbreaking changes without a firm wide recompile/relink, which typically took 3 days. HUGE productivity boost. A small bugfix didn't require a firmwide recompile/relock for the smallest bugfix.

I dunno -- you make it sound like it's a priori easy to figure out what is going to be better: one codebase ala react or multiple implementations per platform. Where the definition of better is some admixture of user experience, hardware requirements, maintenance costs, ease of hiring / training people for the necessary skills; and all these may shift over time.

But could it be that the OS functionality also evolved until today where it’s finally feasible to do this?

I’m guessing the oldest code in Messenger stems from a time when the OS-provided libraries were not up to par or simply didn’t exist yet. Partly because it’s not until now that the OS manufacturers finally see what there is demand for in apps.

This is more of a “Why are they confessing?” moment.

“They’re not confessing, they’re bragging”

Oh yeah, this is a problem with a lot of developers, reinventing the wheel because the native JSON parser might be improved upon. I mean it's a clear case of NIH, and yet it's also defensible because I'm sure most native / builtin JSON parsers are not as fast as a custom solution. And for an app like Messenger, moving to something else like grpc would be very defensible.

>> These are supposed to be the smartest people in SV

They might just be. Everyone else is cargo culting on React Native and the like.

I suppose that makes you the smartest person in SV!

Reply on news.ycombinator.com