964 karma · joined December 2, 2013
- Email - ben@twos.dev
- Open source - github.com/glacials
[ my public key: https://keybase.io/glacials; my proof: https://keybase.io/glacials/sigs/xZFwICTyYo257X_iSnEUDl7UnvumB-6pzml0UBrXxCk ]
With UUIDs any service can generate an ID itself and tell downstream services about it in parallel—even if one of them is down, slow, or needs retrying.
My experience was that 80% of the folks are lifers, for better or worse. Work-life balance was great because everyone’s got kids and soccer games and traffic to beat home, but it was still very much a “butt in chair” system, not a “get work done” one. People regularly do “10-40” (10-hour days M-Th) or “9-80” (9-hour days M-Th, every other Friday off) schedules.
Compared with startup life and even FAANG, everything moves slowly. It’s a combination of real security, security theater, and the red tape that comes with being funded by taxpayer money. That plus the extra rules from just being near the nuclear stuff (can’t drink at lunch, guests need a background check, relationships with foreign nationals must be disclosed) made it a slog.
The most hilarious example, heard only through stories: there are two internal networks, the normal one everyone uses and the high-security one that has no internet access. They are physically separate—no cables crossed, no SSH tunnels, no bridges, nothing. But you have to transfer data between them sometimes, so you would remotely load your data onto a tape drive, and there was a tech you would ping who would eject the tape, run it over to the other network, and insert it in.
As with anything rote, the process was soon automated with a shell script. The script would take a couple of minutes to execute, and your data would be transferred. Entire workflows were built on this script. And around noon every day the latency would skyrocket, because the tape runner was on lunch.
> 3 factorial + 4 factorial > between: 10 and: 100
which means:
> 3 receives the message "factorial" and answers 6 > 4 receives the message "factorial" and answers 24 > 6 receives the message "+" with 24 as the argument and answers 30 > 30 receives the message "between:and:" with 10 and 100 as arguments and answers true
I’ve since moved to Seattle and it’s crazy to see shit can actually get done here.
To be frank with my feedback, I am a person who uses Firebase for a side project. I don't have the mental capacity to watch an ~hour talk for each piece of GCP infra I don't understand. I liked Firebase because I could understand it intuitively through its UX.
I'm sure the GCP features are very helpful and innovative and I'd get a great ROI from the talk if I worked on them for my full-time job. But some weeks, an hour is all I have. I'm an app developer and I would just like to deploy my app please, and have the rest fade into the background, or at least integrate with my existing workflows.
Thanks for all your hard work. I understand if "side project developers" is not the top of your funnel. But I hope you hear my feedback.
As time toes on and more and more Firebase features are redirected to GCP equivalents, the DX value prop is being drained out of the product and I’m left not even understanding my own infrastructure. I’m thankful the author pointed out Supabase, it seems like a great alternative.
If you were to compare the total time wasted by each category, I’m sure nondescriptive would come out as the most wasteful by far.
1. “Why not accomplish this with X?” We arrived at this solution organically, which was important for adoption: a Discord server meant for gaming hour turned into hangout rooms turned into offices. It may not be the best option, but best means nil if you can’t convince people to use it. For us and our existing culture, Discord was an easy and incremental jump to take. Take whatever path makes sense for your culture.
2. “Why not make this asynchronous?” Asynchrony should indeed be the default mode of communication, but synchrony has its uses; between nonverbal communication and round-trip-time it is simply obnoxiously higher bandwidth. It trades away efficiency (person-hours) for speed (hours). The fewer people involved the better the exchange rate, which is why this article focuses on 1:1 interactions. I wrote about this later in my article “Why Be Synchronous?” [1] but tldr; synchrony should be deployed similarly to tech debt.
> People have erroneous intuitions about the laws of chance. In particular, they regard a sample randomly drawn from a population as highly representative, that is, similar to the population in all essential characteristics. The prevalence of the belief and its unfortunate consequences for psvchological research are illustrated by the responses of professional psychologists to a questionnaire concerning research decisions.
(emphasis mine)
Not only does the statement say that “people” make this mistake then go on to cite a questionnaire only of professional psychologists, but the questionnaire is the prototypical non-random random sample the very psychologists taking it are allegedly proving misinformation about. Questionnaires select for people with the time, inclination, and attention to start and then finish a questionnaire.
Infamously, experiments held at universities bias towards undergrads. Experiments that reward participation bias towards people motivated by the reward. Experiments that don’t reward participation bias towards people good-natured enough to contribute just for science.
Randomness is hard.
It depends a lot on specifics, but as a trend I tend to agree. However, there's value in making the development environment consistent among engineers. I wonder if there's a middle ground for version-pinning things like PostgreSQL and Ruby that's not as extreme as containerization.
This seems like a leap—couldn’t these folks instead be thinking “oh the police stopped by my building, they are paying attention”? The real study is behind a paywall so I’m curious if this was controlled for.