stoicShell

Here's what most surprised me recently, which compounds all your points.

Middle of Nowhere, France, 11 AM. My Uber arrives, a cool Model 3, "huh, great!" I thought, "I'm gonna pry this guy's brain for info on EV's."

Sure thing the driver was a talker and over the course of the next 20 minutes proceeded to tell me all the good and bad, in his opinion — it was his 3rd or 4th EV.

Tesla is "out of this world" — his words. "And you know why? Because they have the best free charging network, period, others are not even comparable". Remember, we're in the middle of nowhere in a rural town. He points to me a couple gas stations on the map nearby: "I can charge there, super fast, no problem. But with any other brand, the German, the French, the Japanese? It's a mess. Nothing before 30-40 miles at least, can only charge during work hours, that sort of... problems. And Tesla's (sorta) free and has much more range to top it all."

Consider that we're talking infrastructure, Tesla being better than the French and German brands in France of all countries, about 200 km from the German border!

So, there's that. The headstart and pragmatism of Tesla, even far away from homeland, USA is big and consequential — it'll take years for others to catch up, and they're not heading this way as they all rely on different standards (NIH syndrome) and bodies like the EU haven't catched up on regulation yet (like they did e.g. for phone chargers normalized to micro-USB, now USB-C).

I know it's anecdotal, but for a professional driver it was pretty clear that Tesla is just about unchallenged in EV.

> statistically unlikely to pay off

> probabilities involved with your decision

While this is a good general approach to life IMHO as well — if you mean "be rational, not just emotional" and "work on your cognitive biases, seek objectivity" — it might also prove terribly counterproductive in this context.

It would take a book or five but briefly:

- you just can't use statistics when they say "95% fail", otherwise you just don't do startups, ever. With that mindset, joining an established company is more likely to "succeed" for you and maximize serenity.

- another stat for you: most entrepreneurs fail "about twice" before making it, i.e. you'll probably fail 1-3 times for sure before entering the 5% of those who create a profitable business. Trick #1, thus: you can roll the dice several times (consider 2-5 years per "real try").

- most valuable ideas were either not identified (rarely) or not well executed (often) before someone eventually nails a product. You thus iterate quickly on the market (MVP, feedback, lean cycles, etc) to find your best fit curve, to hone in on the product that works. Chances are you'll find a local minimum, not "the best", you'll pivot, you'll reconsider, you'll maybe focus entirely on a subsystem, a 'feature' become 'product' — think how Docker, the company, appeared after the same name product.

The reality is that a "fast scaling startup" a la California is rare and a moonshot most often — unicorns and all that — but a diligently conducted, ground, sustained effort to make a business growing organically to reach sustainability for you and a few others in 2-5 years is a realistic goal (but all things considered, e.g. probably not on your first try, likely 10 years after you began for the first time).

I don't want to claim that it's easy to create a business, it's by far harder than working the jobs in most cases; but SMBs make up anywhere from 80 to 90% of our economies, they're the real bread and butter of our collective wealth, and these 'small' entrepreneurs are our true heroes. Not many of them make it big, and that's the 'gamble' you speak of, but it's not the only way, nor is it at all required to go down that path.

Microsoft's board sure pulled off a winning strike with Nadella. From "almost IBM-dinosaur" to biggest market cap on Earth pretty much tied with Apple, and massively reversing public image from hated to just about liked by many. Huge win for Nadella. He sure loves what he does, money is besides the point.

But then again it's so obvious in his case, I mean I and probably many saw it coming — the man just does not operate at the same level, he's stellar you know, like the Jobs and Musks and Waltons of this world).

I have no hope for Boeing to recruit such a great man, I don't think that kind of business actually wants that. Imagine a Dorsey / Musk disruptor, pushing open standards, thinking of direct B2C, whatever... That just wouldn't fly with Boeing's board and mindset (oh pun so very much unintended yet so apt).

I think we agree on the general perspective, yes — we'd probably agree as a team with known (ad hoc) conditions and goals.

Data on small businesses is hard indeed. I'm only speaking anecdotally from the MSP / software shops perspective, the "tech guys" of most businesses who don't in-house IT. Also from a European perspective, so that might make a big difference — we're, ahem, let's say not as involved, interested, or capable in all things "technology" as a general population (I didn't say luddites but that's how it feels sometimes, compared to the vibe I get in NYC or rich Asian cities).

That will make for some pretty salient readings, thanks for the links.

There are obviously cases of failure. I don't know the stats. I'm speaking mostly of small/medium businesses, where size and complexity are different.

On a personal level, I have the same problems with using Python.

I've become enamored with package management in Go — not perfect yet but efficient, simple, to the point. The backwards compatibility enforced at the version level is also great — you often find Go code years old that keeps running just fine. I like things that you set up once and may just forget, that's where real productivity is found imho — it doesn't matter that I can do X in 1h if I have to do it every other day, I'd rather spend a full week or even ten, and solve it forever.

I think Js is comparably simple but I've heard so many horror stories about dependency management that I just don't know — I've yet to use Js in prod myself at work and I don't look forward to this day.

Here's the thing: it does not matter how great a language may be while I'm writing it, because that's 10-25% of my time; what matters is that everything around, from setting up dev environments to shipping passing by devops, especially as a one-man/small team, can be done "simply enough". And that, IMHO, is where Go is miles ahead of most other languages from a philosophy standpoint.

I tend to feel very positively about Rust for it looks to be an extraordinary intelligently lead project, with comparably 'real' benefits that extend beyond the code page (but I've yet to use it myself to confirm first-hand).

We see the importance of these topics so clearly with Py2/3: none of the problems between these two have anything to do with what's in the code, with programming; all of it has to do with the ecosystem, with the real and much larger task of maintaining codebases, managing teams and deploying 'stuff' in ways that work with the environment (whether tech, people, knowledge, politics, what have you).

The move to 3 by Python has been a failure in that regard, and IMHO it rests on the shoulders of an entire community who chose to stick to 2 now regardless of what happened then. Well then is now and the result is chaotic.

I'm not worried about Python itself — the language is incredibly popular, especially in academia, and we need to double the programmers population earthly each year so that's a sustainable amount of new projects written in Python 3 every day. Old 2 projects will be but a drop 10 years from now simply because of this number effects of growing tech at such an insane rate (it's been about true since the late 1940's, uncle Bob has a great take on it in his latest appearance in The Changelog podcast).

Anyway. I can't wait for py2 to die and py3 to become the only Python.

The saying only applies when your product is software itself, not in most cases where software is just the means to deliver your product — here a website providing education in video form etc.

Besides, the reality is that most business software out there gets rewritten every 3-15 years (really depends on use-case and conditions, but on average 4-5-6 years is a good bet). After some time it's just not worth it to keep refactoring, you'd rather start anew with hopefully better tech and certainly with better knowledge of your problem — they say you should write everything 3 times to make sure you really nailed it.

In many businesses, these rewrites would constitute a new major version, more comparable to the feeling we always got in the waterfall era — new version = big changes, new UI, new stuff. That's when it's possibly lethal, if you really break the thing, and that thing is your product, not a means to it.

100% agreed, and you made me realize something.

As someone who writes — I mean prose, whether fiction or not (mostly not: essays, technical, etc) — I had to come to terms quite early with the dichotomy you explain here.

There is a place for the "beautiful language", the parts of it and the ways of using it that make it a pleasure, as a writer and as a reader. This, unsurprisingly, usually demands a whole lot of additional work on top of the 'direct meaning'.

Then there's a place, in casual communication, in business, in marketing, in essays as well, in technical docs, in speeches, in a lot of places, for the 'direct meaning', or close to that. The efficient use of language, when all form recedes in favor of meaning, of concepts, of getting that 'other' to get what you mean.

It's just that, in human language, you do it all with the same tools, we use formal or topical subsets of a vastly larger ensemble. In programming, we're more likely to use different languages [themselves subsets of human language if you think about it, but let's forget that for the sake of simplicity].

And there are programmers among us who love to dabble in the form, like some writers would spend 10%, twice, ten times the effort crafting just "better form" over an already well-defined idea/story. While other programmers, or at other times, just focus on getting things done. Cue the spectrum in-between.

So it all depends what we put in our code, as programmers, as human beings I guess. Is that thing a personal statement? Or is it just garbage code to temporarily expedite some roadblock? How do we approach complexity, bottom-up from the simplest elements/code, or top-down with the most expressive almost-meta entities? Maybe some side-line out-of-the-box angle? See how we'd word all of these, in human languages, as in code. We just wouldn't say the same, nor code (select languages) the same.

I don't know if I explained it well. But looking at it from a human language writer, it all seems clear now. The whole rat race of languages, the churches, the sheer effort put into form when meaning has already been solved 10 times by others, the strong NIH syndromes... it's all so common in traditional writers circles. We're all just writers, really!

As I read it:

> “Typescript is a hack on top of [a] [supposedly] server side language that is [awful]. ( Node doesn't even support int64 )”

"supposedly" in this context meaning Js is not worth being called a "server side language", in the commenter's opinion (citing lack of int64 support for example). This also implies in subtext that "server side languages" would be of a higher category/value than languages for whatever other use-cases.

I personally don't agree with any of that, just helping communication here.

You might just have named the concept upon which Monica bases.

- meta: it's interesting because having a word somehow 'creates' a concept in our minds, easier to think of and discuss I guess.

- topic: the concept is truly interesting, and you 'get it' when reading Monica's marketing pitch for sure. But the way you name it makes it a category, and when I add up that the one feature of Facebook that even non-users still come for is Groups... somehow this all hints at the aforementioned category.

Interesting. Food for thought.

Got it, thanks.

It's very true that common acronyms tend to get a life of their own, become words in and of themselves, even re-write their meaning — as poster below astutely suggested 'CRM' could mean "contacts" RM in this context.

As a non-native English speaker I'm quite surprised at the use of the word "CRM" for “children of all your friends // your brother // your grand mother”

Customers, seriously? Can someone educate me on this particular use of the terms? (to me it was only viable in business situations)

Regardless of the second, third meaning of "customer" in English, I'm afraid the word just won't fly in e.g. Western Europe where it only has 1 meaning (someone who pays you for a service), and people often deplore that business, money distort relationships... It's just a cultural mistake to call Monica a CRM over there. It would be like calling a software "union organizer" to manage your -personal- group of friends in the US... not exactly a "neutral" term, nor one remotely related to "friends". Lots of subtexts in some words, translations not 1:1.

PS to authors of Monica: I can help with a French translation ;-)

This needs to be said enough. On the other hand, remembering poems in school wasn't considered "easy" either, so I wonder why people think memory should easy for names, nor why it's a judgment on them that my memory isn't great — I'm agonizing ten times over not remembering, I should be the one hurting lol (definitely am).

It's like numbers. I remember IP addresses and breadcrumbs better/longer than I should, and why is obvious (sysops, web dev, nerd?)

Agreed, Rust's "popularity" in production projects is a topic to be revisited circa 2025-2030.

My personal intuition is that it will have become a strong alternative to C++ by then, and Go will probably eat the other side of that (at the 'upwards' frontier of C++, before/underneath e.g. Python), which given a decade could result in maybe 25-30% of major C++ projects moving or with plans to Rust/Go. That would be a healthy balance of alternatives, a true victory for these mid/low-level contenders.

It's not like the bottom of the stack can be won the likes of Python or Js at 80-90% within a decade. Structurally, it simply cannot.

I'm not sure what you're talking about. I suppose we have different backgrounds.

- I've never heard a single ranking officer in the army or intelligence circle or the judiciary branch ever claim that "it's not clear that secrets are necessary" — you'd be right many don't think it's an evil though. (I've personally interviewed such people among others for research, many times between 2006-2014, and this question was central to some discussions because we were indeed designing political regimes).

- You seem to confuse "secrets", the general idea of hidden information (e.g. a Christmas gift, the location of a weapons repository, the name of a lover) with secrets as a security device (PIN codes, passwords, the layout of a physical key). The former are content, the latter are means to restrict access (meaningless in and of themselves). You seem to argue that the latter can do better with less "remembering" (security practices, FIDO, etc), and sure go for it; but that has nothing to do with the former, actual secret information (content) which you seek to protect by way of such security devices.

- My point was about secrecy as a function of States, well before digital computers even existed, and well after. Modern computing compounds effects but doesn't change the nature of institutions. You'll always need to secure 'dangerous' stuff. I'm not sure how you envision a hostile invading army on your ground, but if you picture that suddenly many red lines appear clearly.

I'll tell you the dirty secret: the less they have an actual enemy to fight, the more they idle, the more "these people who desire secrets" become threats to the wider population — people report that it's such a parallel world view as an insider that focus can get fuzzy, undetermined, self-harming. This is why historically you see many governments pretty much making up enemies: a mundane observer would tell you it's to a classic to unite the population (or your base versus rival groups), but a historical perspective shows it's also to curb the 'natural deviance' of all the shadowy things in a State, to focus them for good when their idling becomes too evil.

None of this black and white. Nothing's fundamentally changed with computers or electronics — it's more game theory, math, and obviously philosophy, psychology, than whatever implementation of a system throughout history.

For another round at not-so-simple-secrecy-management, consider now corporations, first between them, then in interaction with States. You'd think it's all new, unseen before. Go read some account of the 16th century or even before. See how this is just part of human nature. As I tell myself, "deal with it".

I can't speak for America directly but I hear it's trending too: here in the old western world (EU), we gladly install cameras and microphones in our homes, down to the bedroom, all by ourselves.

To think that 50 years from now, people who grew with such a permanent record on them — an ever-lens to watch and re-watch their every move, to frame the world anew most likely — will not be willing to accept current levels of Chinese State surveillance, is either naively cute or idealistic delusion. IMHO.

Another way of saying this, looking backward: you gotta admit this crazy idea of lighting fires inside ships and inviting lightning itself in our homes were ridiculous ideas (before), dangerous behavior (during), totally obvious (retrospectively). It's called a paradigm change.

I feel the level of exposure we have to tracking/recording sensors (cams, mics, gps, etc) is bound to provoke such a shift. Probably in the name of efficiency (for the good part), in fear of some terror (for the bad), I just hope we'll be top-notch on security and privacy (lest it gets ugly before it gets better).

The limit is that you have actual secrets to protect, whether codes or names. You don't want these public because everyone could destroy you then. Secrets are a necessary evil. Managing secrecy as a function of some more or less independent entity — three-letter agency, direct governmental body, army... — is a balancing act, to put it mildly. Ever since the dawn of time, and periodically throughout history, you hear this tension between the visible power (gov) and the hidden figures ("deep state", when some independent agency grabs too much power, and they all do, that's how they 'die' and get reformed historically).

This is one of the oldest and hardest problem in managing a 'country', a vast group of people, in the face of potentially hostile foreign powers and nefarious actors in general (including, and sometimes especially, within).

I feel our epoch (with internet, mobile, 24/7 on, hyperbuzz, etc) is vastly increasing the complexity and difficulty of this topic. It's likely to make those in charge of secrets paranoid, with reason, even assuming the best of intents.

TL;DR: wish it were as simple as that.

I must not have made my idea clear.

The thought experiment is not about software, nor is it about programmers.

It's about writing e.g. "JohnSmith" on your freaking passport in the name field. It's about people being free to have it written "John Smith" or "Smith John" or "johnSMITH" or however they want. It's about your business card, your mailbox, the name on your bank account.

I was just phrasing one example implementation of that idea.

Also, I appreciate the downvotes due my failure to convey my idea clearly, but for a thought experiment it's pretty harsh — how is it not 100% on topic when the article specifically talks about writing "Ryo Saeba" as "SAEBA Ryo"? I'm just saying, 'fine', but make it unique and user-choice.

That said I'm resting this case, the best jokes are the shortest I suppose. I was merely inviting comments to tell their own preferences. For instance, I reduce my first name to a sound that matches a greek letter's name, so I like to spell it e.g. "χLee" — and I'd love for it to be official spelling, I hate with a passion that my country doesn't allow name changes unless major reason. It's my name, isn't it? (if I read your linked blob correctly)

Mmmh, OK, I see, thanks a lot for explaining.

The UX you describe seems to fall in the 'naughty websites' category in my book, indeed. I think there's a "uncanny valley" of atrocious UX where it's "almost like the real thing but not quite" and it feels very disorienting. I'm pretty sure that wouldn't fly with most projects.

This and what you mention about js components imply that, what, we should expect each and every useful project out there to increase manhours to make some interface for flutter? I mean, short of a fits-all transpiling-middleware that takes in Js to output whatever Flutter needs to work with it, it's just not happening.

I'm not sure Flutter is as general a framework as we make it out to be; that it targets many platforms doesn't mean it targets many use-cases, let alone all of them. Afaik, it's a heavily 2D-graphics oriented solution, great for design-rich projects, and I had failed to see the restrictions (apps being their own little worlds) until you outlined what it means when translated for the web.

For the web I'd bet on some combination of wasm over this any day, tbh, combined with progressive web apps it seems a stronger, more general/opened proposition.

Thanks again for the good food for thought.

Allow me to reply, I think you've misunderstood parent's point:

- there is a spectrum of "importance" to software: a shopping app crashing is generally less critical than medical software crashing during surgery.

- there is a spectrum of "importance" to the news: surely the benefit and damage of reporting on Netflix's latest show is lesser than reporting on an incoming tsunami.

If you are warned upon fast release of a piece of news of "lesser impact" that it's "unverified", "untrusted source", etc., then you get to choose the impact: you either wait for further confirmation or act now, that's on you.

Conversely, for the "important" part of the spectrum, then we all agree that like critical software, it must be vetted and validated before release. There's no question about that.

As for where to draw the line, it's anywhere each particular new outlet feels it should be; but the mention of where we are on that spectrum should be at least industry-wide ethics for the Press, and enforced by regulation if necessary (see other comments for great suggestions about how to indicate trustworthiness of information, extent of research, sources, etc).

> efficiency for the sake of efficiency

Oh dear rurp, you don't want to get me started on that! ;-)

Your hiking example is a textbook page of my life, I do things like that all the time. Partner openly jokes that I'm crazy / weird / funny — all in good spirits, I concur that it's not exactly statistically average (i.e. 'normal') behavior. — "but why do you do this like that?", eyes usually roll before I even finish my elevator pitch; but every once in a while I catch her imitating. Good times, haha. Small victories, you know.

That being said,

I have a gazillion justifications for this. From ancient Zen and Stoicism (you guessed it) to modern scientific organization of work / tasks / labor, passing by cognitive science and physics and what-have-you.

It's. Just. More. Efficient. To. Be. Efficient!..

¯\_(ツ)_/¯

But it's also a delusion, to some degree (when you mistake the means for the ends I suppose, when it becomes a zero-sum rat race from a 3rd person perspective). Hence a healthy distance with the concept, I treat it as one parameter/rule of our universe — nature favors the efficient ones — but I've learned to just shrug at the general inefficiency of my civilization. Sometimes, I admit I'll even take pleasure and find beauty in a wildly inefficient thing that nonetheless passes the threshold of "it works", however barely. Politics, states, institutions feel like that to me: it should all collapse under its own weight and complexity, and yet it goes on... fascinating feat. It's like e.g. Windows (the biggest codebase in existence, at least as reported a few years ago, 50 million lines iirc?), you have to revel at the wonder that it even works.

Sorry, I edited the post with more examples. Capitalized letters names in the middle, e.g. "JohnESmith" for "John E. Smith"?

Note that owners would choose their array, i.e. how they wish to normalize their own name(s). In most countries it would probably be issued by the State, though.

But hey that's a joke, a thought experiment at best; I think strings with spaces are perfectly fine. The concept of a defining single string for a name (implying order is fixed, forever) is however good. In practice it's already what most contacts apps let you do — input first, last, middle, handle, etc. and define order to display, but it's generally a global setting; it could be granular (per contact), with quick/helper rules per nationality for instance.

I'm not sure we'll ever solve this linguistic and cultural matter only using technology though. ;-)

Edit (final, promise): I simply move that:

- people choose what are "valid" representations of their name (owner decides, others conform)

- systems make it easy for others (people, systems) to pick one (by default you'd assume item 0 in the array).

As a programmer and nerd with an aesthetic sense for consistency, I move that we all adopt an array of PascalCase strings as value for the "name" key.

    {"name": ["JohnSmith", "JohnEdwardSmith", "JohnESmith"]}
    {"name": ["AnneGauthier"]}
    {"name": ["ZoolisCartom", "CartomZolis"]}

Owner decides the array's content; others (people and systems) may then just 'match' based on reqs/prefs.

____

More on-topic, from a linguistic standpoint I believe natives should always define their own namespace, others should merely conform (e.g. use as-literal-as-possible transliteration following accepted standards).

A foreign name is an invitation to meet another culture.

That was my thought as well. I went to Akihabara in 1997 and it was still glorious. Evidently that spirit has now moved to Shenzhen.

> We have begun reaching out to external auditors and, in tandem, are opening up our operations to review by our users. This allows you to verify with your own eyes, whenever you want. WYSIWYG.

Technical side: color me very curious about that "our users" part. I can't wait to see what it entails.

Business side: bold move, it may prove to be a blue-ocean-like strategy, if substantiated. Interesting.

____

Some rambling about access, transparency and "open"-things

Most people don't know that under the terms of most democracies, in principle, any citizen has the right to go to any public office and request basically anything non-classified: documents, accounts, etc. The idea being that the State is but the expression of the sovereignty of the People.

Obviously, no one believes for one minute that any 'normal' citizen will be granted access to most things. It's just an artefact of idealism you hear in law classes and political activism circles I suppose (and it's grey-ish-ly somewhat applicable at the lowest, local level).

It would be interesting to see a new breed of "open-sourced" businesses granting access to customers (like States would to citizens), businesses whose value resides not in secret sauce — things like accounting, plumbing or VPN are probably "solved" matters of public knowledge. Because they can afford almost total transparency, they may as well weaponize it against rivals who can't — or won't. In markets where trust is anywhere from high-value to mission critical, this might just open wide a whole new blue ocean.

Google sure is nowhere near as capable or even willing as Microsoft or Amazon; heck even IBM through Red Hat could prove a much better steward for its enterprise customers.

But I think the morality is to never put all your eggs in the same basket, because any of them can fail for external reasons — e.g. horror stories about people locked out of any service because payments failed due to some stupid action by their bank; months to fix issues... don't be that guy/business with a single point of failure.

So, contingency plans, and a healthy distribution of your flows.

Have several banks/cards, several clouds, front load balance with a cross-platform HA solution, then for everything behind peg providers against each other; optimize for cost or convenience or whatever.

This is the resilient way; and possibly even antifragile as you develop new synergies in this meta-space. It also sends a message that interop is value to you, to the market.

When you operate at that level, there may be room for GC in your system — typically where you can afford it to fail / disappear but it's better/cheaper as long as it lives. You're already ready for the day it dies, because you make that risk assessment a parameter in your arch.

You make great points and I agree with your take on agile — I actually mentioned "cost" to indicate that reality was deviating from the 'ideal' agile approach, when it stops being "the right thing to do" — buggy, etc. — because you're trying to meet some arbitrary deadline or favor marketing, please mgmt, etc.

Likewise, I think it's fair to assume the economic competition between news outlets may push some to be too aggressive in shipping fast, too fast.

And you know what, deep down I think it's OK, as long as you don't falsely advertise what you're doing. "We want this <content> (whether code, news) in the hands of our customers asap, so we're releasing it now; but be aware it's not 100% guaranteed until scrutinized by the crowd and corrected accordingly."

I'd love to have a choice between some "fast news shippers" and some "slow, vetted pieces". I think there's room for both and everything in between. Just don't be disingenuous about it, and if it takes regulation to enforce that, then so be it — every legitimately regulated activity pretty much brings it on themselves, give or take some political latency.

I think you need to become more independent from the 'system' you describe; i.e. go freelance / contractor / consultant / remote etc., some variation of these.

I think I really don't trust the author of Rich dad poor dad but the one thing he got right is the ESBI system ("cashflow quadrants"). — I'll let you google but the gist of it is simple: there are only two limited resources, money and time, and any work is a trade of one for the other. You want to be in a position wherein you generate 'enough' money to 'buy back time' essentially. That means being either a business owner (B quadrant) and/or an investor (I quadrant).

Freelancing is the "S" (specialist) quadrant, you don't want to be there forever — because revenue only comes from putting in hours, it's a neverending grinding wheel, however profitable it seems. What you want is to setup your 'freelancing' as a 'specialist' to grow into hiring people and thus become a business.

Never forget that more than 80% of GDP in rich countries is made by small businesses. Groups of 2, 5, 10, 20 people make up the effective wealth of our economies.

Deep down that's what The Millionaire Fastlane or The 4-Hour Week expose to the general public, this idea of relative independence combined with a business model that cumulatively earns you ever more time — and hiring is key to unlocking that, multiplying manhours around your activity, sharing the load, not being "required" yourself for the business to run. A group of well-organized devs could probably wrap 30-hours weeks and still make a ton of money.

> This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.

In fact, afaik, it's kinda 'proven' loosely in psychology studies that "laziness" isn't a bad trait per se. In fact, from our ancestral laziness comes our drive to build things (systems, organizations, machines, civilization!) to do our job for us, anywhere from 'streamlining' to 'automating'.

Many great developers are self-reportedly very ambivalent between laziness and the drive to make things — alchemy notably happens when what you make today will let you be lazier tomorrow (you probably need to be at least 25 to 'feel' it though).

Of course, being a nerdy creature, you'll rinse and repeat indefinitely — there probably never will be a shortage of things to automate in your lifetime — but that's the spirit. As you said, we gotta keep ourselves busy to balance the lazy. ;-)

First thing would be to de-correlate this 'news blockchain' entirely from any sort of 'coin', 'token', whatever 'currency' thing — a blockchain is a distributed database, period, 'crypto-coins' being just one application for this storage.

There are several ways to do it then but a standard would likely emerge, as in: "we <publisher> commit to mirror-publish our content to ThePressChain."

You'd likely store only text (say the raw html) on the blockchain though, so using links for pictures etc; which implies your CDN is archived publicly for later retrieval (I suppose a deal with archive.org or equivalent is in order to bolster such a paradigm).