Ken's Notes

Advice for CS students

Wed, 18 Mar 2026 09:30:22 -0700

Modern large language models (LLMs) are a new kind of power tool that disrupts software engineering. Our field has shifted several times before, but this one is a doozy. A conversation with a friend led to him asking “What would you encourage new computer science graduates or current CS students to focus on to make themselves successful?” It’s a natural question when it feels like a sea change is transforming the field.

Pattern pickup in practice

Mon, 09 Mar 2026 09:15:22 -0700

In my post about AI agents as power tools I wrote that agents are good at picking up existing patterns. Here’s a concrete example of what that looks like—both the strengths and the limits.

The setup

I have a project using SQLite with a bespoke database versioning and migration system. Nothing fancy, just a version number stored in the database and a set of migration functions that upgrade from one version to the next. The kind of thing you write when you need migrations but don’t need a framework.

The agent is not your colleague

Mon, 02 Mar 2026 08:45:17 -0700

In my post about AI agents as power tools I ended with “don’t confuse the tool for the craftsperson.” This is worth expanding, because the confusion runs in both directions and both cause problems.

The mentorship trap

AI agents communicate in natural language. They say “I” and “I think” and “let me try.” They apologize when they make mistakes. This makes it easy to treat them like junior colleagues who work very fast.

Architecture matters more with AI

Mon, 23 Feb 2026 20:05:02 -0700

In an earlier post I wrote that code communicates to the computer and to future readers. With AI coding agents, there’s a third audience: the agent itself. The agent reads your code to understand how to extend it. Good architecture makes this communication clearer. Bad architecture makes the agent confidently generate more bad code.

AI agents are very good at using well-designed components. They are not very good at designing them. They can implement against a clear interface, follow established patterns, and generate code that fits into an existing structure. They struggle with deciding what the interfaces should be, knowing which abstractions will age well, and understanding the domain deeply enough to decompose it correctly.

Testing for AI coding agents

Mon, 16 Feb 2026 09:30:02 -0800

AI coding agents can move fast. The constraint on their productivity is correctness. They are always confident, but they need clear, automatic signal about correctness otherwise a human ends up providing all of that signal (slowly). A robust test suite can ensure the confidence aligns with correctness. The shape of the test suite matters as much as its existence.

Interface tests vs internal tests

Tests that cover publicly exposed interfaces without depending on internal implementation details are a force multiplier for AI agents (and humans). These tests define what correct behavior looks like without dictating how that behavior is achieved. An agent can refactor freely, restructure internals, rewrite implementations entirely—and as long as the tests stay green, the changes are probably safe. A “perfect” test suite would cover the entire set of visible behavior, so a green suite would mean correct software. Don’t let the difficulty of a perfect suite prevent building a good one, and consider how lower development costs and higher ROI on tests may mean aiming closer to “perfect” than you might have once.

AI agents are power tools

Mon, 02 Feb 2026 08:15:22 -0800

In my last post I called AI coding agents “power tools for software developers.” The characteristics of power tools explain the capabilities, current limitations, and exciting opportunities of coding agents.

A table saw doesn’t know what you’re building. It doesn’t care if you’re making a bookshelf or a coffin. It will cut whatever you feed it, exactly where you guide it, with tremendous speed and force. The saw has no judgment. It has no taste. It won’t tell you that your design is ugly or that the joint you’re about to cut won’t hold weight. It does precisely what you tell it to do, including cutting your fingers off if you put them in the wrong place.

Solving problems

Thu, 29 Jan 2026 12:15:22 -0800

Years ago I wrote about my enthusiasm for automation of toil. The advent of coding agents is the first time I’ve faced automation of a task I enjoy. I enjoy developing software, and I enjoy coding.

For fun projects, the ‘return’ on the investment is ‘fun’—and sometimes the fun is in the coding, sometimes it’s in solving the problem, and sometimes it’s in solving the problem by coding.

I found programming fairly young. I was lucky to have a computer and a technologist father who encouraged my interest. I enjoyed coding: making something “go”. I also enjoyed solving problems. Initially these were problems like “how do I make it do what I want” or pursuing an interest in a language or tool.

MAVEN Launch

Thu, 21 Nov 2013 22:57:24 -0753

It was Monday, November 18, 2013 around 10:00 a.m. and I was standing in a humid Florida parking lot in the midst of a large crowd of people. We were all waiting to get on one of the many buses that had gathered there.

We all had good reason to be waiting in that parking lot. The buses were going to the NASA Causeway where we would get to see a rocket launch a spacecraft on its way to Mars.

Mock service dependencies

Fri, 15 Apr 2011 21:34:34 -0753

Suppose you’re building a service that depends on several other services to work. You write a bunch of code and carefully include error handling code and have a plan for what happens if each service your new service calls fails. Naturally, you want to test your code. These services are invoked over a network. Perhaps they’re web services but they may be some other network protocol. Suppose further your code is nicely factored so there’s a “client” class that presents the network service as a library API to the rest of the service.

Communicating in code

Mon, 28 Mar 2011 21:42:09 -0753

Code is communicating. Communicating with the computer to make it do something useful. Communicating with the future people that will read and maintain the code.

The former doesn’t care how clever you are. The latter may know where you live. The latter may be you.

Make a decision

Sun, 13 Mar 2011 17:22:43 -0753

You’ve got a choice to make. You’ve carefully written down the various attributes you care about and how well each choice lines up with those attributes. You’re having a hard time making a decision because with the information you have now they all look very similar. One of the following is true:

You’re missing attributes with which to evaluate the choices, attributes which would differentiate the choices for you
You’re incorrect about how well the choices match your evaluation criteria
There really is no difference between the choices given information you can have now (ruling out somehow getting future knowledge)

Don’t discount the possibility that the situation is the last one. Due diligence is important but don’t block forever waiting for some flash of information that will never come. Don’t discount the opportunity cost of not making the decision and moving on to the next thing to do – sometimes that outweighs any potential cost caused by picking the worst possible choice among those you have selected. Never spend more energy on a decision than the cost of being wrong.

Learning debugging

Thu, 06 Jan 2011 22:57:24 -0753

In my learning programming post I wrote about some approaches for learning to program and linked to a bunch of resources. Some of my insightful friends pointed out that most programming teaching doesn’t cover debugging and that lack leads to a lot of frustration. This is particularly hard on those working alone or with other people that don’t know how to debug.

Debugging is the art of figuring out why a system doesn’t work. The skills of debugging apply not just to errant programs but to any system that needs diagnosis.

Learning Programming

Tue, 04 Jan 2011 23:22:48 -0753

I’m interested in how people learn to program. Over the past few years, friends or relatives have asked me about resources for learning to program for themselves or for people they know. I’ve collected and refined that advice here. It’s hard to know what approach will work for someone to learn to program. It’s hard work so it’s important that each step be interesting and rewarding enough to keep going particularly when there’s no external force such as formal courses.

The Robustness Principle and internal APIs

Fri, 15 Jan 2010 20:48:40 -0753

RFC 761 section 1.2.2.

2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

RFC 1122 elaborates with section 1.2.2.:

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: “Be liberal in what you accept, and conservative in what you send”

Saving time

Sat, 18 Mar 2006 15:55:10 -0753

I’m pretty passionate about automating tasks. I don’t think people should spend time doing things that computers can do, especially when automating those things is easy. I have, in the past, slid down expansive, deep ratholes writing a program to automate some grunt work or another. Sometimes the time to write the program takes longer than doing it by hand, but I believe the time was still well spent because of learning during the automation or because of how unlikely it is that the grunt work will really only have to be done once.

Being a software developer

Wed, 15 Mar 2006 22:14:30 -0753

I’m a software developer. There are tools I like and have successfully built applications using but I also enjoy learning new tools and languages.

My goal is to use the best tool for the job. Most of the time the “best tool” is not a choice based entirely on the merits of one platform over another. If I want to hack my WordPress install, I have to use PHP. If I want to use Lucene for something, I have to use Java.

Engineering yourself out of a job

Thu, 31 Mar 2005 16:28:42 -0753

I once presented my vision for how a group could automate enough of a bunch of content publishing tasks to allow the people that created the content to take care of publishing site refreshes rather than requiring the involvement of engineering folks and doing code-and-content pushes.

The person I was talking to responded, “Are you trying to engineer yourself out of a job?”

It was a startling moment because our new product development was usually gated on engineering effort – freeing up our time to focus on product development and making the content creator’s job more rewarding by allowing them to make and publish content on their own seemed like a win for everybody. Of course I wanted to engineer us out of the job of pushing content so we could focus on improving the code.

The future audience

Sat, 08 Jan 2005 13:02:35 -0753

The future audience weighs heavily on me when I’m writing things to post to the Internet. I assume virtually everything I post to the Internet could eventually be read by anyone I know now or may know in the future. I am fortunate that I went through the most pronounced part of my angry, stupid new Internet teenager phase in a forum with less robust archiving than Usenet.

It should matter less to me but it’s hard to post something that says anything at all when all I can think of is how will this seem years from now to people I don’t even know yet.