[ChrisMarshallNY]

Military leadership has a great deal to recommend it.

For one thing, their principal mission is to deal with the unexpected, and come out on top.

That's nothing to sneeze at.

In the civilian world, first responders and mobsters are probably analogous, as most corporate leadership is about consistency and predictability.

First responders, however, only have goals to stop the unexpected, or repair damage. Mobsters figure out how to take advantage of the unexpected, and maybe make some hay from it.

I suspect you could relate.

[austin-cheney]

As both an army officer (reserves) and a former corporate software developer the problems are different because the expectations are different. One might assume expectations would follow the problem state(s), the reality, but I promise this isn't the case.

When I say that expectations are different our culture prepares us to start with a foundation of assumptions and our expectations grow and blossom from these assumptions. We assume things like the power grid is reliable, that we will have internet, and the only malicious people are common thieves attempting to rob unwitting grandmothers of their personal piggy banks. We then expect certain conventions to be automatically in place when writing software for our employers, things like: CI/CD, frameworks, code editors, and so forth. When an employer fails to meet these assumed expectations, typically limited to tools and infrastructure, we as developers consider the employer a failure. Strangely, things like policies and the human element rarely (close to never) enter these preliminary expectations for most developers which frequently results in dire second and third order consequences.

On the military side we do not have the luxury of these expectations either because we may enter an austere environment lacking the conveniences of modern life or because the military culture is socially backwards with regards to modern software.

Seeing these differences in expectations and appropriately self-reflecting becomes a necessary factor in durability. In my 15 years of writing software as a corporate developer this, more than all other factors combined, accounts for why some organizations can build durable software products and others cannot. It always boils down to two things: 1) setting appropriate expectations for people (soft-skills and inclusion) and 2) setting appropriate expectations for building quality products. Rarely, as in almost never, have I seen an organization really master both of those but I have seen organizations try at one and fail at both. In order to achieve success on one or both items there must be something to measure against and a willingness to impose hard limits.

[ChrisMarshallNY]

Thanks for the detailed reply. I appreciate the insight.

I write fairly robust software. Not milspec, but a bit tougher than your average app.

I'm interested in mesh systems, but have found Meshtastic a bit too "raw" for my tastes (but maybe later, when I'm done with this project I'm working on), and the proprietary ones won't share their API.

The reason is that I'm interested in writing software that helps people help people. For free.

It's kind of shocking how hard that is to do. No one wants to support or encourage that kind of thing, so I generally have to go it fairly alone.

[austin-cheney]

Completely unrelated to the subject of this thread, but I too have similar interests that I have been working on for the past 4 years. I recently wrote a paper about the concept I am exploring: https://github.com/prettydiff/share-file-systems/blob/master...