With the advent of LLMs, I've felt even less need to publish publicly. It's as if an LLM can either produce something higher-quality and more tailored to the reader's context in a shorter period of time. Or the topic I write would be so niche that it should just be in a group chat.

https://hatchet.run/blog/durable-execution

Meta-comment about the post. I used to read and write book reviews like this all of the time. Not anymore. ChatGPT and Claude can do a just a good of a job. Now I'm looking for what you think, a unique insight, what did you feel from a book review from a humanoid. LLMs do a fine job summarizing.

Woke up at 6am. Child 1 woke up at 7am. Dropped her off at daycare at 8am. All the other children were being dropped off by their dads, too. Full day of work ahead. Dinner at 6pm. Bath at 7pm. Bedtime and story at 8pm. Usually calls with Bangalore from 9pm to midnight but it's Labour Day over there. Sleep at midnight.

Rinse. Repeat.

  - L1: Intern with undergrad degree
  - L2: Intern with graduate degree
  - L3: Junior
  - L4: Intermediate
  - L5: Senior
  - L6: Staff
  - L7: Senior Staff
  - L8: Principal
  - L9: Distinguished
  - L10: Fellow

L5 or Senior is usually considered a “terminal” role. That means all engineers should be able to get to this role. And people without the headroom get managed out if they can’t get to L5.

Staff+ is usually “special”. It means that people count on you to drive initiatives and you have something special other than just writing code. You are able to make product and business impact.

Distinguished and Fellow are very rare. Large FAANG companies will only have a handful of these engineers. It means you’ve made industry-wide impact like inventing map-reduce or DynamoDB or Kubernetes.

I'm guessing here. I haven't written video games in 20 years but struct packing/alignment was super important on the Sony PSP back then.

For example, there is a full glass of water sitting on my desk from 9am. It's noon. I haven't taken a sip. Until now.

Constant reminders do work.

Most orgs should just be shipping features. Before starting an Experiment Program teams should be brainstorming a portfolio of experiments. Just create a spreadsheet where the first column is a one-line hypothesis of the experiment. Eg. "Removing step X from the funnel will increase metric Y while reducing metric Z". And the RICE (Reach-Impact-Confidence-Estimation) score your portfolio.

If the team can't come up with a portfolio of 10s to 100s of experiments then the team should just be shipping stuff.

And then Experiment Buildout should be standardized. Have standardized XRD (Experiment Requirements Doc). Standardize Eligibility and Enrollment criteria. Which population sees this experiment? When do they see it? How do you test that bucketing is happening correctly? What events do analysts need? When do we do readouts?

That's just off the top of my head. Most orgs should just be shipping features.

I'm sitting at my desk in an office in Gastown in a low-rise. The streets are covered in feces and broken crack pipes.

We've barely bought any clothes either. They all come from Buy Nothing groups. Kids grow out of toys and clothes every 3 months. Parents are desperate to offload this stuff.

And my wife has become a hoarder as have other parents in the neighbourhood. Buy Nothing groups seem to set off some sort of hoarding affliction in parents.

https://chrishecker.com/Rigid_Body_Dynamics

Comments URL: https://news.ycombinator.com/item?id=40009054

Points: 1

# Comments: 0

Magically, I have hours per week to read books.

https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-fo...

False! A foundational concept in Constraint Theory is that "Large Batch Sizes Increase Lead Time".

Apple should figure out how to release smaller batches more often to improve quality. They should figure out how to release the first day of the quarter, every quarter. And work backward on what needs to happen to make that happen. Then release first of the month, every month. Once again, work backward on how to make that happen.

For example, we release to the iOS App Store and Google Play Store first thing on Monday, every Monday. And we worked backwards to figure out what we needed to do to make that happen.

When something goes wrong, the batch size is small enough that we can quickly figure out what happened. Also, the release train is reliable enough that engineers can push back on PMs. "You are not getting this feature this Monday. You'll get it next Monday".

Large batch sizes and long release cycles are terrible for quality!

Reference required. Empirical evidence does not support your claim.

The PDF in the parent’s comment shows there were 1010 vacant homes in 2017 and 502 vancant homes in 2022.

Jens Avon Bergmann of MountainMath.ca did analysis after the 2021 numbers were released. His takeaway:

>> “The results demonstrate very little “toxic demand” leading to vacancies in BC, and provide valuable checks on estimates of “foreign” ownership.”

https://doodles.mountainmath.ca/blog/2021/11/21/three-years-...

Please stop spreading this disinformation unless you have actual references with actual empirical evidence. It is actively harmful to supply-side solutions.

I am open to have my mind changed if you have evidence that toxic demand is actually causing significant harm. With significant harm defined as being one magnitude greater than the 500 vacant homes in the above PDF from the City of Vancouver.

Read the book and watch the Netflix documentary. I’m pretty sure Arnold is self-aware of his father issues. For a concrete example, Arnold’s brother dies drinking-and-driving at the age of 24. Arnold contrasts the way he was able to handle his relationship with his father compared to his deceased brother.

Over time, engineers get comfortable working on their own microservice but don’t have the context to make changes in microservices that other team’s own. Having iOS, Android, and web clients exasperates this.

Unblocked helps engineers get all of the context they need around changes. When teams grow, this context ends up in places like Slack threads that are 100 comments deep.

As much as you try to get engineers to write documentation, it just makes more sense to pull already written context from Slack and GitHub and generate the documentation.