> we talk about programming like it is about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues.
A thousand times this! This puts into words something that's been lurking in the back of my mind for a very long time.
> Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent?
Considering that programing and tools used for it are not for computers but humans, and that apart from most trivial things more than one people is necessary to make something that work on/with computer(s), it is no surprise that SE is much more social science than many would like to admit or feel comfortable with, over-emphasizing its natural science part to the level of failure eventually (on the product level aimed at addressing needs of the people). Probably because social sciences are very fluid and much less reliable than natuaral sciences, so we have an inner tendency avoiding the social bit, or handling it on a very primitive level? I do not know, this is a feeling. So much focus on atomic details of technology yet the group effort of the product is still rubbish too many times.
> The first chapter of the book claims, "The major problems of our work are not so much technological as sociological in nature". The book approaches sociological or 'political' problems such as group chemistry and team jelling, "flow time" and quiet in the work environment, and the high cost of turnover
I’ve been drumming this for so long now, even before I heard of (let alone read) this book.
I feel that the development of psychology and sociology has been lost on the workplace and it isn’t well applied. Executives want everyone to be widgets except themselves, even when study after study shows that for companies to perform optimally their workers must feel well compensated, well valued, balanced freedom in the workplace, chances for advancement etc.
In many respects you could apply psychology and sociology to how products should / could behave etc. as well, which I’m sure due to the monetary component some companies have taken seriously at least in some periods of their lifecycle, like Apple under Steve Jobs in his comeback
I switched to samurai for the few things I have that still used ninja; it's an improvement in every possible way.
But regardless, I think those kinds of build systems are just wrong. What I want from a build system is to hash the content of all the transitive inputs and look up if it exists or not in a registry.
Man, I was so afraid this was going to be about Fortnite. Turns out it was a fantastic read. I feel really sad but unsurprised about his description of what it's like to be an Open Source maintainer.
> users of ninja ... all Meson projects, which appears to increasingly be the build system used in the free software world;
So, AFAICT, that hasn't turned out to be the case.
> the code ends up being less important than the architecture, and the architecture ends up being less important than social issues.
Well... sometimes. Other times, the fact that there's good code that does something goes a very long way, and people live with the architectural faults. And as for the social issues - they rarely stand in opposition to the code itself.
> Some pieces of Ninja took struggle to get to and then are obvious in retrospect. I think this is true of much of math
Yup. And the some of the rest of math becomes obvious when some re-derives it using alternative and more convenient/powerful techniques.
> fetching file status from Linux is extremely fast.
It of course depends on what your definition of "fast" is. In the extremely-slow world of frequent system calls and file I/O, I guess one could say that.
> I think the reason so few succeed at this is that it's just too tempting to mix the layers.
As an author of a library that also focuses on being a "layer" of sorts (https://github.com/eyalroz/cuda-api-wrappers/), I struggle with this temptation a lot! Especially when, like the author says, the boundaries of the layers are not as clear as one might imagine.
> I strongly believe that iteration time has a huge impact on programmer satisfaction
I'm pretty certain that the vast majority developers perform 10x more incremental builds than full builds. So, not just satisfaction - it's just most of what we do. It's also those builds which we wait-out rather than possible go look for some distraction:
OTOH, the article doesn't mention interaction with build artifact caching schemes, which lessen the difference between building from scratch and building incrementally.
> Peter Collingbourne found Ninja and did the work to plug it into the much more popular CMake ... If anyone is responsible for making Ninja succeed out there in the real world, Peter is due the credit.
It is so gratifying when a person you didn't know makes your software project that much more impactful! Makes you really feel optimistic again about humanity and socialism and stuff.
A thousand times this! This puts into words something that's been lurking in the back of my mind for a very long time.
reply