I work in an industrial physics and mathematics domain, and in that domain specifically, I must say it is very charitable to describe a majority of software engineers as doing "applied mathematics", if we are to interpret that as meaning "software engineers are participating in the practice of doing research mathematics." Except perhaps in some extremely reductionist view of what it means to "write a program" (e.g., programs are proofs, Curry-Howard, or some other idea), I don't think "applied mathematics" truly characterizes the work of, say, someone writing out a GitHub Action or adding a new RESTful endpoint to list a company's product catalog.

There's a pattern amongst software engineers in these and other discussions. When it comes to discussing management and resource estimation, some people describe software as the most arcane, idiosyncratic craft to exist. In other situations (e.g., where actual research mathematics or computer science is proposed to be used to solve a problem), software engineering has to be "simple", "aligned with best practices", and almost anti-intellectual.

The pattern of discussion (here and elsewhere), to me, indicates a survival instinct of sorts, if that makes sense. To this end, there's a sort of hypocrisy if it means being a software engineer is as unrestrained as possible: software is purported to be like applied mathematics in situations where it's advantageous to describe it as such (e.g., "we can't estimate because proving conjectures is intrinsically unpredictable") , then when the proposition is brought forth to engage with software as applied math (e.g., "team, we can bound the 99%ile perf by proving this recurrence on resource usage, and that'll give us evidence to modify our search algorithm with an adaptive radix tree."), software engineers push it away for something satisfactory to a CS101 student (e.g., "we can just implement auto-completion of our product catalog by searching a sorted array of item names, why complicate it?").

I understand the troubles of estimating resources for tasks and projects, and indeed the requests can sometimes be unrealistic and overbearing—I don't mean to suggest otherwise—but even the most technically sophisticated pieces of software are flush with "ordinary" kinds of programming tasks.

Plumbers are doing applied physics, not rendering a button on a webpage. Try telling a physicist to provide an "estimate" for the cost of proving the big bang theory. Why should you expect an estimate for fixing your leaky bathroom faucet?

Half this site is crapping its pants over being replaced by AI being able to do their jobs with a prompt yet it thinks their work is sooo novel and unknowable.

You're not seriously comparing research mathematics with software development, are you? You think you're expanding the breadth of human knowledge with your CSS tweaks of the shopping cart implementation? Give me a break.

We're performing applied mathematics, but we're performing that task as engineers. The key is in 'applied'. Going from theory to practice takes planning and is not as unbounded as performing science in my opinion.