This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.
Same sentiment here. B-tier hit factory stuff is easy to catch and easier to ignore and move on from. Also happy to recognize a fellow Stevie Wonder fan.
What was the compostion of folks let go by Cloudflare ? How many working in profitable lines ? How many in loss leaders ? How many engineers ? How many supporting business functions ?
Is it just me that I simply don't care ? I never one-shot these tasks, always provide a breakdown and always give the AI straightforward tasks that would take too much typing. The approach seems to work just fine regardless of the model. If it gets stuck, I usually take over and do the task myself. Also allows me to plan for throughput rather than latency - i.e. start 2-3 small tasks in parallel and do 1 complicated task or planning myself. It works whether I use codex or claude. I lean more towards codex since its cheaper. Even aider gets good results this way.
I guess the question is who is your customer or more specifically who's your buyer, who's your user and where do they hang out ? Also how do people find out about you product ? Distribution takes time, so I think its important to gauge interest upfront rather than commit to building first.
In general, the answer usually is to find people in your own network. If you go by that funnel the first thing you need is a network. LI is great at this. The next thing is to see who in your network is worth talking to. Find out whether the pain-point that you recognized resonates with them. A LI blast to your network might work as well to give you a bit of credibility. One thing that is cited often that does NOT work is spamming people asking for their time to learn about a problem. Nobody ever got back to me wit this method. But asking people in your own network for warm intros almost always works.
I dont think the Spring ecosystem is bad. In fact, its one of the more stable frameworks. Even spring AI which is built for AI agents a new use-case is very intuitive if you take time to learn its abstractions. Usually doesnt take more than a day of reading docs and writing some try-out code. The thing I really like about Java is the stability of its packaging ecosystem. Maven is XML (yuck) but is okay with the IDE integrations. Gradle has advanced features often missing in Python / Go such as build caching. The OOP stuff is also good because it scales with very large code bases. In, fact frontend esp React adopted a functional style which leads to complexities associated with hooks. A mixed approach is usually better. Overall, the only bad thing are the multiple unnecessary abstraction layers which are a pain in any language. Rest of Java is quite good.
GPT doing a great job summarizing and providing a counter:
what's they key thesis here and the argument ?
*Key thesis:*
When technology eliminates meaningful performance differences between products, industries shift from competing on *engineering and function* to competing on *brand and status*. The Swiss watch industry after the quartz crisis is a clear example: mechanical watches stopped being valuable tools and became *luxury symbols whose value comes mainly from branding, scarcity, and signaling wealth*.
*In one sentence:*
The essay argues that when technology makes functional differences between products disappear, industries shift from engineering competition to branding competition, and the modern luxury watch market illustrates how that transformation works.
---
If you want, I can also explain *why this essay is controversial among economists and designers*—there are a few big assumptions in the argument.
And the counter
A few places the argument is debatable (even if it’s persuasive as a narrative):
It treats “brand” and “engineering” as mostly opposed. In practice, luxury buyers often do pay for engineering (finishing, durability, serviceability, movement architecture), and those technical choices can reinforce brand rather than fight it. The tension is real, but not always zero-sum.
It downplays other drivers of the Swiss recovery. The rebound isn’t only “they discovered brand.” Things like Swatch’s role in recapitalizing distribution/production, industry consolidation, improvements in manufacturing, and globalization of luxury demand can explain a lot of the late-1980s revenue surge alongside marketing.
The “artificial scarcity = managed asset bubble” framing is provocative but contestable. Scarcity can be interpreted as: capacity constraints, quality control, long-term brand stewardship, or channel strategy—not necessarily “bubble management.” It may function bubble-like in resale markets, but that doesn’t prove intent or fragility in the way financial bubbles work.
Some claims are asserted more than demonstrated. Examples: Rolex “abandoned research” after ~1960; “only three survived as independents”; “most brands are owned by six holding companies”; “they rebuy hundreds per year.” These might be true in broad strokes, but the essay uses them as load-bearing supports without showing evidence in-text (beyond a couple notes).
The design-history claims are simplified. Watch size and shape trends aren’t only branding; they’re also driven by changing tastes, ergonomics, manufacturing norms, sport/tool styling, and shifting notions of masculinity. “Big = cheap historically” is directionally true in some eras, but not a universal law.
The gender section is especially shaky. “Women never really went for mechanical watches” and the steam-engine analogy read like overgeneralizations—there are strong counterexamples (and cultural variation) that complicate that story.
Congratulations to the creator of this site and thank you so much for posting it !
I have to (unwillingly) do frontend work so I recently read up on CSS quite a bit. I have always thought that using computed numbers for styling is bonkers. Its better to use CSS that uses logical values. The site seems to emphasize that style.
Number of features shipped. Traction metrics. Revenue per product. Ultimately business metrics. For example, tax prep effectiveness would be a proper experiment tied to specific metrics.
Curious: whats your primary programming language and what sort of development do you do ? In my experience with LLMs agentic coding paired with a good IDE works wonders. Its also allows me to surgically write critical bits of code myself while outsourcing boilerplate stuff.