pkaler

> I'm really struggling to see how to make architectural decisions with an agent.

I walk to work and home with ChatGPT Voice and AirPods. I ask it to be Socratic and I just start rambling the top of thing on my mind. After 20 mins of back-and-forth it's usually teased an answer out of me or I've teased an answer out of it.

I'll most likely be at Polyglot. I did a very small part to help organize one of the very early ones.

I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.

Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.

The latter is true but the former is false.

What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.

I've seen that countless times in the last two decades.

My mother worked in a factory that sewed drapes for film sets before she retired. My brother-in-law used to be an operations manager for a warehouse that rented equipment to film sets.

There is just a very long tail of services and a robust supply chain that is required for most industries to be successful.

I was never a prolific blogger. I do write a LOT internally at work and I write very long messages in group chats.

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.

I found the accompanying blog post excellent. In my experience, systems go from a monolith to a distributed monolith to a reliable distributed system. A durable workflow engine is one of the pieces that is required to get to target state.

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

I'm also currently reading "On the Calculation of Volume". It is fantastic.

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.

Yup.

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.

As others have said, levels and titles are generally for compensation and performance reviews. Each company has their own bespoke ladder but it generally maps to:

  - 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

Each company has their own numbers and names but it generally progresses like that. Impact and scope scales as you head up the ladder.

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.

SIMD and data locality. You probably want to check across three vectors simultaneously and load the coordinates next to each other.

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.

I'm actually working on an app for myself to remind me of that.

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.

Agree!

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.

Beg to differ. I live in Yaletown in one of the Concord Pacific towers. David Lam Park and George Wainborn Park are vibrant as is the whole seawall. My kid goes to the daycare along one of the parks.

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.

I have a 9 month old and we are drowning in toys. We have bought very few of them. The article is clearly not written by a parent because it barely touches on Buy Nothing Groups on Facebook.

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.

I sleep with Breathe Right strips. It's changed my life. Whoop band and 8Sleep confirm.

This is great. This reminds me of Chris Hecker's Rigid Body Dynamics series from GDMag/Gamasutra that I read (checks watch) almost 30 years ago! This is the classic/canonical set of articles.

https://chrishecker.com/Rigid_Body_Dynamics

(Aside: My goodness, Medium has gotten terrible. The article will not scroll for me because of some random overlay that won't dismiss. Why do publishers stay on Medium? I regret it every time I click a link.)

I don't have Instagram, Facebook, TikTok accounts. I don't watch Netflix. I don't play video games.

Magically, I have hours per week to read books.

The term that you're looking for is Retrieval Augmented Generation (RAG).

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

> I never understood those annual release cycles anyway. Too artificial, too forced. Great for marketing hype, accumulating bugs, and missing out on documentation. Bad for quality.

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!

>> A little insight on Vancouver: PRC investment firms decided that the steady growth of the North American real estate market looked to provide great returns on investment. So, these firms started buying up large numbers of single-family homes in Vancouver.

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.

> I'm a fan of Arnold, but I think it's pretty clear that he suffers from issues stemming from his rough relationship with his father.

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.

I had a chance to look at an early version of Unblocked. I think the huge benefit is when you work in a microservices environment or with many clients.

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.

GraphQL makes sense when you have:

  - Many teams with many micorservices with many underlying stores
  - A fetch-based architecture

Each team can be responsible for implementing the resolver for their service along with caching, scaling, etc. At Netflix's scale you don't want to have every single service have to scale to the level of the BFF/Orchestration layer. https://www.apollographql.com/docs/apollo-server/data/resolv...

If you have push-based architecture, it makes more sense for underlying microservices to publish to a broker like Kafka and then materialize a view to DynamoDB, Mongo, Redis, etc.

And if you don't have many teams with many microservices, then just do the REST, Rails, MVC thing and save yourself the headache.

This is Google at its 1990s COMDEX/Microsoft Vapourware worst. There is no product to try, no code samples, no documentation. Just an animated GIF of what the experience may be like and a signup link.

> Dumb question, what are invariants?

The term that you want to Google or ask ChatGPT is "Design By Contract". An invariant is something that is true during the lifecycle of a class, function, loop, service, system, etc. Invariants, preconditions, and postconditions are the three primary constructs in DbC.

This is a blast from a previous lifetime! I worked at Relic Entertainment during that time. Both Relic and Radical's offices were in Yaletown in Vancouver at that time, IIRC. Radical ended up moving to Main & Terminal.

I worked on Company of Heroes and Dawn of War during this era. The code looks very familiar. It's the same style of C++. The code looks very similar to Homeworld. https://github.com/HomeworldSDL/HomeworldSDL

I went to SFU, where Neall Verheyde one of the programmers from Radical lectured one semester. Sadly, it looks like he passed away a few years ago. https://www.dignitymemorial.com/obituaries/west-vancouver-bc...

> He only really excelled at creating inhumane structures that only serve to impress the intelligentsia. It's not like you'd ever want to live in his austere glass boxes

I read your comment while perched on a stool next to my kitchen island. The city stares at me in the background while I glance back at the city from time to time.

I used to live in one of the "austere glass boxes" you speak of that is pictured on the cover of Douglas Coupland's City of Glass. I live a couple blocks down the street now. https://en.wikipedia.org/wiki/City_of_Glass_(Coupland_book)

The metaphorical stones of others can not shatter this beauty.

This is for FreeBSD Firecracker. This means this is used for AWS Lambda and Fargate. A whole bunch of 2ms wins is how one would improve cold start time.

I have two Staff+ level positions open on my team. The expectation for them is to be able to work in a cloud-native (AWS/K8s/Terraform/etc), distributed systems (Kafka/SNS/SQS/Kinesis) that is mission critical because it touches people's money (fintech). And new client code gets written in modern stacks (Swift/SwiftUI, Kotlin/Compose, Typescript/React/Next.js).

If I were still an IC rather than a talking head on Zoom all-day, my role would map to somewhere between Senior Staff and Principal. I would write microservices from scratch, deploy to the cloud, operate them, and then write all of the clients (iOS/Android/Web) myself. I've been doing this for ~20 years so I have the ability to quickly pick up new languages, frameworks, platforms, technologies, etc.

The current Senior Staff/Principal engineers do projects like decomposing that old miscellaneous database from the original monolithic codebase and implement it across all domains with correct boundaries. Build libraries that all engineers on the team use. Ship V1 of that new product that is very strategically important to the company.

(Send me an email if you are a Staff+ engineer that is looking for something new!)