INNOQ Blog

Joel on Software is a classic: http://www.joelonsoftware.com/
Sadly, a few years ago he mostly stopped writing about business and architecture, but the archives from around 2000 to 2005 are really good, and mostly timeless.

infoq.com has lots of good articles and talks, some language- or technology-specific, but most with a focus on architecture.

The O'reilly Head First books "Object-oriented architecture & design" and "Design patterns" are somewhat basic, but an excellent and accessible start.

For something deeper and harder to digest in book form, try some of the classics like Eric Evan's "Domain-driven design", or Martin Fowler's "Patterns of Enterprise applicaton architecture".

As for some specific styles, try typesafe's manifesto and description of reactive applications, Hohpe's "Enterprise Integration patterns" for pipes-and-filter architectures, and anything by Stefan Tilkov (https://www.innoq.com/blog/st/) for REST.

Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other.

People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature:

https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692

https://www.innoq.com/en/blog/native-clojure-and-graalvm/

Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.

>communication is used to elect a random group member and follow her lead toward the option she would have chosen if alone... in the context of a confusing puzzle where... the majority of individual choices are wrong, this tactic, intuitively adopted by groups, is strictly superior to majority decisions

Humans elect random leaders when the going gets tough?

Also:

https://phys.org/news/2025-06-impairs-teamwork-individual.html

https://www.npr.org/2025/06/03/nx-s1-5406260/a-surprising-trick-to-making-hard-choices-try-thinking-less

https://www.innoq.com/en/articles/2025/06/wieviel-denken-ertraegt-ein-team/

Some more details are here: http://www.innoq.com/blog/st/2012/03/announcing-roca/

"a set of rules to apply if the goal is to come up with a Web app that is actually on the Web as opposed to be tunnelled through the Web. We tried to come up with a catchy name, and finally arrived at ”ROCA”, a conveniently pronouncable acronym for “Resource-oriented client architecture”.

So rather than a manifesto, they're trying to devise a nomenclature, along the lines of how Ajax gave a name to non-page refresh server communication with the browser.

I'm not a Clojure programmer, but I have an interest in things that run on the JVM. I went through this semi-quick guide to get an overview of how the language and syntax works:

EDIT: actually this was the link I meant to post. It was on HN a couple weeks ago: https://docs.google.com/presentation/d/15-7qFy6URdE7Owi2LitkQI_OHBu1AFWPUwHxgBc-O4E/edit

EDIT: Not this link, though it looks interesting: http://www.innoq.com/blog/st/presentations/2010/2010-05-20-ClojureConcurrency--JUGD.pdf

Yes, here's a few excellent articles that explain what problems build tools solve and why they exist:

- https://sunsetglow.net/posts/frontend-build-systems.html

- https://www.innoq.com/en/articles/2021/12/what-does-a-bundler-actually-do/

- https://www.swyx.io/jobs-of-js-build-tools

Loosely put, they're the equivalent of all of `gcc` or `rustc`: compile the source code, run type checking, output object files, transform into the final combined executable output format.