having used claude extensively for the past couple of months, i think there is still a lot of value to understanding your code and steering it intentionally. the amount of incidental complexity claude accumulates otherwise (which mostly results in bugs that it can't ever fix reliably) is staggering.
Vibe coding broke people's brains because they had a bad understanding of the software design process.
The pop culture model goes something like this: start out with a sketch and then render that same idea in progressively finer detail.
So when tools could "skip" to high detail, people went WOW.
I love the Android community and I'm incredibly sad to have lost my colleagues. Calls for boycott feel like adding salt to injury and pissing on their amazing contributions
If the balance of contributors shifts towards little Square effort, if there's a disagreement on contribution or blockers, anyone can just fork & move on. Maybe some projects can move to foundations (aka where projects go to die)
If that's your worry, you should have stopped using Square OSS when Jesse & Jake left.
As for merging PRs: we have a long tradition of graduating strong contributors (& ex employees) with write rights. No reason this should change.
Worried about a change of strategy? There never was a strategy!
Support & updates? This was always tied to a few folks contributing on a volunteer basis, and it always was ever changing.
Given this, calls for boycotting Square OSS are stupid.
It's disrespectful to the hard work all these ex-Square engs have done. It won't hurt Square the company in any meaningful way, it just makes a bunch of your Android peers sad.
It's ridiculous to think there was some sort of Square master plan for all the OSS and some well thought-out maintenance roadmap that Square's leadership was invested in. It's always mostly been a happy chaos.
OSS is a sub culture within Square's eng, practiced by a relatively small set of individuals.
These OSS projects are the work product of those individuals. Square as a company never really had a real serious strategy or plan here.
What happens to Square / Block Android OSS projects post layoffs?
Let's start with some context
OSS at Square is mostly a happy accident. Jack hired Bob, who's job was attracking world class engineers, and he did that through talks & OSS.
How to detect LLMs sending you emails?
ChatGPT suggested a Controlled Constraint Test: forcing an unnatural constraint
e.g. here: "Before I consider an intro, could you explain the fit in exactly 3 bullet points, each under 15 words?"⁷
I tried, got a fitting response a few minutes later 😊
Very sad it had to end like this. The Cash Android team and my design systems team was really special and I'm going to miss everyone.
Even if you don't touch those libraries directly, you may be using libraries, frameworks, and tools that do. This is the prime opportunity to find people who aren't just knowledgeable in many of these tools, but are maintainers and authors for them.
So yeah if you have been until recently employed by a Jack Dorsey led company and want to get into mobile or front-end observability, hit me up.
😭 for all my ex colleagues at Square. You all made this place a wonderful place to work at ♥️
I'm still there... Scratching my head, wondering how we can keep things up for our customers
Almost all of Cash Mobile Engineering was laid off today.
None of us have any clue what their rubric was for choosing who stayed and who went, but whatever it was, I'm on the job market again!
Hi friends I just got laid off along with 40% of Block. No idea what comes next, but if you have need for a Principal Frontend Engineer hit me up!
cc @romainguy.dev I remember you talking about that and how sometimes you'd center large numbers back around 0 to increase precision
Wondering how many folks are wandering around with their laptop opened (e.g. in the back of a car) and tethering because they want Claude to keep moving while they're running errands
We were all just waiting for you to show up
Not yet!
This is still a super early draft, thoughts & feedback welcome!
The idea here is to turn that step by step process into instructions for an agent + give it an interactive tool to read the trace, edit it, and run queries about object state (i.e. what I used to do in YourKit).
Ideally the agent iterates reading code + reading state to make progress investigating
So what I'm attempting to do here is encode how I've been investigating leaks:
- A process, as described in engineering.block.xyz/blog/the-lea...
- An understanding of an app's architecture & code
- A tool for querying object state in the heap (manually poking with YourKit)
The problem is: in my experience, this is often bullshit, although you're sometimes lucky.
Before you go "yeah LLMs are BS machines", PAY ATTENTION: I wrote "point where most folks would point."
Many engineers struggle with analyzing leaks, and might come up with a similarly plausible bad answer.
If you throw a leaktrace at an agent, it will probably parse that reasonably well, and point where most folks would point. Then it'll make up a plausible explanation, and if it's Claude running in your codebase it might even try to put up a fix.
First attempt at building an interactive CLI tool that agents could use to investigate leaks: github.com/square/leakc...
This is just a couple hours of work (plus, of course, my few decades of experience)
Any recommendation for an in depth (recent) technical podcast / talk / blog on how to build an agent loop for auto investigating & fixing production issues?
This one hits hard.
Another fun bit is that JSR330 had this at the end:
"An injector could rely on reflection or code generation. An injector that uses compile-time code generation may not even have its own run time representation."
That was 3 years before Dagger's release
