All the "engineer"-ry things like constructing testing oracles or understanding code complexity this can all be found in Programming and Programming Languages https://papl.cs.brown.edu/2020/ that uses Pyret which has similar enough syntax to Python none of your bad engineers will be lost. There are lectures for it too: https://learnaifromscratch.github.io/software.html#org4eef4d... you could teach this class to them the lectures really teach you concepts like trees and graphs and how to reason about them.

Thanks for linking it!

Practical Object Oriented Design (Metz)

Refactoring (Feathers)

Test driven development with Python (Percival)

Missing Semester: https://missing.csail.mit.edu/

The drive behind this project is to demonstrate non-beginner issues facing professional developers. Instead of ephemeral syntax tricks or "how to use library x v5.3", the focus is on skills affecting codebases over decade-long timelines, such as:

- gaining confidence in code with (non-brittle) integration tests

- deep understanding of what the OS offers (and fluency in the command line)

- building excellent monitoring and instrumentation for rapidly diagnosing production issues

- vetting dependencies so they don't bite you in the ass

- architecting code for re-use and intuitive navigation for freshly onboarded team members

- the paramount importance of data integrity (and how to enforce it at the DB level)

etc.

https://www.semicolonandsons.com/

When you see an interesting block of code that you see could be refracted, hold a session showing your refactoring of that code. You'll have to do it twice, once to figure it out, second to present. It's very time-consuming but it's the best way for people to learn

1. Commit hooks that lint code (pylint3, flake8, ...). Code must be clean before it is merged.

2. Introduce testing: code must be covered by tests.

3. Require documentation: there must exist an independent specification of what the code does, at least from an external point of view: what are the interface contracts.

Once you have code that is specified and covered by tests, only then do you have a proper environment for transforming badly structured code that works into better structured code that still works.

Other than that, organization of programs is a big topic that requires study of theory. For instance, you could probably rediscover the idea that code should be organized into modules such that the content in a module belongs together, and isn't tightly bound to content in another module. You might not have a name for this but an intuitive feeling for it, which is very good. But if you study software engineering, you will learn about cohesion and coupling directly, so you don't have to reinvent or rediscover the wheel. The cumulative effects of learning material directly add up; you can shave years and years from the time it takes to become competent.

I think that the decline in the "Wirthian" languages like Modula 2 has been detrimental. The biggest initial boost that I got in the understanding of structured, modular programming was from programming in Turbo Pascal and Modula 2 in the late 1980's.

In Modula 2, you structure the program in modules which have a clear interface and implementation, declared in separate files. Modules declare their dependencies on other modules. From this, the compiler knows all the dependencies. There is no need for any Makefile or dependency generation; you tell the compiler to build the program, pointing it at the main module and that's it.

Each module has a block of global initialization statements. The compiler/linker, knowing the dependency among the modules, ensure that these statements are executed in module dependency order: if A depends on B, B's global initialization runs first, then A.

When I started coding in C, I realized immediately that this is missing: there is just a main function and after that you're on your own. Moreover, unless you declare your dependencies to the Makefile or IDE system or whatever you're using, or get it to figure them out externally, you will not get correct incremental builds.

So I simulated modules by carefully structuring header files, and giving each module a global initialization function, and then call these in some disciplined way, like from one big init function.

I later saw (thanks in a large part to open source) that other people's big C programs did things like this. I felt that programmers who had exposure to a language supporting modularity had an edge in understanding the issues and motivation for good organization patterns in C programs compared to those who were just getting randomly burned and improving their approach by trial and error.