wellpast

Definitely the hallmark of junior. Obsession with code deduplication as the highest pri when it’s quite low among others.

that can't hold invariants in their head across thousands or millions of lines of code and possibly an exponential number of interactions.

There’s your problem. And static typing won’t save you either.

The skill is not that, it’s the ability to compose and evolve systems such that you don’t have to hold so much state in your head.

(Btw that property can hold for a million LOC codebase.)

“Until you get better” at pedaling, training wheels can help.

It’s not an arrogant take; it’s arrogant to think you know static typing is a requirement for developing software well.

Simply put, even solipsism is unfalsifiable.

Not even to optimize for, but to write correct programs you really need to understand the runtime which is usually broader than the syntax.

All Clojure (lisps) do is remove the stupidity of syntax.

Even if syntax is the minor thing, why wear a stupid, uncomfortable shirt while running when you could wear one so comfortable you scarcely feel it?

Clojure was explicitly designed to be dynamic. It’s a feature, not a bug.

https://clojure.org/about/dynamic

Until you get better at not making mistakes that the training wheels of a static type system “protect” you from, lean into the REPL as a means to build up small correct expressions into larger ones.

I’m willing to be wrong but this industry-wide emphasis on AI creative/coding workflows seems way over-engineered.

Ime successful creative execution looks like micro-iterations where each output informs the next creative move.

I can build something incredibly fast from essentially caveman grunt instructions through an LLM harness, iterating as I go.

Optimizing for feeding a huge plan to an agent sounds to me like a net waste of time. And looking over the shoulder of industry peers trying to do this, I don’t see their outputs or throughput some remarkable improvement over what I can produce with minimal fanfare usage.

When I think about a programming problem, I think in terms of the sequence of instructions I need the computer to do, and the memory locations that can hold the information the computer needs to track.

You’re almost there. Just stop thinking about the sequence of instructions. Focus on the information half (the values) that you need to produce.

In Austin we have most notably Terra Toys and Toy Joy.

Terra Toys is 50 years old, its space shows it. Hand-written recommendations and prices. The employees demonstrate and play with the toys, welcome you genuinely as you enter. The toys seem curated for actual fun not schtick. I went in last week and it was popping. It’s an experience.

Does Main Street need to focus on experience to survive? If so, how does it monetize experience if selling items isn’t the first focus now?

HTML is marking up the meaning of the document.

Is this true at all anymore, except for SEO optimized sites/content?

For apps, it’s all layout, isn’t it — and HTML, JS, CSS have all evolved heavily to support UI-first, haven’t they?

One way to potentially discourage or curb AI-edited/written is integrate AI into HN so that your submissions get recommendations based on HN post guidelines such as “consider tone”, “substance” etc.

Then less motivation to jump out to external LLM to even get comments on your content which can temptingly lead to editing/generation.

Being able to solve problems with true simplicity is a master’s skill. The skill to recognize simplicity and its value is a skill as well.

You can try to explain this OP’s concept to a stakeholder in a 1000 different sensible ways and you’ll get blinking deer-in-headlight eyes back at you.

This skill is hard-earned and, so, rare.

Therefore, many hierarchies are built on sufficient mediocrity top to bottom.

Which works because bottom line doesn’t often matter in software dev anyway.

And even when it does matter it’s multiplicatively rare to have a hierarchy or even the market that it tries to serve who can build, comprehend, handle high power::complexity systems, products, tools.

$100 says AI got at least some notes effecting the copy of this post

This seems very much a stunt. OpenClaw marketing and PR behind it?

I coded up a crossword puzzle game using agentic dev this weekend. Claude and Codex/GPT. Had to seriously babysit and rewrite much of it, though, sure, I found it “cool” what it could do.

Writing code in many cases is faster to me than writing English (that is how PLs are designed, btw!) LLM/agentic is very “neat” but still a toy to the professional, I would say. I doubt reports like this one. For those of us building real world products with shelf-lives (Is Andrej representative of this archetype?), I just don’t see the value-add touted out there. I’d love to be proven wrong. But writing code (in code, not English), to me and many others, is still faster than reading/proving it.

I think there’s a combination of fetishizing and Stockholm syndroming going on in these enthusiastic self-reports. PMW.

Had the same thought but feels too overly optimistic.

I don’t think people “internet” for trust, but for dopamine.

but the truth is that behind the volatility and public speculation, there has been a smooth, unyielding increase in AI’s cognitive capabilities.

We are now at the point where AI models are … good enough at coding that some of the strongest engineers I’ve ever met are now handing over almost all their coding to AI.

Really?

All I’ve seen on HN the past few days are how slop prevails.

When I lean into agentic flows myself I’m at once amazed at how quickly it can prototype stuff but also how deficient and how much of a toy it all still seems.

What am I missing?

This is one of those discourses that disappoints me about our industry.

Estimation can be done. It's a skillset issue. Yet the broad consensus seems to be that it can't be done, that it's somehow inherently impossible.

Here are the fallacies I think underwrite this consensus:

1. "Software projects spend most of their time grappling with unknown problems." False.

The majority of industry projects—and the time spent on them—are not novel for developers with significant experience. Whether it's building a low-latency transactional system, a frontend/UX, or a data processing platform, there is extensive precedent. The subsystems that deliver business value are well understood, and experienced devs have built versions of them before.

For example, if you're an experienced frontend dev who's worked in React and earlier MVC frameworks, moving to Svelte is not an "unknown problem." Building a user flow in Svelte should take roughly the same time as building it in React. Experience transfers.

2. "You can't estimate tasks until you know the specifics involved." Also false.

Even tasks like "learn Svelte" or "design an Apache Beam job" (which may include learning Beam) are estimable based on history. The time it took you to learn one framework is almost always an upper bound for learning another similar one.

In practice, I've had repeatable success estimating properly scoped sub-deliverables as three basic items: (1) design, (2) implement, (3) test.

3. Estimation is divorced from execution.

When people talk about estimation, there's almost always an implicit model: (1) estimate the work, (2) "wait" for execution, (3) miss the estimate, and (4) conclude that estimation doesn't work.

Of course this fails. Estimates must be married to execution beat by beat. You should know after the first day whether you've missed your first target and by how much—and adjust immediately.

Some argue this is what padding is for (say, 20%). Well-meaning, but that's still a "wait and hope" mindset.

Padding time doesn't work. Padding scope does. Scope padding gives you real execution-time choices to actively manage delivery day by day.

At execution time, you have levers: unblock velocity, bring in temporary help, or remove scope. The key is that you're actively aiming at the delivery date. You will never hit estimates if you're not actively invested in hitting them, and you'll never improve at estimating if you don't operate this way. Which brings me to:

4. "Estimation is not a skillset."

This fallacy is woven into much of the discourse. Estimation is often treated as a naïve exercise—list tasks, guess durations, watch it fail. But estimation is a practicable skill that improves with repetition.

It's hard to practice in teams because everyone has to believe estimation can work, and often most of the room doesn't. That makes alignment difficult, and early failures get interpreted as proof of impossibility rather than part of skill development.

Any skill fails the first N times. Unfortunately, stakeholders are rarely tolerant of failure, even though failure is necessary for improvement. I was lucky early in my career to be on a team that repeatedly practiced active estimation and execution, and we got meaningfully better at it over time.

Someone might run:

curl -s https://www.cs.cmu.edu/~biglou/resources/bad-words.txt | tr -d '\r' | while read -r w; do curl -s -X POST https://subth.ink/api/thoughts -H 'Content-Type: application/json' -d "{\"contents\":\"$w\"}"; done

95 other users*

Love this. Is there a scrape-able list of these?

Just d/l’d. Thx. Exploring… Looks interesting!

https://xelly.games/

Vine but for user-submitted microgames

Docs: https://xelly-games.github.io/docs/intro

Docs for game developers: https://xelly-games.github.io/docs/intro

https://xelly.games/

Users post small games to social feeds.

Scroll like a social network, jump into and play any game by tapping on it.

Games are served into fully locked-down, sandboxed iframes for security.

https://xelly.games/

Twitter but for games instead of tweets.

https://xelly.games/

Social media network where users post microgames!

It’s a least-common denominator effect.

I.e., most people don’t care.

Local-first is optimal for creative and productivity apps. (Conversely, non-local-first are terrible for these.)

But most people are neither creative nor optimally productive (or care to be).

sane*

Of course it will because same programmers don’t ack their customers until their (distributed, replicated) db says ack.