My experience with the F# Mentorship program

What is it

The Winter 2020 round of the F# mentorship program is now over. I participated as a mentor, and wanted to share my experience. The mentorship program is organized by the F# Software Foundation, and runs twice a year for 6 weeks at a time. All participants are volunteers of the community, and are asked to join the F# slack channel to communicate.

How I got involved

I first heard about the mentorship program program last year, but was too shy to sign up as either a mentor or mentee. I've since grown as a person, and have become more outspoken. I believe my job helped me in this regard as I became known as the "ReactJS guy". This gave me a lot of exposure to playing the mentor/coach in a given technology. I also presented at Meetups that my company sponsored, once on the subject of Introduction to F#, and once on Introduction to Node.js.

Imposter Syndrome

So clearly, I now had experience with introductory courses, but I still felt (and still do feel), something that I'm sure a lot of you are familiar with. Imposter Syndrome. Or the idea that I'm not actually as good as people say I am. When I came upon the announcement of the Winter 2020 mentorship program, I thought of joining as mentee, with the hopes of learning about a more detailed subject as someone already experienced in F#. At this point, however, I already felt my first mental block, as I thought I'm not good enough to be able to participate for a more advanced subject. At the same time, I felt that I didn't want to take a slot of another mentee that might be better suited for the role.

I then thought about signing up as a mentor, and hoping to get matched with someone wanting to get into F# for the first time. (Notice a pattern?). But even here, I felt that all too familiar feeling of not being good enough :(. That is, until I came upon this section on the website:

It's almost as if the fine folks of the F# foundation were also all too familiar with a certain syndrome. However, after reading through the site, and especially that section, I was convinced that I could do it. So I signed up. At this point I just want to say a big thank you to whoever had the idea of including this section. It was a big help.

Becoming a mentor

At this point, actually singing up for the program was rather straightforward. You select on which days at which times you would be available, and at which skill level you would feel most comfortable mentoring. As a side note, a requirement to signing up was also having to join the F# slack channel. This was the first time I went into the F# slack, but I can say that I've enjoyed the community there, and will continue to participate in the various channels there, as all the people there are very nice and interesting folk.

The actual mentoring

A few weeks after I signed up, I finally got an email confirming that I was chosen as a mentor. I was then paired up with someone looking to learn more about F# by contributing to open source projects. At this point I already knew that there would be some initial difficulties, as contributing to open source projects is always difficult. Not in the sense that the people involved might be difficult to work with, but in the sense of even just finding a project to contribute to.

The difficulty lies in the fact of coming from the outside of a project, and wanting to contribute a feature or bugfix. There exists a distinct lack of domain knowledge, and on top of that, you're usually not familiar with the direction that the project wants to move into. The second point is generally easier to learn, especially with large well known projects. However, with larger projects, small features and bugfixes either simply don't exist because there's already a dedicated team for them, and large features take a significant investment of time and collaboration with the various members of the existing development team.

That being that, this is where I felt that the relative size of the F# community might be beneficial, as it's not as large as C# or JavaScript. Meaning that the better known projects don't have professional teams working on them, and there's a higher likelihood of finding an issue to work on.

My mentee (lets call this person John Doe) turned out to be someone with extensive C# knowledge that already had some F# experience, in that he knew the syntax and how it tries to accomplish things with immutability first, and the focus on data flow. After discussing what we wanted to accomplish throughout this program, we decided that we would try and learn more about the F# ecosystem, and which tools and libraries are commonly used instead of their C# counterparts. As we were looking at different projects on GitHub, we encountered the aforementioned problem numerous times.

The first hurdle

Eventually, we settled on learning to use CanopyUI to scrape data from a Hangfire dashboard. The first thing that John learned was .Net Core. Interestingly, he had not been exposed much to .Net Core, primarily using regular .NET Framework for most of his career. At the same time, there was a lot of confusion regarding how Paket and FAKE played into the ecosystem, as well as the F# language itself and its build tools. This is understandable confusion, as the majority of F# open source projects use those two tools, instead of simply relying on the NuGet directly and the dotnet cli or MSBuild for build automation. What made it more confusing was that (IMO) paket and FAKE were more useful in .NET, but less useful in .Net Core as the standard tooling had improved so much.

This isn't to say that paket and FAKE no longer serve a purpose, however for small projects that simply depend or one of two NuGet packages, and only need to have tests run against them before building a release package probably is fine without those tools.

Continuing to learn

As the Hangfire dashboard that John wanted to scrape data from was from his place of employment, we couldn't justify actually using it during our calls on slack where we screen shared. So something else we did was set up a basic ASP.net Core site that included Hangfire to show a dashboard. This is where we spent most of our time. Turns out that Hangfire on .NET Core removed some features from the .NET version, namely basic authentication, which made it difficult for us to write UI Tests against in such a way to mimic his workplace's dashboard one-to-one. But this is a Hangfire specifc problem and had nothing to do with F# or its tooling.

A nice part of setting up an ASP.net Core site was that the APIs used often times required C# Action and Func objects, but F# functions when compiled are FSharpFunc objects. This was an interesting obstacle, but quickly overcome as the F# compiler is smart enough to automatically cast the one to the other in certain situations. But nonetheless a good situation explaining the differences between how F# views its functions and how C# wants to use lambdas.

Coming to the end

Although we didn't manage to accomplish any large features or projects during the mentorship program, John was still satisfied with what we did accomplish, especially with learning how .Net Core differs to .NET Framework. He even told me about an incident he has at work where he was able to much more quickly diagnose the issues because he recognized that there was a .Net Core project involved, and most people on his team were assuming .NET. So I was glad to hear that there was a direct positive outcome of the mentorship program :)

In Closing

Unfortunately, as we came to the end of our scheduled 6 weeks, there were certain life changing events happening in the world, namely a very serious virus (you better be keeping your distance), and it became a bit difficult to concentrate on our mentorship, so we decided to cut it short by a week. But as previously mentioned, I'm still happy that I was able to help John learn more about the F# ecosystem, and .Net Core in general with some direct outcomes.

As a fun aside, when I was showing him how awesome Type Providers are while using Visual Studio Live Share (which is amazing) I discovered that IntelliSense doesn't kick in for the remote partner in the Live Share session, without being granted Build rights. Thinking about how type providers work, this makes sense, but was still interesting to come across.

In the future, I would probably sign up again for the mentorship program, although I'm undecided on wanting to be a mentor again, or trying to get into a deep dive topic as a mentee.

And lastly, another big thank you to the F# Software Foundation for organizing this program.