zeptonaut22

Definitely true, but back in the day that was sort of the fun of it -- similar to putting up an AOL Instant Messenger away message, it was just... a blast of a funny thought to the people that you knew.

Over time, that network got stale and it included "people you sort of used to know", and then it included your grandma and uncle and rest of the world. There are few things that are at the intersection of the Venn diagram of "things I want to share with all of those people", especially as I get older.

--- *40 minutes* Time it took Rankin to descend, due to a thunderstorm’s vertical air currents forcing him upward ---

Can you imagine the sheer terror of skydiving for 40 minutes through a thunderstorm? Jeepers.

Cool project! I think there's a way to add a button to the README that turns a repo into a template -- maybe that would decrease friction further?

Mark Zuckerburg's superpower is being like Jack Sparrow at the beginning of Pirates of the Caribbean: he steps off one boat just as it's sinking onto another, and he has the humility to not really give a damn which ship he's on. (I say "humility" even as someone frustrated by his net impact on society.)

I think on the How I Built This Instagram episode the Instagram founder said that Zuck was basically reading the data from Facebook's interactions and saw that the demographics and sharing tendencies of Facebook users meant that it was in a death spiral: people were moving interactions to private channels, reducing the available "friend" content. IMO, the causal factor here is that people became wary of public oversharing and the result was FB pivoting away from "social network" (OG Facebook) to "social media" (2010-2015 FB) and eventually just "media" (Instagram, Reels).

Looking back at what I posted on FB in 2008-2012 is like observing an alien from another planet: it was a completely different platform.

That's amazing. Thanks for sharing a more informative link than the one I found!

Interesting to read: I've always heard of Chrome and Gmail as two Google products that were the shining examples of "look at what these wacky engineers went off and built!"

It seems like that notion may be a bit romanticized.

I wanted to share this post with any other engineers that have struggled with the transition from "building what you're told" as a junior engineer to "figuring out what to build" as a senior engineer.

This post talks about a super pragmatic roadmap I came across from an experienced indie game dev dealing with exactly this problem: how do you balance between "building" and "figuring out what to build"?

Very cool idea! I could definitely have seen this being really useful at my last startup.

A few quick thoughts:

- I definitely would have loved to see some common travel filters (which I know as a programmer is easier said than done"). The recommended flight for me was spirit airlines, which sucks in the US and I wouldn't really want to force my employees to take that.

- Both origins and the destination that I tried were in the US, but the price was still listed in euros.

- In my head, I imagined that the suggested destinations would include some reason that they were compelling, not just a generic picture of the city. My suggested destination was Atlanta, but I don't know why we'd want a team offsite in Atlanta. I'm looking for something on the right continuum between "cheap" and "interesting", and this seems to really only help with the "cheap" aspect.

Very cool tool though! I'll keep it in mind for future work travel needs.

Just a thought: this tool looks cool, but I'd love to see a demo video of it in action as the hero item at the top of the page. Without that, it feels a little... theoretical and hand-wavy.

If I were to guess, the one of these that has by far the most impact is the Google featured snippets. There's constantly a tension between Google and online publishers about Google wanting to serve people answers quickly (with "on the search page" being the fastest version of that), but that not actually helping the publishers.

I couldn't agree more about the toxicity, though. I don't pretend to know much about who's right in the Stack Overflow vs. moderators debate, but every time I visit an answer on Stack Overflow and glance at the right sidebar I feel like a kid who's just walked in on his parents fighting. The tension between the company and the community is palpable and it makes the site feel like an icky place to be.

In my experience, the web has bifurcated between "web applications" (owned by React) and content sites (owned by Jamstack).

One dilemma I've faced is when you find yourself in the middle of those two areas and might want to develop an MVP in Jamstack to later add more web-appy features. Jamstack always left me feeling like it was sufficient for my current use case, but with much more complexity I was always one errant feature request away from running into something I couldn't do and having to rewrite everything.

Furthermore, just doing simple things can require significant creativity on how to achieve that. It's fun, because the end result is something that's significantly more performant than anything you could squeeze out of React. I happily use Jamstack for my blog (FCP of 0.8s, Lighthouse score of 100!), but would feel reckless suggesting it for any professional work that I do outside of company blogs or something.

Thanks for sharing your insight in #2: definitely an interesting view that I wouldn't have access to myself!

As for #3, the same thing occurred to me with regards to the supply chain shortages during the pandemic: the highly optimized, just-in-time supply chain that we'd work so hard to build meant that there was almost no room for extraordinary events. When those events do inevitably happen, they're far more disastrous than they would otherwise have been.

I don't think that _all_ continuous improvement needs to be this way: the classic example of "letting the factory floor worker work with a toolsmith to design a better wrench for their job" probably doesn't have negative consequences in extraordinary situations. However, I do think keeping in mind "is this a pure improvement or are we making a tradeoff, and at what cost?" is a worthwhile question to ask.

Definitely have never heard anything about that aspect of Japanese culture - thanks for sharing!

I have experienced the bit of "Japanese working folk being willing (or perhaps expected) to commit their lives fully to their jobs", and I wonder if putting your own health on the line comes as a byproduct of that? Definitely not an aspect of the culture I'd try to encourage.

There's an excellent book called Gemba Kaizen that's all about kaizen and the Toyota manufacturing process that inspired a lot of the thoughts in the post. Lots of interesting parallels between manufacturing and software development (e.g. "factory management should lots of time working on the factory floor if they want efficiency wins").

I find this site fascinating not for the investment strategy linked but rather the great job it does in making a powerful and complex feature set accessible to its users. It does this all while managing to avoid the rut of looking like every. other. app.

Kudos to whoever is doing design on the Composer team: I can tell that someone cares deeply about both the UX and UI of the app.

A few months ago, I got to help structure an acquisition deal for our company that ultimately fell through. This post is about some of the ways I learned that employees can get a raw deal in such an acquisition.

My main takeaway was “work for people you trust or assume equity is worth nothing”. Upon an acquisition, equity value is more opinion than fact and you want someone with scruples negotiating on your behalf.

Acquired Podcast - "stories of well-known business and the playbooks that built them". Awesome podcast if you enjoy learning about the intersection of tech + business.

Startups For the Rest of Us - far on the other side of business + tech spectrum in the indie hacker space. Find it lends a really nice counterpoint to Acquired.

How I Built This - well-known and fantastic interviewer Guy Raz interviews company founders about their stories. Definitely has more a consumer than tech bent.

Planet Money - because it's awesome.

The closest thing to gathering I've seen is the consistency of posting on LinkedIn with the #layoffs and #opentowork tags. I've also seen a decent amount of activity in the ex-Googler community where former Google leaders (e.g. Laszlo Block, former head of HR) host Zoom discussions about what life's like on the outside and whatnot.

Man, this sucks. CSS-Tricks has long been one of the best resources on the web for doing CSS right and the quality of their writing and research is outstanding.

Bad on DO for going through with this acquisition and then lopping off its head: it's a net negative contribution to the web.

Geoff, thank you for your contributions.

This is a blog post by Ben Kuhn about why he's leaving Wave (where he was CTO) and joining the AI startup Anthropic.

Anthropic just raised $300MM from Google and - perhaps more interestingly - was founded by and employs many of the authors of the paper that underpins modern machine learinng models, [Attention is all you need](https://arxiv.org/abs/1706.03762).

Wave, Ben's previous company, is a big deal in Africa. In Ben's own words, "When mobile money succeeded in Kenya, (Suri and Jack 2016) found that it lifted 2% of all Kenyan households—almost a million people—out of extreme poverty. I think Wave has a strong chance of doing the same for the rest of sub-Saharan Africa!

Point being, Ben is someone who I'm always impressed thinks so deeply about his work and I'm more optimistic about Anthropic knowing that he's involved.

Yep - totally agree. I do think that's another benefit to "starting small" though with marketing via individual comments: your failures are a little less public than they would otherwise be. The most important thing is to be useful: if you don't have anything to say that leads to a "conversion" but do have useful input, that's great: give the useful input and move on. Only give a link to your work if it's genuinely very well suited to the response.

I also think people underestimate the amount to which really successful people have taken the approach of marketing via individual answers: for example, here are responses from the head of two compliance automation startups (SecureFrame and Vanta) with a total valuation somewhere north of $2B... duking it out in the comment section of a forum 2 years ago. Small marketing wins add up.

This blog post is a bit of an apology note.

When I first graduated from college, I thought of marketing as a tool for people whose work wasn’t good enough to stand on its own.

Years down the road, I realize that many of the engineers at Google whose work I knew best… well, I knew about them because they were excellent marketers of their work too. Knowing the first 10% of marketing was a lot more likely to move the needle on my impact than learning another 1% of engineering, which was in fact a lot more difficult anyway.

Sorry to hear - this must be immensely stressful for you, but I definitely appreciate reading about the failure.

This quote really spoke to me:

> I also learned the level of commitment it takes to bring something from 0 to 1. It's really, really hard to build something from scratch. And it takes an insane amount of irrational confidence.

I've found the same: working at a very early stage startup gave me a new level of appreciation for people who make any new business work, whether it be a deli or a unicorn. It's very, very difficult.

Unfortunately, starting a software business by trying to build too much before shipping is very, very expensive. In my experience, people talk about MVPs as an obvious destination - "in order to prove this out, we obviously need the ability to make payments, the ability to list excursions, ...". In reality, I think finding an MVP is a skill more akin to archaeology: everyone one of those "obvious features" should be scrutinized closely. Is there a way to manually do this? Does the manual version have little enough friction where it will actually allow me to test my business hypothesis?

I also think "building the real thing" is often a trap: "real software" grants you scale but makes it difficult to build a real relationship with your users. At the birth of a business, a close relationship with your users where you can get great qualitative feedback about their problems is far, far more important than scale. Your solution is probably wrong and your understanding of the problem isn't nuanced enough to build the right thing: you can just hope that you're in the ball park enough where people want to help you get a run.

Thanks - I'm glad you enjoyed them! Toddlers are cruel teachers.

Totally makes sense! Plus, you can look pretty cool when you're actually decent right away at something. Pickleball is a blast.

Welp, I now consider this required reading alongside the post. Thanks for sharing!

My jealousy is tangible. I always want to be great at just a few things... but those few things happen to change too often for that to ever happen.

(Software engineering and running are probably the ones I've sustained for the longest, though kids haven't helped with the latter.)

Basically, I mistakenly thought "I'm working at Google, not a startup: this advice isn't relevant to me".

What I didn't realize was that the startup world has lots and lots of info for figuring out how to build new things that matter while minimizing waste. Beyond senior SWE at most FAANG companies, you have to start thinking about how much your work matters as opposed to just how complex of projects you're able to handle. It was the "...that matter" suffix that really blindsided me, and I focused too much on "becoming a better SWE" through better coding, more interviews, etc. instead of building up the entirely new skillsets of things like customer discovery, soliciting customer feedback, etc.

Ah - if you feel this way, then I probably wasn't on the nose enough with this specific point. I was trying to balance a few points (i.e. IMO most people focus too much on marginal improvements in skills that got them to where they are) and not enough on building awareness of what completely new skills they need to build.

Generally, my suggestion is "weasel your way into coaching from people who are both much better than you at the thing and can break down their approach". Neither is sufficient on its own. In my experience, 1:1 coaches can be incredibly hard to find in some domains (esp. professional ones) and it seems like most people find them once they're already showing great promise at something, which means that they're not at the bottom of the bell curve. That means the onus is mostly on you to get to the middle. To do that, look for people who have found more success than you at the skill and are great at explaining their thought processes: podcasts and YouTube channels are invaluable for this.

Like most good advice (IMO), this is something that seems obvious but is rarely practiced.

This post comes from the experience of several brutal multi-year engineering projects at Google that, in retrospect, I wonder "why didn't anyone criticize the idiotic decisions that I was making?!".

Along the way, I was making "good software engineering" decisions but very poor product decisions: specifically, the biggest risk to the project wasn't that the code was poor but rather that no one would want the thing that I had set out to build. I find that unless you're diligent about incremental validation, time on engineering projects is usually wasted on the scale of years by creating a beautiful castle that no one wants to live in.

I now see that my project was a lot more like a little startup: by finding resources about how to make a startup go, I could have saved a lot of trouble. By taking this path, you still end up with a lot of waste (rewriting fast, poor versions of features to be better), but you're able to course correct earlier and have a lot better chance at the overall project being a success.