There are many angles.

Part of the low-code/no-code story is that conventional programming requires programmers to not just decide what has to be done but in what order to put those things. (This is connected with parallelism because if tasks are done in a particular order you can't do more than one at a time.)

An Excel spreadsheet is different from a FORTRAN program, for instance, because you can write a bunch of formulas and Excel updates the results automatically without you sequencing things.

https://en.wikipedia.org/wiki/Topological_sorting

is an easy approach to finding a valid order to do tasks in. It's used frequently in build systems but rarely in other software so it contributes to build systems seeming to be from another planet

---

I work in Java a lot and I used to hate Maven, because, if you look at Maven as "an XML vocabulary" you're going to frequently find "you can't get from here" and looking for answers in Stack Overflow is going to dig you in deeper.

The right way to think about Maven is that, like (part of) Spring, it is a system for writing XML files that configure a group of Java objects. Seen that way, writing a Maven plugin should be a second resort; the moment you're scratching your head wondering if it's possible to do something, you should (1) make sure you can't "go with the flow" and follow conventions, then (2) write a Maven plugin.

The thing is, a Maven plugin is just an ordinary Maven class. You're a Java programmer, you know how to do things in Java. All the skills you use everyday apply, you're no longer in a weird, mysterious and limited environment. That's part of the "makefile program"; you probably build your code (edit files in Java, C, whatever) 1000s of times for every time you change something about your build system. On a team you can be very productive if you know the main language but have no idea about how the build works (if the build the works.)

When you try this though you often run into political problems. In most places, for instance, only a few people on the team have the authority to create new maven projects (a plug-in is a class defined it's own project.) Maybe that makes sense because you don't want them breeding like rabbits, but a lot generally most systems are badly partitioned as it is, and I think many programmers wouldn't want to have the fight it would take to create a new project.

People are accustomed to builds being SNAFU and FUBAR.

When I first saw Maven I was baffled that, as a remote working on a system that had about 20 programmers and about 20 projects I couldn't build the system successfully at all. The build worked maybe 70% of the time at the office and people didn't seem to worry about it. I could live with that because they were building large complex systems that they were always throwing away and I was building simpler spike prototypes that worked.

I worked at a number of places where builds were unreliable in ways that seemed quantitative rather than qualitative, eventually I realized the problem was really simple, if you were using snapshot builds and a lot of people were working on a project and you didn't have any transaction control you would often get a set of snapshots that were not compatible with each other.

Most teams don't take builds seriously enough. I've found it rare to meet an engineering manager who can answer the question "how long does the build take?" and fantasize of going to a job interview, asking that question, and if I don't get an answer, standing up and walking out.

For many projects I've worked on I've built "meta-build systems" where the assumption is that have 12 maven projects and 4 npm projects or something like that (aren't most of us using mixed languages in the React age? why isn't this treated as a first-class problem), and such a system can be smart about what gets built and what gets doesn't, what is running out of snapshots and what can have a fixed version, etc. Merges in changes from develop automatically, and if seven steps are required that take a total of 15 minutes I ought to be able to think about something else entirely for 15 minutes and hear a "beep" when it's done.

Trouble is we don't take builds seriously enough: it's a technical problem and it's a political problem and we often don't face the technical problems because of the political problems.