Developer, Architect, Trainer, Consultant; Michael has worked with and trained people in a wide variety of technologies, as well as having just written a lot of code.
His career has ranged from data analysis in Python, to enterprise OO code in C#, to extremely functional (in both senses) code in Elm and Haskell, with a sprinkling of F# and TypeScript inbetween.
To help move our discussions of software development in general and functional programming in particular beyond opinions and arguments with (generally) very shaky scientific support to actually thinking about the humans we work with and build tools for.
Hopefully the audience will come away from the talk with the clarity of mind to know that there isn't one objectively best solution to each problem - and that's okay! But there might be solutions that work better or worse for them and their teams, and some examples of what those could be.
Anyone interested in the process of creating software, and the humans who do it.
More than 10 years into his programming career, being diagnosed with ADHD brought a change to how Michael viewed many of the common arguments in modern software (types or tests? functional or OO?). It became apparent pretty quickly that many of the programming paradigms and tools he'd grown to view as "best" over the years lined up suspiciously closely as excellent compensations for the areas that are often weakest for those with ADHD.
Maybe, rather than trying to find papers proving the advantages of type systems, it would be more productive to explain how they help compensate for easy distractability. Is the completeness checking of discriminated unions a straight jacket on flexibility, or a valuable tool to help against a limited working memory?
Come on a personal tour of one programmer's experience with an atypical mind, and let it impact how you choose and create technologies for humans rather than for best practices.