4 ms·

I'm nearing greybeard status, so I have to chime in on the "get off my lawn" aspect. There is no one general "good engineering". Everything is different. Label

I'm nearing greybeard status, so I have to chime in on the "get off my lawn" aspect. There is no one general "good engineering". Everything is different. Labels suck because even if you called one thing "microservices", or even "monolith of microservices", I can show you 10 different ways that can end up. So "modular monolith" is just as useless a descriptor; it's too vague. Outside of the HN echo chamber, good engineering practice has been happening for decades. Take open source for example. Many different projects exist with many different designs. The common thread is that if a project creates some valuable functionality, they tend to expose it both at the application layer and library layer. They know some external app will want to integrate with it, but also they know somebody might want to extend the core functionality. I personally haven't seen that method used at corporations. If there are libraries, they're almost always completely independent from an application. And because of that, they then become shared across many applications. And then they suddenly discover the thing open source has been dealing with for decades: dependency. If you aren't aware, there is an entire universe out there of people working solely on managing dependencies so that you, a developer or user, can "just" install software into your computer and have it magically work. It is fucking hard and complicated and necessary. If you've never done packaging for a distro or a language (and I mean 250+ hours of it), you won't understand how much work it is or how it will affect your own projects. So yes, there are modular moniliths, and unmodular monoliths, and microservices, and libraries, and a whole lot of varied designs and use cases. Don't just learn about these by reading trendy blog posts on HN. Go find some open source code and examine it. Package some annoying ass complex software. Patch a bug and release an update. These are practical lessons you can take with you when you design for a corporation.

ryze20245 2y ago
I read this yesterday and then came back today to upvote and comment because I thought it was so beautifully said
rramadass 2y ago
Well said! I am already in the latter half of my fifties and find articles/discussions like these irksome and a sad reflection on the state of knowledge of the Programmers today. Everything is merely cookie cutter recipes, patterns, cute jargons/acronyms, a general lack of understanding of computation models/paradigms, an inability to disambiguate actual concepts from language constructs, a lack of knowledge of fundamentals/important nuances all of which leads to simplistic cargo-culting. There seems to be no emphasis on thinking through the problem and a solution but only an eagerness to reach for the latest faddish framework/library/pattern to put together something and "make it work". Reminds me of Tesla's observation on Edison; “His [Thomas Edison] method was inefficient in the extreme, for an immense ground had to be covered to get anything at all unless blind chance intervened and, at first, I was almost a sorry witness of his doings, knowing that just a little theory and calculation would have saved him 90 per cent of the labor. But he had a veritable contempt for book learning and mathematical knowledge, trusting himself entirely to his inventor's instinct and practical American sense. In view of this, the truly prodigious amount of his actual accomplishments is little short of a miracle.”
- throwaway984393 2y ago
  [dead]
transpute 2y ago
> If you aren't aware, there is an entire universe out there of people working solely on managing dependencies so that you, a developer or user, can "just" install software into your computer and have it magically work. It is fucking hard and complicated and necessary. If you've never done packaging for a distro or a language (and I mean 250+ hours of it), you won't understand how much work it is or how it will affect your own projects. When new employees joined the engineering org at a former employer, they were required to spend six months on the sustaining team, where they could be assigned customer-escalated bugs in any part of the codebase. Under the clock to deliver a hotfix for production customers, they would be required to learn a new area of the complex codebase, work with specialists in that area, develop/test a fix and shepherd it through review/approval by senior engineers. Those who survived this process could apply to the subsystem team of their choice. There is much for developers to learn from a period of apprenticeship in cross-platform software packaging. Start with .deb/.rpm, then image customization, A/B upgrades, stateless systems and work up to reproducible builds with Yocto, NixOS, Guix. In the next few years, SBOMs (software "bill of materials" aka package provenance) will become mandatory in some regional and vertical markets. This will either cause a reduction in dependencies, or increased attention to software supply chain relationships that bring regulatory costs.
kiitos 2y ago
The folks who maintain system-level package managers (apt, rpm, etc.) love to equivocate their stuff with language-level package/dependency managers. But the folks who maintain language-level package/dependency managers essentially never reference system-level package manager stuff. Which makes sense. They're categorically different things. System-level package maintainers are, often, stuck in an anachronistic model of software delivery.
- throwaway984393 2y ago
  [dead]

ryze20245 2y ago

I read this yesterday and then came back today to upvote and comment because I thought it was so beautifully said

rramadass 2y ago

Well said! I am already in the latter half of my fifties and find articles/discussions like these irksome and a sad reflection on the state of knowledge of the Programmers today. Everything is merely cookie cutter recipes, patterns, cute jargons/acronyms, a general lack of understanding of computation models/paradigms, an inability to disambiguate actual concepts from language constructs, a lack of knowledge of fundamentals/important nuances all of which leads to simplistic cargo-culting. There seems to be no emphasis on thinking through the problem and a solution but only an eagerness to reach for the latest faddish framework/library/pattern to put together something and "make it work". Reminds me of Tesla's observation on Edison; “His [Thomas Edison] method was inefficient in the extreme, for an immense ground had to be covered to get anything at all unless blind chance intervened and, at first, I was almost a sorry witness of his doings, knowing that just a little theory and calculation would have saved him 90 per cent of the labor. But he had a veritable contempt for book learning and mathematical knowledge, trusting himself entirely to his inventor's instinct and practical American sense. In view of this, the truly prodigious amount of his actual accomplishments is little short of a miracle.”

throwaway984393 2y ago
[dead]

transpute 2y ago

> If you aren't aware, there is an entire universe out there of people working solely on managing dependencies so that you, a developer or user, can "just" install software into your computer and have it magically work. It is fucking hard and complicated and necessary. If you've never done packaging for a distro or a language (and I mean 250+ hours of it), you won't understand how much work it is or how it will affect your own projects. When new employees joined the engineering org at a former employer, they were required to spend six months on the sustaining team, where they could be assigned customer-escalated bugs in any part of the codebase. Under the clock to deliver a hotfix for production customers, they would be required to learn a new area of the complex codebase, work with specialists in that area, develop/test a fix and shepherd it through review/approval by senior engineers. Those who survived this process could apply to the subsystem team of their choice. There is much for developers to learn from a period of apprenticeship in cross-platform software packaging. Start with .deb/.rpm, then image customization, A/B upgrades, stateless systems and work up to reproducible builds with Yocto, NixOS, Guix. In the next few years, SBOMs (software "bill of materials" aka package provenance) will become mandatory in some regional and vertical markets. This will either cause a reduction in dependencies, or increased attention to software supply chain relationships that bring regulatory costs.

kiitos 2y ago

The folks who maintain system-level package managers (apt, rpm, etc.) love to equivocate their stuff with language-level package/dependency managers. But the folks who maintain language-level package/dependency managers essentially never reference system-level package manager stuff. Which makes sense. They're categorically different things. System-level package maintainers are, often, stuck in an anachronistic model of software delivery.

throwaway984393 2y ago
[dead]