A long time ago Google used to have a program called "bureaucracy busters," where submissions were reviewed by the CFO to find internal barriers to getting things done.
It was a good system. It no longer really exists and has been replaced by endless reprioritization and detailed bean counting justifying every single small action to prove to layers of management that what you are doing is worthwhile as Google slowly rots into a decayed husk of its old self.
On the topic of calculators. I discovered Figr[1] on HN a while ago, and it really helps when doing one off multi variable thing, like helping a customer estimate their bill etc.
Kudos on building this. I occasionally search for these on Google and am always disappointed by the mess. Bookmarked.
I switched back to Pixel after two years of using an iPhone recently. It’s got a lot better phone and text spam detection. I get 5-10 spam calls and texts a day. The iPhone got unusable.
You can use http directly for your functions [1]. Or you can create custom http actions [2]. We encourage websocket usage because it allows for reactivity and UI consistency and it plays nicely with reactive frontend frameworks like React etc.
Back when I took compilers in college we wrote a compiler for Oberon. I couldn’t quite find my original class site, but this one seems roughly right (from a few years before I took the class): https://cseweb.ucsd.edu/~wgg/CSE131B/
When I first learned about isolation levels in databases I was shocked that databases could “lie” to me. I think like most devs focused on the product end I just expected databases to be a magical black box that worked perfectly. Which I assumed was just the strictest definition of serializability without really thinking about it.
After watching some of Andy Pavlo’s lectures[1] it all just dawned on me: Databases are just like any other piece of code you write and have to think about all the tradeoffs with algorithms and book keeping to keep things efficient and providing the guarantees you want.
I highly recommend that lecture series.
Shameless plug: the reason I watched those lectures was to understand the internals of DBs better because I started working at Convex. Where we try to make sure things like this is something an app developer doesn’t have to worry about. Though we do mention it in our docs[2] for the curious.
Thanks for the reminder! I’ve been listening to this since sometime in the late 90s early 2000s. I spent so much time focused because of this, and it became a formative part of my music taste in high school.
I am a downtempo person so classic Groove Salad kept me going.
I had moved to a new city about a year before the event. No work, no friends, money dwindling, and suddenly the world went bananas… my most vivid memories of that period was hours of reading about anthrax and bin Laden and groove salad and that secret agent station.
I was the one of the original TLs of Google Photos, specifically on Android and eventually managed all of the frontend teams for Google Photos. So I hope it's not a stretch to say that I have deep empathy for frontend problems. We also have great frontend oriented folks on the team.
I also worked with jamwt at a previous company (Bump) doing frontend work. When we worked together, I remember the acceleration of our ability to execute when the backend people were closely involved in our data syncing problems. Heck jamwt and team even wrote most of the initial client syncing code. When backend and frontend folks work closely together to solve data problems you can make magical things happen. In the end we're just product oriented engineers trying to ship delightful experiences.
