I work at a small company on a single page webapp. Since we're working on a subscription-based product, we need to focus on fixing bugs and improving usability

I work at a small company on a single page webapp. Since we're working on a subscription-based product, we need to focus on fixing bugs and improving usability to make our users more productive and more happy. This should place us in firmly the third camp of pragmatic professional software engineers. But I don't agree with the trichotomy outlined in the article. We spend plenty of time and effort doing "programming as hardware hacking" to implement a backend that can process our customers' data orders of magnitude faster than our closest competitors: This allows our customers to obtain analysis results in minutes/hours instead of days/weeks. We didn't get there with the third-camp sentiment that "The program only has to be fast enough for the users" - if we did, we wouldn't be leaders of the (niche) industry that our customers operate within. Then again, we spend plenty of time doing "programming as applied mathematics". Our software inherently consists of a lot of geometric algorithms. To give a recent example, a couple colleagues and I spent a couple days last month to fix a buggy geometric primitive: Given an almost-simple polygon, which is made by joining the endpoints of a polyline without self-intersections with a straight edge, compute its area. We had a seemingly-correct, but complicated and evidently buggy, implementation that needed to be used in a new user-facing feature (contour-line simplification). After several whiteboard sessions and do-overs, we found a simple formulation of the problem that admitted a simple and obviously correct implementation. The buggy area computation didn't cause any crashes or other obstructions to the user, but it created results that looked aesthetically unpleasing (because the lines were poorly simplified).