Hello, everyone. My name is Houston Haynes. While I’m fairly new to the F# community I’ve been involved in industrial grade hardware and software production for 30 years. Some of you may have read “What the F(#) is Next?” so I’ll spare the repeat of that or my detailed history, which you can find on my blog. More recently I had the pleasure to present at the “Focus on F#” .NET Conference, and I really enjoyed demonstrating how F# can run on a microcontroller “at the edge”. While IoT represents only one subject of interest, that on-going project is emblematic of my enthusiasm for expanding F#'s technical footprint and engineering mindshare.
Like most of you here I have also lived with the reality of “my ‘chosen’ language is the one I’m payed to use for work”. Fortunately I’m in a situation now where I get to write both C# and F# for a living and continue learning from talented coworkers, some of whom frequent these forums. While I continue to learn about F# at deeper levels I can take some early credit for successful advocacy. I’ve spent some time with Akka NET and nudged its founder, Aaron Stannard about the advantages of an updated F# implementation. The result of that can be seen here and here. And while I hope to contribute to that work later this year, there are other projects and broader topics that also have my attention. That, in essence, is why I am asking for your vote.
I’m the beneficiary of the time and patience offered by many in the F# Slack. And for that effort I feel like I owe something back to the community, if that is seen to be of value. And beyond that I also believe that .NET and F# are at their own points of inflection, and both would benefit from a fresh perspective. As many have discussed in this forum and others, education and training is a major challenge. That’s because everyone approaches F# from a different background, and often with different goals.
Along those lines I believe the “story” of F# as an analytic platform language is grossly undersold. I also understand that there has to be enough “critical mass” in that domain for a new concept to gain a foothold. However, with some experienced voices these issues can be addressed. One example: Scala operators. Anyone who has had to deal with the “slings and arrows” of that language would be glad to take on the cognitive load of learning a new language in exchange for a simpler, safer syntax. But if that story isn’t clearly detailed in outreach messaging, it’ll never make it past the mountain of work that engineers in that world have to endure day-over-day - the same issues F# would otherwise alleviate.
There’s also a level of cognitive burden in code management and “the inside loop” of working with a mature environment that may put off folks from other “stacks”. This happened to me quite a bit with academics who were very comfortable with base R and tidyverse conventions, but git terrified them. It may seem like a really odd blind spot to most folks here, but that’s the point of having a fresh perspective. You’re never going to get someone to wade into a GitHub repo to write tests or contribute to documentation if they’re put off by the idea of that environment. Stepping out of the “everyone’s a hard boiled programmer” is actually the way you reach new constituencies - and recognizing/addressing their actual points of friction would go a long way toward welcoming more to the community. This goes especially for marginalized communities who may not have a support network to inculcate them with the practices that might otherwise we assumed of them. I want to be sure that those considerations are carefully thought through to ensure that the foundation is sensitive to inclusion and equal outreach to underserved communities.
Equally important is the unsexy idea of business messaging. Of course some of this should be in equipping engineers with proper messaging (and of course resources and portfolio fodder). But I firmly believe that there should be direct-to-business messaging, even if it’s just astro-turfing social amplification of biz-friendly demos on LinkedIn. Of course I think the “Focus on F#” event was a good show of coordinated effort (confirmation/survivor bias notwithstanding) but I think even that was still too technical for the audience “reach” I’m talking about. I believe it’s not only important to do the work - but to also be seen doing the work, both by Microsoft and the broader business community. It may read like some form of “halo effect” of empty social proof, but this is the kind of thing that’s as unsavory to engineers as performance optimization is to project managers. Both are necessary, and I think the Foundation would benefit from investing more thought and effort in this area. So, I’m bringing this up here as something I would bring to the table as the Foundation finds a path forward.
The “fishbowl” metaphor is something I use when referring to perspective around a language or tech stack. Most people have an intuitive understanding mental image - inside the fishbowl one cannot see the outside world clearly, if at all. And if you’re outside the fishbowl you may think your sight is clear, but often the image is distorted in ways you cannot appreciate from a distance.
My perspective - both inside and outside of the “F# fishbowl” is one of the main reasons I believe I would offer something unique and useful on the Board of Trustees. I have experience with moving business leaders and senior engineers to “yes” on large projects. And I understand how to reach (and speak to alleviating) the pain points in a way that they’ll entertain the idea of taking a new path. And that - from my perspective - is what the foundation needs now more than ever.
We all have a vested interest in seeing F# flourish, and I will do everything I can to help that effort. Thank you for your time and consideration!