So you're all excited about functional programming, and you've been learning F# in your spare time, and you're annoying your co-workers by ranting about how great it is, and you're itching to use it for serious stuff at work...

But then you hit a brick wall.

Your workplace has a "C# only" policy and won't let you use F#.

If you work in a typical enterprise environment, getting a new language approved will be a long drawn out process, involving persuading your teammates, the QA guys, the ops guys, your boss, your boss's boss, and the mysterious bloke down the hall who you've never talked to. I would encourage you to start that process (a helpful link for your manager), but still, you're impatient and thinking "what can I do now?"

On the other hand, perhaps you work in a flexible, easy going place, where you can do what you like.

But you're conscientious, and don't want to be one of those people who re-write some mission critical system in APL, and then vanish without trace, leaving your replacement some mind-bendingly cryptic code to maintain. No, you want to make sure that you are not doing anything that will affect your team's bus factor.

So in both these scenarios, you want to use F# at work, but you can't (or don't want to) use it for core application code.

What can you do?

Well, don't worry! This series will suggest a number of ways you can get your hands dirty with F# in a low-risk, incremental way, without affecting any mission critical code.

• Twenty six low-risk ways to use F# at work. You can start right now -- no permission needed.
• Using F# for development and devops scripts. Twenty six low-risk ways to use F# at work (part 2).
• Using F# for testing. Twenty six low-risk ways to use F# at work (part 3).
• Using F# for database related tasks. Twenty six low-risk ways to use F# at work (part 4).
• Other interesting ways of using F# at work. Twenty six low-risk ways to use F# at work (part 5).