aard's comments

I've been working on my own version of a literate programming system (https://github.com/adam-ard/organic-markdown). It's kind of a mix of emacs org-mode, jupyter, and Zettelkasten. But, because it's based on standard pandoc-style markdown, you can use it with a much wider range of tools. Any markdown editor will do.

Even though I made it as a toy/proof of concept, it's turned out to be pretty useful for small to medium size projects. As I've used it, I've found all kinds of interesting benefits and helpful usage patterns. I've tried to document some; I hope to do more soon.

--https://rethinkingsoftware.substack.com/p/the-joy-of-literat...

--https://rethinkingsoftware.substack.com/p/organic-markdown-i...

--https://rethinkingsoftware.substack.com/p/dry-on-steroids-wi...

--https://rethinkingsoftware.substack.com/p/literate-testing

--https://www.youtube.com/@adam-ard/videos

The project is at a very early stage, but is finally stable enough that I thought it'd be fun to throw out here and see what people think. It's definitely my own unique spin on literate programming and it's been a lot of fun. See what you think!

Location: Salt Lake City, UT

Remote: Yes, hybrid or onsite also OK

Willing to relocate: Yes

Technologies: C/C++, Python, Embedded Linux, IoT, Docker, Bash, Golang, OpenGL, Qt, CMake, IaC, CI/CD, 3D Graphics/Math, Real-time Systems

Résumé/CV: https://www.linkedin.com/in/adam-ard-03245215/

Email: [email protected]

Senior system engineer with 25+ years of experience in robotics, embedded devices, and 3D applications. I've worked on everything from humanoid robots and smart energy systems to AAA console games and graphical simulation tools. I’m passionate about developer experience and recently created Organic Markdown (https://github.com/adam-ard/organic-markdown), a literate programming framework. I write about software design and developer culture at https://rethinkingsoftware.substack.com. Looking for deeply technical roles where software meets hardware and math meets the real world.

I very much support this sentiment! If we want a decentralized internet, we need to stop relying on large companies to manage everything for us. Git was designed to be a p2p system, but we very quickly centralized it with forges like Github. It is very discouraging. Most of the internet is like this now--managed by a handful of very powerful organizations. There is no end to the problems this will cause.

> Sometimes the exciting things are exciting for very valid reasons

Very true! I would also add: Sometimes boring things are boring for reasons that actually make them poor solutions.

For example, some systems require tedious, mind-numbing configuration. This is boring, but also a good reason to NOT use something. If it takes hours and hours of manual tuning, by someone with special training, then the solution is incomplete and at least needs some better defaults and/or documentation. It might be a poor option.

Another example is a system that does not lend itself to automation. Requiring manual interaction is certainly boring, but also does not scale well. It is a valid reason to disqualify a solution.

Boring can often be a smell--an intuition that a solution is not fully solving the problem.

I see your point here, but I want represent a counterpoint to this line of reasoning, from my personal experience. I've been in a lot of situations where someone simply wants their way--in this case they want the organization to choose their personal software preference--and so they call it the "boring" choice.

By calling it boring, they characterize their _preference_ as the majority accepted, mature, obvious decision and anything else is merely software engineers chasing shiny objects. The truth is almost always more nuanced. Both solutions have pros and cons. They trade-off different values that resonate more or less with different people.

So, please be careful with the "it's boring and therefore obviously better" argument. Don't let it be a way to summarily dismiss someone else's preferences in favor of your own--without a deeper discussion of trade-offs. Otherwise it's no better than any other condescending attempt (ex. I'm in charge, so we are doing it this way. No one ever got fired choosing IBM/Microsoft/..) to win an argument without having to present real arguments.

Tim Bryce’s work, such as his “Is PRIDE too rigid?” article, uses analogies with traditional engineering (like jet engine design) to argue that skipping critical design steps can lead to costly rework later, but it stops short of offering rigorous empirical proof or extending the idea to the realm of software.

"Big Design Up Front" in software is the whole reason the Agile movement came about. To put BDUF into Agile is to miss the point completely--they are fundamentally incompatible. Any company that insists on "lots of analysis and design cycles before a single line of code is written" will be left in dust by competitors if all their programmers don't quit first.

There is a lot of confirmation bias in the industry around estimates. If an estimate is ever wrong, it's never taken as evidence that estimation in general is a flawed practice. The failure is always attributed elsewhere, usually to a lack of effort or focus. But if an estimate happens to prove true (even broken clocks are correct twice a day), everyone pats themselves on the back and says, "look how predictable we are. We are so good at estimation."

The autonomy you gain from starting a business is also a big deal. You can work long and hard with low stress when you are the one making decisions. Burnout comes from being powerless and at the mercy of someone else.

Isn't that pretty much textbook Scrum? The language in the Scrum Guide couldn't be much clearer...

"The Product Owner is also accountable for effective Product Backlog management, which includes:

- Developing and explicitly communicating the Product Goal;

- Creating and clearly communicating Product Backlog items;

- Ordering Product Backlog items; and,

- Ensuring that the Product Backlog is transparent, visible and understood. "

And if that wasn't enough...

“…the entire organization must respect their decisions.”

“The Product Owner is one person, not a committee.”

“Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”

Sounds like "sole authority" to me.

I think we have been stuck with this for so long we have forgotten that any other way is possible. Scrum is just a complicated way to divide labor. No one else at a software company needs a formal process to partition their work. They just sit down, talk and then go do the work. They come up with a light weight way -- a informal process -- to get stuff down. They would never even think to ask themselves, "I wonder what formal process we can follow to assign work?" They just do it.

How about letting engineers do what everyone else at the company does? Get together in teams, divide up the work, and check back later. You are asking for an alternative thing to mandate upon engineers from above -- something formal. I say, just let engineers manage themselves. No mandated process.