25.0304 (v1 25.0304) Doc URLs Stack URLs Lab notes (Gdrive), Git

I added this page 25.0304 to explain how I would use this sandbox to teach

• stacks (#2),
• APIs/API-docs (#1),
• stack deployment (#3), and
• non-stack components (docs, sites, customer AI assist) (#4).

The gist of this approach

• You learn by doing. THE HARD PART IS KNOWING FIRST-HAND THE WORKFLOWS AND WHAT BUTTONS TO PRESS.
• The most important thing is to not get bogged down with errors. Focus on progress, not perfection (Dave Gray's motto).
• Start from the top and work your way down.
  • Focus on simple demos for a complete dev chain.
  • Avoid (low level) coding whenever possible.
  • Use AI wherever possible. Its NOT a matter of not letting AI become a crutch (that makes as much sense as saying dont use IDE's because they become a crutch). Any crutches you will yourself throw away as you learn to walk (and you might find out that AI is not a crutch, but a future standard tool, as are IDEs). AND YOU CANT DEPEND ON AI (at least for the foreseeable future), BECAUSE AI IS A DUMB TOOL WITH NO INTELLIGENCE.

This general approach is often (always?) the best way for potential customers to understand first-hand how a SW tool could be an indispensible part of their strategic toolset (ASAP).

Example of using this approach

Note: My focus is on API-docs and docs in general. And currently the sandbox contains my lab notes (not end-user docs). What I am suggesting is in the future creating a tutorial series (or college courses) based on the org of the sandbox with some of my lab notes converted into minimalist step-by-step specific demos.

PART 1: Replicate simple minimalist specific demo (stack, API, API-docs, deploy, docs sites)

While constantly verifying that the entire chain still works after making changes. Learning GIT and other tools along the way.

#2 Stacks

Start to finish create a stack and run locally.

#1 APIs/API-docs

Add a few REST API endpoints and simple swagger. Still running locally.

#3 Stack deploy

Deploy using Render. DNS setup with Squarespace.

#4 Non-stack SITES / DOCS / AI

• Create (product).com site.
• Create docs.(product).com site.
• Create step-by-step downloadable docs.

PART 2: DRILL DOWN

After having done the above for a specific example, you drill down WITHIN THAT EXAMPLE by doing enhancements/mods. You learn coding piecemeal AS YOU NEED IT.

PART 3: BRANCH OUT

Then you branch out to variations of the above (different stacks, etc.)

• #2 Add auth/sec, try other frameworks for FE, BE.
• #1 More REST endpoints, GraphQL, more API doc types.
• #3 GIT actions, AWS and others, Terraform, etc.
• #4 Add some end user AI assistance and generated docs.

Summary

I started out writing assembly language code for embedded 8086 systems with ICE (in-ciruit emulation). No operating system. I knew exactly what the code was doing. I loved that job... I spent my day implementing algorithms, not struggling to understand someone else's high level abstractions. Nowadays its all abstractions. High level code, APIs, dev tools, cloud app platforms, etc. You dont really know what going on under the hood.

So dont over-analyze, over-complicate things with endless verbiage. Just give me a working demo so that I understand the idiosyncracies of your high-level tool. I find such an approach usually only on Youtube (and thus thats my learning focus; I wish could find this more often in print).

I thought about creating a video tutorial series after taking a college course in SW dev last fall (first college course in more than a decade!) that was a disappointment. The typical "lets start out learning what tuples are", then jump around, jump around, concepts, concepts, resources, resources, NO AI ALLOWED!, building a huge Django project start-to-finish for weeks and only trying to deploy after the project is "complete" (the deployment failed). I spent most of my time confused. I paid $600 for the pleasure of it all.

Never again. Treat YOUR prospective customers better than that.