Online coding and Python classes in Brentwood

Ordnance Survey's Code-Point Open file gives a map coordinate for every postcode in Great Britain. In the CM file, 2,144 postcodes carry the Brentwood district code, most of them in CM13, CM14 and CM15. The learner writes the obvious program: read the file, then for each postcode loop over all the others, call a small dist() function, and remember the closest. It is correct and it takes about 3.5 seconds. Asked why, most people blame reading the file from disk.

The profiler disagrees with the guess. Reading the file is under 2% of the run. Two thirds of the time goes on dist(), which is tiny but is called 4,594,592 times, once for every ordered pair of postcodes (2,144 times 2,143). That number, not the function's length, is the problem. Profiling slows a program down, which is why the profiled run took 6.495 seconds; the timings below are from ordinary runs.

Version 2 attacks the cost of each call: it compares squared distances, so no function call and no square root are needed until the very end. That is worth 3.4 times. Version 3 attacks the count: it drops each postcode into a 500 metre grid square and looks only in neighbouring squares, widening the search only when needed. It compares 291,987 pairs, 6.36% of the original number, and runs 32 times faster. All three versions return exactly the same answer for all 2,144 postcodes, which the learner checks in code. Timings depend on the machine; the call counts do not.

It is a small habit, and it is one reason a Brentwood teenager who can code gets far more from AI tools than one who can only ask. The longer argument is in why teenagers should still learn to code in 2026.