The First Principles Mindset: Deconstructing Problems Before Writing a Single Line of Code

First principles is not a clever technique. It is mostly the discipline of refusing to start from someone else's answer, and it is slower and more boring than it sounds. I still think it earns its keep, and I will defend that with one job that nearly went the other way.

A fabrication shop ran a laser tube cutter. Steel and aluminum profiles came in six-meter stock lengths, and the day's orders needed short pieces cut from them. The ask was a "smart scheduler" that would tell the operator which order to load which stock in, to waste as little material as possible. The team's first instinct, and mine for about an hour, was that this was a bin-packing problem. So reach for a constraint solver, model it, let it chew on the orders overnight, get an optimal cut plan in the morning.

I almost wrote the integration. Then I went and stood next to the machine for a shift, which is the only part of this I would call a method.

The operator was not optimizing for waste. The expensive thing in that shop was not the offcut going into the scrap bin. It was the changeover. Every time the profile cross-section changed, round tube to square, 40mm to 50mm, the operator swapped the chuck jaws and re-zeroed the machine. That was eight to twelve minutes by the clock, several times a shift. The scrap from a worse cut plan was a few euros of steel. A changeover was twelve minutes of a machine that bills by the hour. We had been told to minimize the cheap thing.

This is the part I trust. Strip the problem down past the words people hand you, past "scheduling" and "optimization," until you hit the quantity that actually costs money, and check it against the floor with a stopwatch. The solver was an answer to a question nobody on that floor was asking.

The aerospace habit underneath it is the same. On a 737 you do not start a weight-and-balance from the loaded weight someone wrote on the sheet. You go back to the empty operating weight, the arm of every station, and you add the moments up yourself, because the number you were handed already folds in assumptions you cannot see. Deconstructing down to the load on a station is not academic. It is what keeps you from inheriting someone else's mistake.

So the scheduler did not get a solver. Once the real cost was the changeover, the structure fell out on its own. Group the day's cuts by profile so the machine changes setup as few times as possible. Then sort within each group longest-piece-first so the leftovers stay long enough to reuse tomorrow. That is a group-by and two sorts. It ran in milliseconds, the operator could read the plan and see why it was ordered that way, and there was nothing to babysit. Changeovers dropped from several a shift to two or three. Waste went up a little, and nobody cared, because we had finally measured the thing that cost money.

The value of first principles is almost all in that step, before any code exists. The deconstruction is the work. The code after it was forty lines.