Jacob Kaplan-Moss

Tag: Programming

🔗 Using AI to build a tactical shooter (#)

Via RC’s AI article, a fascinating recording of someone programming a game almost entirely by prompting Claude by voice. This feels truly “futuristic” to me. Sure it’s clunky at times, but damn if this isn’t closer to the Star Trek computer than I ever thought I’d see in my lifetime.

July 28th, 2025 • ai programming

🔗 Developing our position on AI - Blog - Recurse Center (#)

Detailed, nuanced, and well-thought-out. Tons of great and insightful quotes from RC alums. And their conclusion is, I think, perfect:

You should use AI-powered tools to complement or increase your agency, not replace it.

July 28th, 2025 • ai llm programming recurse center

🔗 Thoughts on my first machine learning project (#)

Fantastic post about what building an ML system feels like.

November 11th, 2022 • ai music programming

📝 Quality Is Systemic

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.
September 9th, 2022 • programming psychological safety quality software

📝 Work Sample Tests: Wrap Up and Q&A

This is the final post in my series on work sample tests. It’s a wrap-up post: I’ll address a few random points I couldn’t quite fit in elsewhere, and answer some questions from readers.
January 6th, 2022 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: What doesn't work (and why)

I’ve written about a bunch of effective work sample tests and the “rules of the road” that make them effective. One thing I haven’t talked about is counter-examples: types of work sample tests that don’t work. I tend not to do this sort of thing: I find it’s usually more useful to talk about what does work than to pick apart what doesn’t. But here, I think it’s illustrative: looking at why certain kinds of work sample tests fail can help illustrate the principles of effective tests. Let’s look at a few kinds of work sample tests that (usually) fail, and why.
December 30th, 2021 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: Labs & Simulation Environments

The work sample tests I’ve covered in this series so far all involve software development. But what about roles that don’t involve day-to-day coding: roles like security analysis, penetration testing, technical support, bug bounty triage, project or program management, systems administration, technical operations, and so on? For those roles, I turn to simulated, “lab”-style environments. Here are some examples of that kind of test.
December 24th, 2021 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: ‘Reverse’ Code Review

For most software engineering roles, the best work sample test will be some combination of the exercises I covered earlier in this series. But not every role; there are some circumstances where other types of tests fit better or are better at revealing some critical piece of information relevant to hiring. This post covers one of them: a “reverse” code review, where instead of you reviewing the candidate’s code, you have them review yours.
December 15th, 2021 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: Bring Your Own Code

If you’re hiring engineers, some candidates will already have code they can share: side projects, open source, and so on. It’s silly to ask those candidates to write new code just for your interview if they already have code they can share. So, if you’re asking candidates to code as a work sample test, you should also offer to let candidates submit something they’ve previously written. Here’s how.
December 7th, 2021 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: Pair Programming

I tend to prefer asynchronous work sample tests. The flexible scheduling of asynchronous exercises (i.e. “work on this whenever you like”) works better for the majority of candidates. But for some candidates, and some roles, synchronous exercises work better. By “synchronous” I mean: work sample tests that are explicitly scheduled, and that has both the interviewer and the candidate working directly together at the same time. In these cases, I often turn to pair programming.
November 30th, 2021 • hiring interviewing management programming work sample tests

📝 Work Sample Tests: Coding “Homework”

Coding homework is my default work sample test: I use it for all engineering roles unless it’s obvious that another kind of exercise is better. There are good reasons to make homework-style work sample tests the default: they’re relatively easy to construct, they scale reasonably well to large hiring rounds, they’re accurate simulations of real work, and easier than most other kinds of tests to construct in a way that maximizes inclusivity. Here’s how to conduct a coding homework work sample test.
November 23rd, 2021 • hiring interviewing management programming work sample tests

📝 Peter Norvig on programming languages

Peter Norvig:

[Programming] language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don’t have those things you’re in trouble regardless of your language choice.

October 18th, 2010 • languages norvig programming quotes

📝 Backwards compatibility

Backwards compatibility is pain sometimes:

# We need backwards compatibility with code which spells it this way:
#   def my_view(): pass
#   my_view = cache_page(my_view, 123)
# and this way:
#   my_view = cache_page(123)(my_view)
# and this:
#   my_view = cache_page(my_view, 123, key_prefix="foo")
# and this:
#   my_view = cache_page(123, key_prefix="foo")(my_view)
# and possibly this way (?):
#   my_view = cache_page(123, my_view)
June 9th, 2010 • backwards compatibility programming

📝 Professionalism

Yes, it’d be nice if contractors kept up to date on the progress of the various building codes. They don’t. There are a lot of people who asked about the building codes in the 1970s and were told (right or wrong) what they were. So they went ahead and learned their trade, build their homes, and chose watching a DVD or spending time with their kids over watching city council do battle over asbestos insulation. Now all of a sudden they’re told that their work isn’t up to code any more. Some waiting and gnashing of teeth is to be expected. What’s needed is less “boy, aren’t I smarter than them” snideness and more “Hey, here’s what’s up.”

July 4th, 2009 • professionalism programming software

📝 "Syntactic Sugar"

It frustrates me when I hear people dismiss the differences between computer languages. There really isn’t any difference between languages, the argument goes, because “all Turing complete language differ solely on syntactic sugar.”

That’s a direct quote from part twelve of Michele Simionato’s excellent The Adventures of a Pythonista in Schemeland, but I’ve got no beef with his articles. Like I say, they’ve been an excellent introduction to Scheme for me. However, I’ve seen this particular assertion – “all programming languages are the same because they’re all Turing complete” – used repeatedly as long as I’ve been a programmer. It drives me nuts.

November 22nd, 2008 • languages programming syntax