At RodeoFX my friend Renaud and I informally discussed our findings, tips, tricks and sometimes frustration. As we are currently no longer working together, this series of articles aims to keep sharing what I recently learned, with no specific order or priorities.

• GitHub and GitLab both support a CODEOWNERS file that indicates who in repos is responsible for maintaining some code. This is useful for automation, for example to add reviewers to a pull request: less platform configuration, more in-repo semantics.
• Everything is a really fast search tool for Windows with valuable features: speed indeed, but also a handy CLI and HTTP API and comprehensive configuration options.
• Catch2 is a single header C++ test framework, making it really fast to setup. I'm just starting to discover it and already like its simplicity very much.
• I forgot about this one, but USD has a nifty API for debugging logs: TF_DEBUG=PLUG_* can be set in the environment variables to output logs specific for plugins.
• The Windows SDK defines min and max as macros, clashing with the ones in the C++ STL. However if NOMINMAX is defined before including Window.h those macros won't be present, fixing the collision.
• Visual Studio needs to be told what kind of library needs to be linked at runtime. Coding for USD, for example, requires linking with the Multi-Threaded Debug DLL or the app will crash at startup.
• Windows has many different rules to find runtime libraries that would be expected on Unices. Practically, the equivalent of LD_LIBRARY_PATH is PATH, which also holds the executables search paths list.
• In Windows (or for what I understand, for code compiled with Visual Studio), a binary can link against static .LIB or shared .DLL. However, applications need to explicitly open the .dll. To ease the process a bit a .lib can only contain what is needed to find and link a .dll at runtime. Practically that means that when linking against a .lib it is not immediately obvious whether it contains static code or points to a .dll, in which case it is called an import library. This can however be found by querying the linker.
• bqt allows running Qt code in Blender. The project is still in early stages and there seem to be some issues (two UI libraries competing for the same events: expect clashes), but still, it's a start: I've been able to open a Qt dialog then run some blender code.