👋 Welcome

Every era of programming has been an argument about the same thing. How much of the work should the human do, and how much should we hand to the machine? Each time we have answered “give more to the machine,” someone has objected that the machine cannot be trusted with it, that real programmers work closer to the metal, and that the new convenience is a toy. And each time, within a decade, the convenience has become the floor that the next generation of programmers stands on without a second thought. This is a story about that floor rising. It runs from a woman feeding subroutines to a UNIVAC on tape in 1952 to a teenager in 2026 building a working web application by describing it to a language model in English. The technologies could not look more different. The motive behind them is identical. ...

Last month I put together a watch list about why thirteen colonies decided to become a country. This is the sequel, and it asks the harder question. Once they had won independence, why did Americans build their government the way they did? Why three branches instead of one strong executive. Why a Senate and a House. Why so much power stays with the states rather than collecting in Washington. None of that was obvious in 1787, and the people in the room disagreed about all of it. ...

On July 4, 2026, the United States turns 250. The formal name for a 250th anniversary is the Semiquincentennial; the shorthand everyone is using is America250. Either way, it marks a quarter-millennium since the Continental Congress adopted the Declaration of Independence in Philadelphia. I wanted to mark the occasion with something more durable than fireworks. This is a watch list. It is not a “greatest hits of patriotism” reel. It is a guided tour through one specific question. Why did thirteen British colonies decide they needed to become their own country? It was not inevitable. For most of the 1760s and early 1770s, the colonists wanted their rights restored within the empire, not a new nation. Something changed. This list is about what. ...

Building a DIY propane pool heating system to heat a 4,400 gallon above ground pool from 68°F to 85°F using a tankless water heater and submersible pump.

Details about the Intex above ground pool setup including padding, dimensions, and skimmer installation for the DIY propane heating project.

Comprehensive shopping list for building a DIY propane pool heater, including tankless water heater, submersible pump, hoses, filters, and all necessary components with Amazon links.

Step-by-step instructions for assembling and testing the DIY propane pool heater system, including water connections, propane setup, and safety testing procedures.

Daily operation procedures and maintenance schedule for the DIY propane pool heater system, including startup/shutdown procedures and troubleshooting tips.

Unexpected wildlife visitors to our DIY pool heater setup, including raccoon encounters that led to equipment damage and important lessons about protecting outdoor equipment.

I see human code reviews as one tool in the quality toolbox. My opinion is that to keep code reviews interesting and engaging, humans should be the last link in the chain and get the most interesting problems. What I mean is that if the code review is burdened with pointing out that an opened resource was not closed or that a specific path through the code will never happen, code reviews become draining and boring. I also believe that code reviews need to scale up to teams that are not co-located. That might mean using an asynchronous process, like a workflow system or using collaboration tools to do the code review through teleconferences and screen sharing. A workflow system can prevent code from promotion into the mainline build until one or more reviewers have accepted it. To keep the code reviews interesting and challenging, I give the grunt work to the machines and use static analysis and profiling tools first. Before you can involve the humans, your code needs to pass the suite of static analysis tests at the prescribed level. This will weed out all the typical mistakes that are larger than what a compiler finds. There are many analysis and profiling tools available in open source and commercially. Most of my development work is in server-side Java, and my analysis tools of choice are FindBugs, PMD and the profiling tool in Rational Software Architect. FindBugs is a byte code analyzer, so it looks at what the Java compiler produces and is less concerned with the form of source code. PMD analyzes source code. Both tools have configurable thresholds for problem severity and they can accept custom problem patterns. PMD has a big library of problem patterns, including things like overly complex or long functions or methods. The RSA profiling tool only tests timing down to the method level of classes. It can quickly help a developer focus on where the sluggish parts of a system are hiding, which is valuable information going into a review. Once the code makes it through this array of automated tests, bring the humans in to look at it and get their input. I have found this approach in our case changes the review from a potentially adversarial situation into one with an educational tone. The review meeting, if it happens synchronously, is not overtaken by the small problems and pointing out basic mistakes. It is concerned with making recommendations at a higher level to improve the larger design. FindBugs, U. of Maryland, http://findbugs.sourceforge.net/ PMD, SourceForge, http://pmd.sourceforge.net/ Rational Software Architect for WebSphere Software, http://www-01.ibm.com/software/awdtools/swarchitect/websphere/