In the latter, my biggest use was to prototype how I’d solve a problem for my sister in her job (scheduling facilities maintenance in a way that didn’t interfere with planned experiments and tests, what maintenance work could be done and when to minimize conflicts with customer schedules). It worked as an example but couldn’t handle the full factors (well, my laptop and lack of experience optimizing models) and they continued relying on (mostly) human judgement (worked out well enough).

I also used it to make a soccer schedule. It worked better than my teammates attempt at making a scheduler from scratch (building both the solver and model). There are already systems for this that the league had available, it was more a “can I do this” challenge.

More important, to me, was learning about a class of solvers and what problems they were effective at solving. Even though I have no immediate need it expanded my knowledge so I know where to start in the future rather than (foolishly) starting from scratch. Or I can point others to it. I’ve seen many devs (myself at times too) reinvent the wheel because we don’t know what options are out there. I took the course to combat that behavior in myself and to better guide colleagues, plus it was fun.

(Apologies, on mobile. I have a few more paragraphs I could write but this is not the easiest entry mechanism for that.)