Check out my recent writing on Medium

My recent writing can be found on Medium. I have been writing about running a strong software development team and being an effective manager. Here are some of my articles:

Have you written down your team values?

The importance of having an explicit set of shared team values.

Regularly Scheduled Hackathons

Building a stronger and better product through recurring hackathons.

Quarterly Questions

Taking the pulse of your engineering team.

Creating a successful software internship

Ensuring interns get the most out of a summer with the team.

Delegating Decisions

How a simple phrase “What do you think?” can help build a stronger and more independent team.

Feature Flags: A cure for production-phobia

Feature flags are an extremely important technique for deploying high quality changes quickly to production.



Chutzpah 4.3.0 – Web Server Mode

Chutzpah 4.3.0 is now available and its largest new feature is Web Server mode.

Web Server Mode

Chutzpah historically built your test harness using local file paths (e.g. file:///some/path.js).  This has worked well for the most part but has problems like causing cross-origin errors when opening the generated harness in the browser and complicating testing applications built with SystemJS. To resolve these issues and overall make Chutzpah more modern I have added a Web Server mode. This is an opt-in feature but after getting feedback and vetting I plan to make this the default in a future release. When this mode is enabled a local server (using Kestrel) will be hosted to serve your files.

To configure web server mode add a Server section to the chutzpah.json file:

This enables the server mode and uses default values for the default port (9876) and root path of the server (drive root). If the default port is not available it will increment the port number until it finds an open one.

You can configure the default port and root path:


Jacoco.xml coverage format

You can now export the results of code coverage in the jacoco.xml format.

chutzpah.console.exe myFile.js /coverage /jacoco cov.xml

This makes integrating Chutzpah code coverage results into a Visual Studio Team Services build simple by publishing the generated XML file:




Code Coverage Timeout

You can now configure how long to wait to instrument each file before timing out. By default this is 5000 ms but using the CodeCoverageTimeout setting you can make this larger.


Code Coverage and Angular2 / SystemJS

If you are using Angular2 or SystemJS code coverage will not work. Chutzpah uses the Blanket.js library to handle code coverage and it does not (and probably never will) support SystemJS. I plan to update Chutzpah in the future to move away from Blanket.js and use the Istanbul coverage library instead. I do no have a time frame yet for this change and PR’s are welcome Smile.


Pin a work item query in VS Code

A couple weeks ago the VSTS Extension for VS Code was released. This extension adds command and status bar integration for Visual Studio Team Services. When using this extension I loved seeing the number of pull requests and the build state in the status bar but I wished I could see the count of bugs assigned to me. About a week ago I forked the project to see how hard it would be to add this feature. To my surprise it was very simple. Jeff Young did a great job with the extension, it is well structured and easy to jump into. After a few hours I built the Pinned Query feature.

A pinned query is a work item query that runs in the status bar and shows you a count of how many items it returns (see the cute little bug icon). When you click on the icon it will run the query and give you the results.


By default it is set to a built in query showing all the work items assigned to you but you can easily customize the pinned query in your user settings file. You can configure using a path to an existing query or by providing WIQL:

Using Query Text

 "team.pinnedQueries": [
            "account": "your-account-name",
            "queryText": "SELECT * FROM WorkItems WHERE [System.AssignedTo] = @me AND [System.ChangedDate] > @Today - 14"

Using Query Path

    "team.pinnedQueries": [
            "account": "your-account-name",
            "queryPath": "Shared Queries/My Folder/My Query"

You can also create a global pinned query which will be the default if you have not configured one for your account by replacing your-account-name with global in the previous examples.


Automate Visual Studio Team Services with PowerShell

One of the main skills programmers have is the ability to automate the mundane. In my day to day job of both working on and with Visual Studio Team Services (VSTS) I find myself performing many of the same tasks over and over. And whenever these tasks require me to leave the comfort of my PowerShell prompt I get grumpy. Since I rather not be grump I created a project called PsVsts to help me automate those tasks.

PsVsts is a PowerShell module which provides several handy commandlets for working with VSTS. The point of this project is not to simply create a wrapper around the public REST apis but to lift those apis up a level to make them more convinient to use. Because of that many of commandlets consume multiple APIs.

The project currently contains the following commandlets:

  • Get-MyWorkItems Gets the work items that are assigned to or created by you. Provides easy way to filter by open vs finished items.
  • Get-WorkItems Gets the work items given a query.
  • Open-WorkItems Opens work items in your web browser.
  • Push-ToVsts
    Takes a local git repo, creates a corresponding repo in your VSTS project, adds that repo as a remote origin and pushes your local repo to it.
  • Submit-PullRequest Submits a pull request
  • Get-Builds Gets a list of builds
  • Set-VstsConfig Sets a config value for use in other PsVsts functions
  • Get-VstsConfig Gets the config values


The commands I use most often are the Get-MyWorkItems and Submit-PullRequest. The Submit-PullRequest commandlet wraps both the pull request and identity apis to allow me to easily create a PR and add reviewers using their name or email. I use this commandlet as part of function in my PowerShell profile to automate my common worflow to make changes and submit them for review:

function fastFix($branchName, $title) {
  if((-not $branchName) -or (-not $title)) {
    throw "You must specify branchName and title"
  Write-Host "Checking out $branchName"
  git checkout -b $branchName
  Write-Host "Adding all files and committing"
  git commit -am $title
  Write-Host "Pushing to server"
  git push -u origin $branchName
  Write-Host "Submit Pull Request"
  Submit-PullRequest -Title $title -Description $title -SourceBranch $branchName -TargetBranch master -Project MyProject -Account MyAccount -Repository MyRepo

I use the Get-MyWorkItems commandlet to quickly see what is assigned to me and then I can pipe that to Open-WorkItems to view them in the browser. By default this commandlet will try to show only open items.

Get-MyWorkitems -AssignedToMe | Open-WorkItems.


You can easily install these commandlets on your machine using the PsVsts Chocolatey package.

choco install psvsts

I hope these may be of help to any other PowerShell users who also loathe being grumpy :)


Chutzpah 4.1 – Visual Studio Debugger Support

A week ago Chutzpah 4.1 which finally adds the ability to debug your unit tests directly from Visual Studio.




Debugging from Visual Studio

Thanks to the awesome PR of Martin Connell you can now debug your JS tests from inside of the IDE. You can set breakpoints in your JS files and launch using the Visual Studio Debugger by clicking:

Debug Tests when using the Chutzpah Test Adapter Plugin


Run Chutzpah With -> Debugger when using the Chutzpah Context Menu Extension

Chutzpah will then launch Internet Explorer and attach the Visual Studio Debugger to it.


NOTE: Before this will work you must ensure script debugging is enabled in IE by going Tools->Internet Options->Advanced and unchecking both Disable script debugging settings.