In my previous post on this subject, we looked at tips for presenting the case for F# in your team. In this article, we'll discuss some practical tips for using F# with your team as you start getting to grips with the language and environment.
So, you've gotten approval to try out F# in your organisation - congratulations. Now, you need to actually deliver! This might be a small proof of concept (POC), preparing a demo to the team, a new module in an existing project or maybe a low-risk green field project. Regardless, there are some common steps that you should follow to help a successful delivery - or understand why things didn't work as well as you'd hoped for.
1. Record as you go
Before you start, set up a mechanism to record your experiences - both positive and negative. You can use this to reflect at the end of your first iteration into F# in practice as to what worked well and what could be improved upon.
This could include blockers that you encounter, comments for things that surprised you and also wins - things that you achieved that either pleasantly surprised you or were challenges that you overcame. Consider even recording the saving of the win e.g
"We used FSharp.Data to connect and consume a JSON dataset - this is typesafe and will save us around four hours every month when the provider changes their data schema and forgets to tell us, as we'll catch it in our nightly CI process or during development, instead of realising post-deployment. This will improve customer satisfaction as we won't get bug reports from them but will catch it much sooner."
2. Be resilient
If you're using F# for the first time in a production environment, you or your teammates will have some fears and doubts. This is totally natural. Just remind yourself the following mantra as you go through the first iteration or two: F# is a general purpose programming language that runs on .NET.
Unless you've used F# before, you'll come up against blockers, or unexpected twists, during day-to-day develoment. Don't give up.
Rememeber that all the things that you do today whether logging, SQL access, deployment to Azure, CI/CD processes etc. have a story in F#. Many of them will simply be to use the same tools you use today but in F#. Others may have F#-specific tools that provide an even smoother experience. F# teams today are writing end-to-end applications today that are virtually 100% F# codebases.
3. Believe in what you're doing
Have belief in what you're doing. If you get to the crunch and "fall back" to your safety net of whatever language / environment you're comfortable with today, you risk the whole project failing - people will see that it's ok to not leave their comfort zone (which is part of what you're trying to achieve).
At Compositional IT we have a simple mentality - F# on .NET Core is our default choice for software development. If someone wants to use a different language or runtime, that's fine - as long as they can justify the benefit. This flips things on its head compared to what you may be coming from, but try to adopt this approach for your project. The whole point is to truly benefit from F# - something which we see only really happening by using it as widely as possible in a codebase.
Don't be shy of using it outside of aspects of your codebase that you may not have considered, but instead have the mindset that you are now an F# developer - period.
4. Don't do it alone
Just like the planning and pitching phases, don't be the only developer on the project. Doing this phase alone will more-or-less guarantee two things:
- You'll end up as the only F# developer on the team. Be prepared to be known as "the F# guy", because no-one else will get involved.
- F# will not become an integral part of your team's development stack.
I've seen this happen in lots and lots of places. Get between one and three other developers involved and fully committed to the project on a regular basis.
5. Consider pairing
It sounds obvious, but consider regular pairing sessions or sync ups with other developers working with you. Don't just work on your own - you'll both spend time making the same mistakes. Instead, working together - even if it's 15-30 minutes a day - will rapidly transfer knowledge between each of you at this formative stage, whilst also naturally drawing out common coding practices and patterns.
6. Aim for rapid feedback
Consider regular sync up or demo sessions with the team in order to get them involved, or at least so that they have an awareness of what you're doing and what the costs and benefits are.
7. Use external resources
There are many excellent free and commercial learning resources on F#, from books and video series, to social media, forums and chat rooms. These are all excellent options for learning - don't make the mistake of thinking that these resources won't be able to teach you something new. All of them are cheap, relatively speaking to the cost of a software developer or two, and are well worth investigating.
8. Work with an experienced mentor
Work with someone - anyone - that has good practical F# experience. Even if you've done some F# before, I strongly recommend working with someone in your organisation if possible, or an external consultant to provide regular coaching during this phase. We see this regularly with many of our coaching customers, many of whom are adopting F# for the first time. Even one hour a week can have a massive impact on the productivity of your project - there's really no replacement for experience of having gone through the process of using F# in a production setting.
9. Demonstrate and report
Plan in a retrospective at the end of the entire engagement. Provide a practical demo, but also review how the project fared overall. Relate this session to the original goals that you set and agreed with both developers and non-development stakeholders e.g. project manageers, delivery leads, CTOs etc.
Tip: Don't pretend that everything went smooth sailing. There will nearly always be something that you missed from your previous language / toolchain - whether that's the tooling in comparison to C#, or the machine learning support in Python. Making it appear as though there were no costs involved at all might make some people doubtful or sceptical.
10. Make it last
If your project was successful, consider what needs doing to make F# a regular part of your team's stack: how can you spread knowledge and skill throughout the team e.g. rotating other members onto the project? Or perhaps mob programming sessions, hack days or lunch-and-learn sessions would fit better?
If it's not an ongoing project and there's a period of time before you can use F# on another project, make sure you you don't lose the "muscle memory" you gained: consider making a daily or weekly habit of just 10-30 minutes of regular programming in F#.
Summary
That's a wrap! I hope you found this series useful. F# isn't always easy to adopt - and there's no guarantee it'll be plain sailing or that it'll be successful. Nonetheless, I hope the tips in this series prove useful in adopting F# in your organisation. And if things don't work out, learn from them. See what you could have done differently - hopefully, you'll have the opportunity to try again in the future!
What should you consider success? Ultimately - assuming that you're passionate about F# and really want to use it in your day job - your aim should to flip the discussion around from "why should we use F#?" to "Why shouldn't we use F#?".
Have (fun _ -> ()) with F#!
Isaac
