To me, software development is many things, but the inner loop is mainly characterized by two alternating modes: Trying things and Learning things.

The biggest hidden assumption I see is that we expect other people to be trying and learning things in the same way we do.

Experienced devs will write code to improve their own understanding, they will create tests to improve their own understanding, they will do research, they will do a lot of learning and all of that rarely gets talked about at standup or in a pull request. This work never shows up in a planning or budget meeting.

I see junior devs getting stuck hard on delivering production ready code - which is the WORK PRODUCT that we want; but that is not what the actual work of software development looks like. A lot of junior devs are hesitant to do throw-away work that does not get committed to source control - they feel like someone out there knows the answer and they just have to find them. And for a long time, that works - they can find someone to provide the answer they need, they can find a senior dev who glances at the code and fixes it effortlessly.

This whole thing is exacerbated by managers with no or minimal dev experience, who also confuse work product and tracked work items with the actual work of producing software.

(And if you're wondering who 'junior devs' is, it's me. I'm junior devs.)

Mixing code, markdown and execution results in one output file gives Jupyter notebooks superpower. You can really have anything in the ipynb file, stored in JSON. I wish there was two types of ipynb files, one for file with just code and markdown (for example ipynbc), and one for keeping code+markdown+results.

BTW, sometime ago I wrote an article about surprising things that you can build with Jupyter notebook https://mljar.com/blog/how-to-use-jupyter-notebook/ You will find in the list: blog, book, website, web app, dashboards, REST API, even full packages :)

Mine is also in LaTeX. Every 3-5 years I get a nice reminder of the nightmare that is cobbling together a fully functional LaTeX dev environment to work on it again.

Slightly off topic but does anybody have any resources for learning linear programming for business applications?

Unless I'm missing something (which is entirely possible, I have a cold and might not be thinking straight) ...

Max-Flow runs on directed graphs. These are undirected graphs.

What is RAG in this context? I only know it as red, amber, green...

"Simple" is an interesting term. I've always found it to be very relative to what someone's actual experiences and knowledge bases are.

For example, virtual machines are something I and probably most other people consider "simple". They're pretty much just little computers. For the most part, I can just work with VMs the same way I would work with computers. No sweat.

My DevOps pedigree, however, also means I consider Docker containers and even some light k8s stuff as pretty "simple" - when these two things feel to other people like massive overcomplications.

On the other hand, I'm pretty new to GraphQL, and it feels to me vastly more confusing than good old fashioned REST API endpoints, where I can crack open the code and actually see exactly how that particular endpoint works. I am mostly alone in my org when it comes to this feeling, because I haven't digested the abstractions that make GraphQL work as well.

I don't really have a good answer then for what simple is beyond "I know it (kinda) when I see it".