jkkramer

I did do it again, and spent time figuring out how to do it even more.

The cool thing though is that I could have chosen to do something else, too. I’m not at a loss for fulfilling, productive things to do. AI won’t change that.

Just yesterday I noticed I was mentally EXHAUSTED after building out a feature with Claude Code.

I actually had to think really, really hard to keep up with the idiot savant as it cranked out code.

Correctness was extremely important for this feature. Claude would consistently make subtle mistakes, and I needed to catch them to keep things from going off the rails. I could have done it myself, but it would have taken MUCH longer.

I essentially compressed a week’s worth of work into a few hours, and my brain paid the price.

So yeah. You can use AI to replace your thinking, or you can use it to push yourself to your max potential.

As a fellow parent and hater of YouTube Kids, I've thought about building a replacement.

What holds me back is knowing that -- if this was an iPad app, for example -- I'd be at the mercy of both Google AND Apple. It's a minefield of sensitive topics:

- Kids & privacy

- Content moderation

- Intellectual property

- Third-party UGC

Way too risky.

Great little product! Seems like this could actually make good money with the right marketing.

Are you doing anything special to leverage TikTok or Instagram Reels? I notice you had a few sample posts. I'd go hard on that if you're not already: post yourself, hire micro influencers, etc.

3 that I always watch for:

- Lenny's newsletter. While lately it's become mostly about how to succeed as a PM in Big Tech, he occasionally covers juicy startup tactics. For example, "What is good retention?" was solid gold.

- Casey Newton's Platformer. Balanced and insightful coverage of breaking industry news

- Data Analysis Journal. Goes deep on many growth topics, with tons of real SQL code from an experienced practitioner, which is extremely hard to find.

https://www.lennysnewsletter.com/ https://www.platformer.news/ https://dataanalysis.substack.com/

A rule of thumb I sometimes use to assess products, including ones I've built:

Looking back at the last year, are you (or your users) happy with the time spent using the product? Do you/they regret it?

Juicing short-term engagement can be effective for startups, but it isn't everything, and doesn't necessarily lead to lasting value.

Everyone seems to be missing the obvious reason they want you to view Wrapped in the app: because they want you to share it to your stories on Instagram, Snapchat, etc, which you cannot do on the web.

When Wrapped came out a few days ago, virtually every person I follow on IG had shared their Spotify Wrapped. It's phenomenal marketing.

Great interview with Nick about this and other topics:

https://www.joincolossus.com/episodes/20135760/kokonas-know-...

Got a source? I can only find references to training on amateur games (e.g. https://en.wikipedia.org/wiki/AlphaGo_versus_Lee_Sedol#Alpha...)

I would call its style unorthodox rather than nonhuman. It still plays common josekis (standard opening sequences) but often chooses uncommon variations. Its mid game is full of startling moves backed by VERY good reading. There's definitely still discernible strategy that us mortals can learn from.

If I recall correctly, the version that beat Lee Sedol was trained on amateur games plus self-play. My guess would be that this new version relies more heavily on pro games.

One technique that can be useful is imposing domain-specific restrictions, then passing responsibility down the chain.

For example, most people only have a handful of recent conversations; can you get away with ignoring distant-past conversations when it comes to read/unread marking? If so, you could send recent normalized data to the frontend and let it derive the unread state client-side. React has some nice tools for efficiently deriving state from server-sent data.

This isn't always the best solution, but it's something to consider.

It's my experience with their web-oriented and JavaScript projects. They definitely put out lots of high quality open source work in other domains.

It's interesting to contrast how Google and Facebook both approach open source for the web.

Google tends to release code and promote it without really using it much internally first. Documentation is prolific but confusingly organized and often fragmented among several versions simultaneously (cough, Google Analytics).

Facebook, on the other hand, actually seems to use their code before releasing and promoting it. Look at how they handled GraphQL: spec and reference implementation released a year ago, clearly labeled as a "Technology Preview". A lot of design work went into it before that, informed by the problems of internal product teams. Only a few days ago was it promoted as ready for production. The spec hardly changed it the last year. Documentation is good, and they work with the community to improve DX.

Why the difference? Hard to say, but my feeling is that there's a more direct link between Facebook's product-driven open source work and their bottom line. There are other startups constantly nipping at their heels, so they need to be on their game product-wise. Better code -> better products -> profits.

Google is largely impervious in the search and ad space, which is their cash cow. It almost doesn't matter how good or bad their other products are. The company is not at risk. Their open source work reflects that.

It looked like a risky dependency, simple as that. Despite the HN title, the point of the article was not to talk about React Router.

EDIT: Additionally, I'm not saying React Router is bad per se, just that it's not fully baked. I'm glad to see people working on the problem. I look forward to leveraging the fruits of their labor in the future (in fact, I already do - I use the history library on which RR is built).

You're not wrong. But it feels worse in JS. In both cases lib authors would do well to set proper expectations - if your lib is half baked, be up front about it.

Further thoughts: choosing an unstable library and then criticizing it for being unstable seems silly. There are two sides: library authors need to value things like careful design, real world testing, and backwards compatibility. Library consumers need to advocate for the same things, plus learn how to identify risk (semver isn't going to save you), and take ownership of their choices.

Yeah maybe. To me it feels like many in the community complain and shirk responsibility, and some stern words were needed to counterbalance that position. If the community wants stability in its projects, it needs to learn what it takes to achieve that.

Thanks for the thoughtful reply! I don't have a problem with strong opinions and harsh words when warranted, with the understanding that we're all learning.

What I wrote wasn't entirely in response to the HN thread. Similar thoughts about the JS community have been brewing for a while and the discussion prompted me to speak my mind.

It's hard. 1) Gain experience. 2) Talk to tech veterans and journeymen. 3) Look to other communities for lessons.

As programmers, we suffer from various maladies. NIH is one, laziness and shiny-chasing are others. As in life, balance is needed. Don't forget the cost part of cost/benefit analysis.

Things would also be significantly sped up if you compiled in production mode. From looking at your source, all the dev mode checks are still being performed. See:

https://facebook.github.io/react/downloads.html (the note under npm section)

https://github.com/facebook/react/issues/1772

http://stackoverflow.com/questions/22118915/how-to-turn-on-o...

I'm confused. The "demo" is just a screenshot? Seems promising but I would like to try it.

There's a React Dev Tools plugin for Chrome that will show a tree of components instead of the DOM.

SEEKING WORK - Remote, <6 month projects

Experienced developer with a keen aesthetic sense. I've worked with startups, corporations, government.

Favorite buzzwords: Clojure, Scala, JavaScript, Backbone

Recently:

https://kavyar.com/ - Frontend (Backbone), backend (Scala)

https://www.gorecess.com/ - Frontend (Backbone)

More:

http://jkkramer.com/

Clojure Doc is easier since it doesn't require a CA.

IRC (#clojure and #clojure-doc on Freenode) is good for coordinating with other contributors.

Please do. Good writers like yourself can make a big difference right now. There's also the Clojure Doc project - http://clojure-doc.org/

You are not forced to pass strings. That's merely a convenience (for Java). You can construct and pass data structures instead.

Nice. Slow to load, but worked.

I wish I could specify preferred theaters. In my area, there are many theaters nearby, and the closest isn't the best.

As a customer, I'm happy. I loathed the idea of maintaining separate queues, to the point where I started writing a unified queue web app in preparation.

As a developer, I wonder if they're still sticking to their plan to make the API streaming-only? [1] As much as I didn't like the idea of Qwikster, I was hoping it would provide a dependable DVD API.

http://developer.netflix.com/blog/read/Upcoming_Changes_to_t...

I don't know if it uses "event sourcing" per se, but doesn't HN use in-memory & serialized Lisp data structures instead of a DB?