The biggest challenge is to prove that it works. The space software community historically is very conservative and risk-averse, and mostly for good reason. As Kubos (and hopefully others) get more flight heritage with Rust on the flight segment, it'll be a much easier sell.

That's the biggest obstacle I think. Someone will have to break the seal and establish that "Rust in Space" actually succeeds consistently, then larger "trad space" organizations will follow.

https://www.kubos.com/

Nope. Fortunately for me, while I was in a position to make those decisions about Bryana (I've since changed gigs), her own excellent performance was the only thing I had to think about.

Look, I'll let Bryana's own career speak for itself, which I have no doubt it will, but for myself I'd have confidence putting her in front of any audience on any topic she feels comfortable talking about.

One other thing, if you know anything about how conferences work, CFPs/speaking roles are something managed by the conferences, not companies. Questions of 'token' or otherwise are best posed to the individual organizers of the conference in question.

Her post only implied her own personal, subjective and utterly understandable anxieties on that point. My response was at pains to put both her questions and anyone else's to rest. She earned everything she got, and the comprehensive respect she received from her peers was without qualification. Never mind gender, she coded way beyond her years of experience. The main thing with managing Bryana was to get out of her way and let her do outstanding work, which she did.

> If you want to put the conversation to rest, simply clarify that point.

Was there something ambiguous to you in my statements here?

* Bryana's performance _across the board_ was top-notch, _without qualification_.

* ...she..._earned_ every single bit of responsibility she ever got.

* We just evaluated the [interview] performance and hired the best dev for the position, _end of conversation_.

She commanded, and continues to command, respect from her peers for both her technical contributions on a very challenging tech stack, and product savvy in an extremely complex business domain. I was on her interview and there was no question of moving bars. It didn't even come up, because she was so very well-prepared. We just evaluated the performance and hired the best dev for the position, end of conversation.

On the job she spoke with authority and confidence in standups and earned every single bit of responsibility she ever got. Mention her to anyone who's worked with Bryana and you'll get the "eye roll of respect." She's so talented there was a minor running joke with a couple of us that we should keep a countdown clock of "minutes till I work for Bryana."

I only wish that early in my career I could have been half as well-rounded and with a fraction of the aptitude, product savvy and technical depth Bryana has.

That word actually shows up exactly once in each episode.

>> In the first episode, they insinuate that IV doesn't pay inventors like they claim. In the second episode, turns out that they do pay quite well, but oh look! that inventor is totally a schmuck for ripping off his coinventors! (Is he really the kind of inventor that IV is paying?!)

Yes, IV paid Chris Crawford -- the one example given by IV of an "inventor" who made money -- for a stake in a patent. That's what IV does. They buy patents or percentages of patents. TAL never claimed otherwise. Crawford retained a percentage of interest in ongoing revenue obtained in court, which was distributed accordingly.

As to whether Chris Crawford is a schmuck and ripped off others, or whether the invention in question was even his to sell or was his idea to begin with, I think this court transcript from a case that he lost, speaks for itself:

---

Attorney: So the first paragraph of this document reads, quote, "This proposal, it is in response to Jack Byrd's idea to provide automated offsite backup services for PC users." And aren't you in the second sentence saying that Jack Byrd had an idea to provide automated offsite backup services for PC users?

Chris Crawford: No. What I'm saying is that Jack Byrd had an idea of me pursuing the automated offsite backup services that I had--

Alex Blumberg: Chris Crawford then launches into a rather surprising explanation for how the sentencing that this business was, quote, "Jack Byrd's idea," doesn't actually mean that the business was Jack Byrd's idea. His explanation? He was using the apostrophe S incorrectly.

Chris Crawford: As far as the apostrophe S-- and I'm still not clear if you're trying to derive a specific meaning with respect to the apostrophe S--

Alex Blumberg: Of course, what would a sentence reading, "in response to Jack Byrds idea" even mean if the S was plural?

Attorney: I'm asking you, though-- you certainly know what the use of an apostrophe S means, do you not?

Chris Crawford: [SNIFFING] As I've written documents over the years, there are times when I use an apostrophe S, and it seems like I'm supposed to use an apostrophe S. But I have to say that my grammar is not strong enough to tell you right now with clarity when an apostrophe S is used.

http://c2.com/cgi/wiki?GlobalVariablesAreBad

State, in general, at any scope, can make things difficult no doubt. But global state is classically bad because it's hard to reason about across large chunks of distributed code, pollutes namespaces, creates concurrency nightmares, etc. Reducing the scope of state to a manageable range of, say, less than a dozen lines of code, into short-lived references, is clearly far better than the alternative and a reasonable approach in the vast majority of cases. Calling it 'poison' ratchets the rhetoric way beyond the gravity of the problem. No, local state is not considered harmful.

What it seems OP is really talking about in practical terms is pure stateless programming, where the application has no implicit or explicit references to a value whose authoritative data resolves in main memory. If you were to tell me the only state you have in your application is Filesystem or database data, "just beyond the edges of our program logic," I'd say you'd basically achieved the fabled 'stateless' programming ideal, long held as a kind of Holy Grail of functional application development, and as OP points out, that's not often achieved even in the strictest functional environments.

I don't want to diminish the points made, the article was instructive to me as yet another anecdote about the perils of shared mutable state at any scope. But the fundamental principle, that one should avoid shared mutable state as much as possible -- which is the upshot of the essay -- has been axiomatic for quite some time.

But there would have to be some cultural and language support for an entire idea around what a codebase is. The idea that it is an object that can possess the property of velocity will take a bit of enculturation. But the software/agile community has done it before, so...

And for me, 'a long period' is anything longer than a month, or more specifically, the time period it takes for me to have to change any code I've already written in order to deliver new business value to a customer.

...and just noticed your 'six weeks' estimate. We're on the same page here it seems. :)

Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death.

Here's an example from this essay:

"There is a reason good code is considered to be a form of poetry. It's elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day."

Try telling a product manager or CEO or other stakeholder how 'clean', 'easy to read', or -- God forbid -- "fun!" your code is, and watch their eyes roll back in their head. (I exaggerate for effect.)

These ideas make sense to us as developers because that's what we spend our entire day doing: considering, reflecting and thinking about code. But I think what we should be talking about is the inherent speed of the codebase. I'm not talking about my velocity as a developer, or the velocity of the team and how many story points they deliver per sprint, but the inherent velocity of the codebase as a function of its technical debt. Codebases, from a business standpoint, should not be "clean" or "dirty", but rather "fast" or "slow".

Technical debt should be surfaced to the stakeholders using language that conveys the dollar value, the fiscal liability, of technical debt. The most accurate way to describe that and show how debt is slowing your team down, is to talk about its inherent speed.

"Our codebase is getting slower" makes business sense to a Product Manager. "Refactoring this will make our codebase faster" is a phrase that conveys the worth of initiatives that otherwise seem to have no immediate effect on the bottom line.

All of the tools and agile methods we have talk about velocity in terms of what a team is delivering, and can parse that down to the sprint and developer level. But in my experience, the most significant contributor to a team's relative speed is the (intertia|speed|velocity|momentum) of the codebase itself, as a function of its technical debt. I think we need to start using language that intuitively and constantly surfaces the dollar value of technical debt to the stakeholders, so that "just ship it!" no longer sounds like a sound business strategy.

Sorry, I should have qualified that, because I wasn't endorsing Machiavelli, only acknowledging his influence on our current context.

You're right about the violent times of The Prince. You're wrong about two things: the notion that it is removed at all from our contemporary environment (such brutality has not been surpassed in extremis in the last century alone? Please...), and the idea that the fundamental turn from the idealism of Plato and the ancients to the pragmatism of the moderns was not prefigured and in fact architected by Machiavelli. The philosophies of Real Politic and Neo-Conservatism (at least) are fundamentally Straussian/Machiavellian in origin.

All I can say about the rest of your points regarding the mentally ill is, I wish mental health was the world's biggest problem as you seem to think it is. But in this discussion it's a complete non sequitur.

"falsifiable observationally verifiable prediction..."

Go back and read The Open Society and Its Enemies or Objective Knowledge. and you'll find this statement constitutes a fundamental misreading of Popper.

Never mind the fact that Popper was basically wrong and the notion of 'falsifiability' is a non-starter when it comes to practical application of political theory, Soros notwithstanding.

"its already just a piece of paper..."

"You won't be permitted to change anything..."

"if voting could change anything it would be outlawed..."

"You'll be given..."

"This is the stage..."

"The purpose of a democracy is..."

"its a blueprint..."

A litany of declarative bromides, delivered with pseudo-authority and strung together without forming a coherent thought, call to action or proscription for remedy. Such could only ever be pointless, nihilistic, and and anarchic.

Demagoguery in the making.

The US would need statesmanship beyond that of Churchill to galvanize and harden society against those eventualities.

Moreover, in an era of dirty bombs, chemical weapons and even full nuclear devices, the consequences might not always be merely a "handful of casualties," and the grotesque effects of certain weapons, particularly on children, would be images that would be highly likely to incite increasingly aggressive responses.

The US historically is not a society that is accustomed to the idea of being under any kind of siege, nor of allowing its families to remain under threat of any kind. That's not the underlying narrative, and it's just not in its DNA.

EDIT: BTW, I've no idea why your comment is not higher. Anyone downvoting it is not paying attention imo.

Sure -- democracy is no guarantee. Referendums go wrong. Aaaand we're back to the Enlightenment political question of how best to balance the will of the masses (which can become a mob in the right circumstances, or an instrument of oppression to the minority) against the wisdom of representative government -- a republic. A sticky wicket indeed. The idealism here -- and I freely admit that it is based on a naive Modern optimism -- is that a transparent, representative democracy, rather than a direct democracy, corrupts more slowly over time and retains the highest possibility of self-reform of all types of governments.

Unfortunately for both of us, the truths of Machiavelli are not easily defeated, least of all by something as saccharine as "make love not war." The most tyrannical and imperialistic societies in history, from Rome to Stalin, often began with variations on such noble sentiments.

"Care better for the crazy." In other words, anyone who means to do harm to the republic should be institutionalized? How? By force I assume. Who defines "crazy"? The history of international conflict unfortunately is not a story of the rational and benevolent vs. the "crazy and murderous", but of competing ideologies, scarce resources, and plain corruption.

The problem with such naivete is that it assumes the problem is theoretical, and merely needs the correct sociological constructions and psychological theory implemented by benevolent institutions.

But how do those institutions grow over time? Who governs them, and which of the many competing and contradictory sociological and psychological models do we apply, first of all to define and identify "crazy," and then to apply the appropriate remedy? Further, what concrete example of such an application can you offer as proof that such a program works consistently on the local individual level, much less the international level?

Further, can you show through examples how such an institution sustains and protects itself through means other than power and violence?