Shameless plug - we're hiring!

As Don and Brian have mentioned, we are working towards an April Update to the F# research release as well CTP this summer and eventually integrating into the next release of Visual Studio. Things are going great on the polishing/finalizing F# front, but truth be told we would like to add more features than we have time - as always is the case - and could use some help. Specifically, in addition to our open developer postions the F# team is looking for a few good Software Design Engineers in Test (or in Microsoft-terms SDETs).

You can find the job description here:

https://members.microsoft.com/careers/search/details.aspx?JobID=1E69990F-1A90-4971-8BE3-2C16A1CAE4FE

But what does that really mean? When a lot of people think of software testing and they imagine sitting in a room and logging bugs until they go insane. Fortunately, that isn’t entirely true. If fact it’s hard to really pin down what software testing is all about at Microsoft, but I define the role as simply making sure we ship something I’m proud of.

Doing that requires the ability to wear many different hats. For example, over the past couple months the F# QA team has been:

· Using an Microsoft Research tool called PEX to generate a test suite for the F# libraries . They aren’t well know, but there are plenty of great tools from Microsoft research for automating test generation and validation. (FxCop is a good example.) And part of the SDET role is keeping up to speed on these technologies and applying them wherever it makes sense.

· Converting our build process from using ‘Make’ to MSBuild, which included writing MSBuild tasks for fslex and fsyacc. As we begin to convert F# from a research concet to a first-class .Net citizen we need to play well with our existing tools. In order to MSBuild our compiler we needed to run fslex and fsyacc through MSBuild, so I read up on MSBuild tool tasks and wrote some code which we will ship in the top-secret-and-yet-to-be-announced F# PowerPack.

· Contributing to the design of the F# language and libraries. At Microsoft testers play a very active role in product design both in contributing to the team effort and in logging (or not logging) bugs.

· Developing code transform tools. The idea is to take existing F# code and turn it into semantically equivalent code but more complex code in order to get depth of testing. Such as:

let f x = x * x => let f (x : int list) = (List.hd x) * (List.hd x)

x <- x + 1 => (fun _ -> x <- x + 1) ()

You wouldn’t believe how many bugs this technique finds…

· Rewriting the F# parser to measure language usage. By tweaking the F# codebase to log which grammar productions we parsed, we could gauge how much of the language our testbed actually covered. Then, we saw how we could refine the language – either by deprecating unused language constructs and identifying common idioms.

· Developing code conversion tools. Hooking up a parser for C#/VB.Net code and running the AST through the F# CodeDom to use existing compiler testcases.

· Etc.

Whereas the role of a developer at Microsoft is pretty well defined, there is a lot room for SDETs to provide value beyond just logging bugs and writing tests. The thing I love the most about my job is the ability to do something different each day.

So if working with new technology sounds like fun and you won’t mind the rainy temperate weather of Seattle, I’d encourage you to submit your resume online or you can send it to me directly via the contact link on the blog. As always, if you have any questions please feel free to ask.