chairleader

That's an interesting observation. I can see both sides of that coin.

I think this notion of friction vs frictionless is one of the key features of this time in history.

To my eye, the whole line from personal technology in the 80s -> through UX on the internet -> through app platform lock-in -> through subscription-centric "ownership" have been providing us all with the promise that we can buy our way into less friction. The next device or subscription solves problems or enables us one way or another. We see this line of history, draw it into the future and see a utopian future with zero friction.

Zero friction meaning zero difference between how you want to feel about the world and what you get out of it. More feeling empowered or satisfied or comfortable or right.

The parts of our culture that embrace friction are the slow parts - grousing with neighbors, weeding a garden, letting the other car go first. These are the parts where we meet with the reality of other people or nature. Maybe there's a tool or framework or gadget that could help, but we know and accept that there is something immutable outside of ourselves and we have to find a way to flow with it.

I'm getting older, I'm finally starting to see the limits of pursuing a frictionless life.

fantastic, thanks!

Out of curiosity, are there Linux tools to go from binary files to audio and back again? i.e `cat archive.zip | faxify -wav > archive.zip.wav`

Thanks for the reply, I'm also a big fan of documentation living inside the repo. I appreciate the framework you describe for the readme as well. Similar to _kb's sibling comment, that sounds like a sane approach to meeting the needs of contributors to and supporters of the codebase.

FWIW, I'm struggling with documentation that support the mix of roles on the team in addition to coders/contributors - QA engineers, product owners, project managers, support teams, etc. A big part is the capture of requirements flowing into proposed solutions and out into support documentation.

In reply to _kb, it did occur to me that there are many job descriptions at play here, and that change is inevitable. Perhaps the answer is simply that it takes many people and several genres of software to keep things from falling through the cracks.

Thanks for this link, I agree, that is a fantastic framework for documenting software.

The idea that a reader of a piece of documentation is approaching it with a particular goal is spot on. I suppose I envision either more or perhaps another layer of goals/contexts in addition to what this is outlined here.

A set of use cases I'm thinking of involve the process of changing what a piece of software does. As design documents arise that may or may not apply to a future version of the software, where should that live? Perhaps during the design phase of that release it belongs in one place while designers are iterating on its contents, and later it moves to another place when it is considered a stable reference document?

Plenty of capital P Process behind this question, I suppose. And perhaps there's no getting around some amount of the "librarian" work moving content around to reflect its use.

The symptoms we experience are: - not capturing key information, often because the challenge of finding a place makes a project out of a task which then gets dropped, - capturing the information in an island somewhere making it unfindable later on, e.g. a loose document in a user's Confluence space.

With a team of folks with different skill levels, when there's information to capture, I'd like there to be a clear single place for it to live so that it's easy to place there and easy to find again.

Interesting. I would say that John didn't build a solution that met all of the use cases that the business needed.

* To ensure accuracy of transactions, he should have built reporting to meet the needs of accountants.

* To support change, he should have kept his components separate and provided modest testing examples.

* To support developers and operations, he should have found and documented the external dependencies along with steps to verify that they are in place.

Whether product managers didn't uncover these requirements or the business didn't prioritize them, these aspects of the definition of "done" have more to do with thee environment the engineer is working in and less to do with his or her work.

Thank you for the tips!

I appreciate this:

> In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.

Reviewers are human too, and can occasionally get lost in the weeds nitpicking a PR/CL.

What tends to be the first indication of breaches? It's one thing to do a forensic analysis after learning of a breach, and it's another to detect it in the first place.