That's interesting with the Zillow anecdote. I wonder if the nuance in the title is actually correlated with a difference in behavior/culture/best practices/approach?
agreed on the presence and stickiness of no-code tooling. but in a future where we want to enable LLMs and agents to do as much of that work as possible, a code-first approach seems far more likely to make that effective. not just because agents are better are writing code than clicking through interfaces (maybe that will change as agents evolve?), but because the SDLC is valuable for agents for the same reasons it's valuable for human developers - collaboration, testing, auditing, versioning, etc.
yeah, i've seen large fortune 100 data and analytics orgs where the majority of folks with data engineering titles are uncomfortable with even the basics of git.
We have these at my company. They refuse to do any infrastructure work so you have to spoon feed the databases to them ready to go. It’s pretty annoying.
Image caption: "The comet debris consists of a cluster of building-size chunks near the center of the image. They form a 3,000-mile-long trail, larger than the width of the continental U.S."
What am I not getting here? If the cluster in that image is 3K+ miles wide, then those are city sized dots, not building sized. I'm guessing the long tail is not actually in the image?
> What am I not getting here? If the cluster in that image is 3K+ miles wide, then those are city sized dots, not building sized. I'm guessing the long tail is not actually in the image?
It's probably two things. I think you're probably correct that the entirety of the tail is not in the image. Also, the size of the dots in the image probably reflects the resolution limit of Hubble, rather than the true angular size on the sky of the chunks.
Very interesting. I'm not convinced this captures the core value of containers though. Or at least not the only core value. Calling containers an evolution of configuration management tools seems like an oversimplification just to make a point. This may be one aspect of building a micro-service driven architecture that containers make easier, but there are other very important ones. Portability comes to mind. It's not just that you can build your stack once and save it, but that you can then run that stack anywhere, and it becomes much easier to share/borrow bits and pieces of other people's stacks.
To a certain degree I don't want to know what's in them. If I want to add search to my stack - initially I'd rather not have to have an intimate knowledge of Elastic Search, a task queue and whatever other moving parts there are. In many cases a black box that just works would be a fantastic option.
The reason hosted services are popular is for exactly this reason.
A wide understanding of different technologies is a wonderful thing but sometimes you just need to ship.
The conclusion of that article actually doesn't seem to be that the Hyperloop is technically infeasible - only that the original spec does have issues, and it glossed over those issues.
"I’m not saying that the problems with Hyperloop can’t be solved. Money, time, and talent can solve any problem that doesn’t involve breaking physical laws, but I wouldn’t put my money, time, or talent in the hands of someone who takes me for a fool."
