not rolling your own

It is tempting, when you understand an algorithm, to write it yourself. You read how Gaussian elimination works, you see it is just a few nested loops, and you think: I can code that in an afternoon. 'Not rolling your own' is the hard-won professional wisdom that, for standard numerical tasks, you almost always should NOT — you should reach for a mature, widely-used library instead. The textbook algorithm and the trustworthy implementation are two very different things, and the gap between them is where careers' worth of subtlety lives.

Concretely, what does the library know that your afternoon version does not? It pivots to avoid dividing by tiny numbers (your version may divide by zero or amplify round-off catastrophically). It scales to dodge overflow and underflow. It handles the empty matrix, the singular matrix, the NaN in the data, gracefully rather than crashing or returning garbage. It is backward-stable by design, returning the exact answer to a nearby problem. It is fast, dispatching to blocked BLAS. And it has been run against millions of test cases by thousands of users for years, so the bugs you would spend months finding have already been found. A line like numpy.linalg.solve(A, b) is the distilled output of that entire history. Your loop is not.

The honest balance: 'don't roll your own' is a default, not an absolute law. Reimplementing an algorithm is a superb way to LEARN it, and you should do that on toy problems. There are also genuine cases for custom code — a problem so specialized no library covers it, or a research method that does not exist yet. The rule is really about WHERE to spend your scarce reliability budget: spend it on the novel science your problem actually needs, and stand on tested foundations for everything standard. The danger of rolling your own is not that it will obviously fail; it is that it will quietly give slightly-wrong answers on the hard cases, and you will trust them.