Softwire Blog

Coaching open source contributions with Codebar

20 June 2017, by

Codebar are an organisation that run weekly events to help get people from groups who are underrepresented in tech into coding. And for the past two years they and Ladies of Code have jointly run a day-long workshop in December as part of 24 Pull Requests, where more experienced devs volunteer to help people to make their first open source contribution.

Lightning talks at the Codebar 24PR event

Photo by @codebar

I coached at the 2015 event, which was a lot of fun. For 2016, Softwire also sponsored the event as part of our drive to support diversity in tech, so as well as coaching, I got to tell a diverse audience of people about why they should apply to Softwire!

There were several lightning talks about open source during the day, including ones from Andrew Nesbitt (who started 24 PR) and Charlotte Spencer (who runs @yourfirstpr).

But most of the day was spent coding. In the morning, the coaches were paired up with students according to what languages we knew or wanted to work with. JavaScript was by far the most popular, with a few people using Ruby or Python, and one person who wanted to write some Java.

I paired with Anna and Bybreen, who were just starting out with learning HTML and CSS. Git was the steepest learning curve, because neither of them had used it before, so we started out using the GitHub desktop client to make things a bit less intimidating.

Writing open source code at the Codebar 24PR event

Photo by @binusida

It was quite tricky to find issues to work on (which is one of the hardest things about 24 Pull Requests in general), but someone suggested taking a few open issues on Prepare to Code, a website which provides beginners’ guides for setting up different kinds of dev environments. The issues were just typos and broken links, but it was perfect for us because there was no dev environment to set up. Once they’d got into the swing of things, I hunted around for more things that they could fix on the same site. Hooray for buggy code!Between them, they made six pull requests, which is pretty impressive for people who were completely new to git. And we hit the 24 pull requests goal as a group.The day wound down with some drinks and a group chat about the things we’d been working on and what we’d learned.It was a really good day. Everyone there was so enthusiastic about learning or teaching (or both), and it was great to be able to help people see open source (and coding in general) as more approachable.


Payroll giving

3 April 2017, by

Payroll_Giving_2016_GOLD (004)One of the many perks we get at Softwire is access to a Payroll Giving scheme, which makes it easier than ever to support your favourite charities. Signing up to a payroll giving scheme has the following benefits:

  • The money comes out of your pay before you see it, which makes it tax-efficient and also psychologically easier to donate more and continue to donate for many years.
  • It’s charities’ preferred method of receiving donations, as it reduces the admin overhead of e.g. reclaiming Gift Aid.
  • It’s really easy to set up.

Last year, we took the time to publicise our payroll giving scheme more internally, and found a simple but effective way to reduce the barriers to entry still further: a number of my colleagues volunteered to go round to the desks of people interested in the scheme and take them through the sign-up process. And if it was after working hours, they would even bring a couple of beers along. This led to a doubling in uptake of the scheme, and we got 20% of our employees signed up in time for the Payroll Giving Awards 2016, which we think is fantastic! We are therefore proud to display our “PGA Gold Award”.

12 months on, we now still have over 20% of employees signed up to payroll giving, and we’re gunning for the Platinum Award this year.

If you were thinking of setting up payroll giving at your workplace, or joining your existing scheme, please do read the testimonials below for more inspiration, or feel free to contact us for practical help.

Rich C:

Payroll Giving CertificateI signed up with Tom after the company meeting. It was really simple to do, I think it took less than 10 minutes. I had some direct debits set up to some charities anyway and so I have simply transferred these into Payroll Giving so that the Gift Aid is taken care of and I can easily manage them online. The main problem I had was finally getting round to doing it – scheduling a time with Tom to sit down get it done really helped me, maybe I just need a lot of nagging to get stuff done though!

Tom E:

I started payroll giving fairly soon after joining Softwire, at the same time as I signed up for the Giving What We Can pledge. I find payroll giving a very easy way to give money both practically and psychologically – there’s no need to think about Gift Aid, and because the money never arrives in my account it doesn’t feel like I’m losing it. Sign-up is simple, and there’s no ongoing admin.


I’ve been doing payroll giving for quite a while now. I started when I realised that we were collecting large capital sums to support a village in Ashanti, and then incurring ongoing costs – for example the hardship fund. I liked the idea that if enough of us put in £10/month we could have an ongoing fund that would work a bit like taxes and provide ongoing support to the village. It was much easier to set up than I thought – I just filled in a form and now it goes out every month without my thinking about it.

What I did on my volunteering day – Jenny

20 March 2017, by

I had the privilege of being part of the Inspire! iDiscover week at Carlton Primary School in Gospel Oak.

Volunteering at a primary school with Inspire

Inspire! are an Education Business Partnership working in Hackney, Camden and Islington. They enable young people to learn about work and gain practical experience of the skills and attributes they need for employment, in particular working with young people from less advantaged backgrounds or who are at risk of being excluded from mainstream education or who are not in education, employment or training (NEET).

iDiscover is an initiative which introduces Science, Technology, Engineering and Mathematics (STEM) careers to local primary school children. The week-long programme provides schools with work-related STEM activities with the aim of encouraging more girls and non-white students to consider a career in these industries.

I was part of an afternoon session with two Year 1 classes where they get to meet real-life people working in engineering careers. Aside from me, there were people from the Institute of Engineering and Technology, an energy engineering and consultancy firm, and an architect.

Volunteering at a primary school with InspireEach of the engineers ran short sessions with the children in small groups – things like building a torch or a Lego tower. I wanted to explain to the kids what a software engineer does in really simple terms (we give instructions to computers to make them do things) so I set up a very simple Scratch project. When the children pressed specific buttons on the keyboard they could make a cat sprite move around the screen, change colour or say hello to them, and I tried to get across the message that these were all instructions I had given to the computer to make it do these things.

Although some of them had never used a computer before they all got the hang of it pretty quickly and came up with ideas for other things we could make the cat do. They’ll learn more about Scratch in the later years of primary school but for now, I was just keen for them to learn that software engineering is another type of engineering, and understand that it has something to do with playing with computers!

In summary, I would like to think that I spent my volunteering day helping some kids take a small early step towards a STEM career.

Photos by Inspire! EBP

Softwire West CSR Report

29 December 2016, by

After another year of great work and fantastic contributions to our Corporate Social Responsibilities, the CSR Committee at Softwire West wanted to make a report that not only detailed our achievements for the year and highlighted the headline figures (such as raising a total of £2858.80 for various charities!), but also demonstrated all the great events and causes people had committed to, organised, prepared for and attended. Something that showed the hard work our staff had put in to help others whilst having lots of fun! Therefore, we created this video (with music!) to thank everyone and give them something to smile about as we approach the end of the year…

Employee Volunteering

1 August 2016, by

This summer Softwire launched an exciting new Employee Volunteering programme with the help of a great social enterprise called Benefacto.

At the heart of the programme is our offer to every employee of two free days this year that they can spend volunteering instead of working. I’m pleased to say that within the first two months of this scheme, 19 people (around 10% of the company) have taken us up on this offer, and have done some amazing things!


Encouraging women in(to) technology

16 February 2016, by

IMG_7268Following on from our managing director Zoe Cunningham’s blog post on getting more women into technology, I thought I’d share some of my own recent experiences around encouraging women in, and into, technology.


CSR at Softwire in 2015

11 February 2016, by

Last year, we wrote a blog post listing our CSR goals for 2015. Here’s how we did against them:

Educational outreach

  • We worked with lots of young people last year through events that we’ve already blogged about, such as Code Club, Code Club Pro, Young Rewired State and Tech City Stars.
  • In the summer we also hosted 5 work experience students from the Social Mobility Foundation. This is the second time we’ve done this, and we hope to continue with it!
  • Through Stemettes, a group of 20 schoolgirls enjoyed a day trip to our offices where they learned to make a simple app. We introduced them specially to some of our female developers and project managers, and of course our MD Zoe. We hope some of them will be inspired to go into STEM careers!

Raising money

  • Our sponsorship of the village of Bonkron, through Ashanti Development, has been a great success. They’re now relatively well off and can continue to develop on their own, so we plan to find another village in the same region to support.
  • We raised £24,500 through Charity Saturday, just short of our goal of £25,000 but still a figure we are very proud of.
  • Over 10% of our employees have signed up to payroll giving and we’re on track for the Payroll Giving Gold award.
  • In total, we raised £30,800 for charity in 2015, and Softwire donated a further £4,000 through our matching scheme. The money went to charities including Ashanti Development, MIND, Broken Rainbow, Giving What We Can, Home-Start, Shelter and Schistosomiasis Control Initiative.

Using our skills

  • Zoe became a trustee of Ashanti Development this year. She’s helping to ensure the charity is fulfilling its objectives and making the best decisions, using skills she’s developed in her role leading Softwire as Managing Director.
  • Our contribution to 24 Pull Requests was an unprecedented success this Christmas – we came in 4th place overall!
  • In Bristol, we’ve been supporting Baby Bank Network with a day a month of technical assistance.

24 Pull Requests: The Hackathon

18 December 2015, by

We at Softwire care about open-source, and for the last 3 years every December we’ve been very involved in 24 Pull Requests, an initiative to encourage people to give back to the open-source community in the 24 days of advent up to Christmas.

That’s still ongoing (although we’re doing great so far, and watch this space for details once we’re done), but this year we decided to kick it up a notch further, and run an internal full-day hackathon, which we recently ran, on the 7th. This came with free holiday for employees (with 1/2 a day of holiday from our morale budget and 1/2 a day from our holiday charity matching scheme), to make it as easy as possible for people to get involved, and prizes for the first 3 contributions and the best 3 contributions (judged at the end).

The Softwire team enjoy a good breakfast

We kicked the day off with a cooked breakfast buffet at 9, following a brief bit of warm up and setup, and then a team stand-up with the 20 or so participants. Everybody quickly went round and outlined what they were looking at (or what they wanted, if they didn’t have an idea), so people doing similar things could find each other, and people with more enthusiasm than specific plans could find inspiration or other people to pair with and help out. And from there, we’re off!

We then managed to get the first prizes for the 3 pull requests all claimed by 11.30, with Rob Pethick adding in missing resources in Humanizer, Hereward Mills removing some unused code from Cachet, and Dan Corder moving AssertJ from JUnit parameterized tests to JUnitParams (quickly followed by a stream more of PRs coming in just slightly behind).

This pace then accelerated further through the afternoon, as people found projects and got more set up, resulting in a very impressive 46 pull requests total by the end of the day (taking us to a total of 89 for the month so far).

These covered all sorts of projects and languages, and included changes like:

Plus a whole range of other interesting and slightly larger changes, along with the many small typo fixes, documentation updates, setup instruction fixes and so on that are so important in really making open-source projects polished, reliable and usable.

Finally, the most credit must of course go to our winning three pull requests of the day:

  1. Adding some detailed and fiddly tests for various statistical distributions in jStat, and fixing the bugs that they found too, by David Simons
  2. Fixing a tricky Sequelize bug, to support column removal with MSSQL DBs, by Michael Kearns
  3. Improving the accuracy of error highlighting in the output of the TypeScript compiler (despite neither knowing the compiler or even the language beforehand), by Iain Monro

Our team hard at work

Great work all around. We enjoyed an excellent day of open-sourcing, made a lot of progress, and we’re now in a great place to do more and more open-source over the coming weeks, and beyond once 24PRs is complete.

We’re now up to 96 pull requests in total, and counting, and we’re hoping to keep making progress up the 24PRs teams leaderboard as it continues!

Watch this space for more updates on the tools we’ve been working on and interesting changes we’ve been making, or follow us on twitter for extra details.

Code Club at Tufnell Park Primary School

25 November 2015, by

image2At Softwire, we’re firm believers in the benefits of using our technical expertise to make a positive impact on society. As part of that effort, we run a weekly after-school coding club at nearby Tufnell Park Primary School, teaching children aged 9-11 the basic concepts of programming (and having lots of fun along the way!). The prospect of starting up a club was a bit daunting at first, but luckily the whole process is made much easier thanks to Code Club, a nationwide organisation that aims to facilitate the process by putting volunteers in contact with local schools and providing a wealth of teaching materials. Sharing the task of organising and running the club between four of us has also made the time commitment much easier to manage and we’ve found the whole experience to be really rewarding.

Code Club have some excellent resources available, including step-by-step worksheets for projects that suit a wide range of experience levels. For children joining the club for the first time, Scratch has proved to be an excellent tool for teaching basic programming concepts, it conveys these concepts in a fun and visually appealing way. Keeping the children engaged in what they’re doing is crucial, so projects that focus on creating games and animations have generally proven to be the biggest hits.

For those children that outgrew what Scratch has to offer, last year we began teaching HTML and CSS,  but this year we’re planning to introduce the more advanced groups to JavaScript instead. This feels like a more natural progression from the visual programming concepts used by Scratch, and should offer the prospect of creating richer and more interactive web pages. While Code Club doesn’t currently provide projects for JavaScript, we’re planning to try out Trinket – an online HTML and JavaScript editor that provides simple code-completion and syntax highlighting – instead, and we’re hoping this will make the transition into text-based coding a much more positive experience.

image3I’m always amazed by how quickly the children grasp the basic concepts (what is an if statement, a for-loop, etc.) so we also aim to encourage the collaborative and problem-solving aspects of programming, skills that we value highly at Softwire, as well. We’ve found that an excellent way to reinforce those concepts is to go beyond the original scope of the project and ask the children to invent extra features they’d like to add to their game. We then chat with them about what code they might need to add to make it work, then let them explore the ideas themselves. This really helps to fire their imagination and they definitely take more personal pride in the result. We’re also fortunate that Tufnell Park school has a blog page where we’ve been able to highlight some of the great projects that the children have created, and this public recognition really helps to encourage them and reward their hard work.

Overall, we’ve really enjoyed the Code Club experience. We’re constantly struck by how enthusiastic the children are about coding and how eager they are to explore new ideas, once they realise that coding isn’t some mysterious and difficult art form, but really a form of puzzle-solving. It’s especially great to see them take the skills they’ve learnt and use them to create their own games, since programming is as much a creative endeavour as it is a technical one.

We have lots of ideas for new projects to explore this year, and with the success of last year’s effort, we now have enough new volunteers within Softwire that we’re planning to expand, with the hope of starting a new club in another nearby school after Christmas! We hope to give another update on our progress then.

Typing Lodash in TypeScript, with Generic Union Types

5 November 2015, by

TypeScript is a powerful compile-to-JS language for the browser and node, designed to act as a superset of JavaScript, with optional static type annotations. We’ve written a detailed series of posts on it recently (start here), but in this post I want to talk about some specific open-source work we’ve done with it around Lodash, and some of the interesting details around how the types involved work.


For those of you who haven’t read the whole series: TypeScript gives you a language very similar to JavaScript, but including future features (due to the compile step) such as classes and arrow functions, and support for more structure, with it’s own module system, and optional type annotations. It allows you to annotate variables with these type annotations as you see fit, and then uses an extremely powerful type inference engine to automatically infer types for much of the rest of your code from there, automatically catching whole classes of bugs for you immediately. This is totally optional though, and any variables without types are implicitly assigned the ‘any’ type, opting them out of type checks entirely.

This all works really well, and TypeScript has quite a few fans over here at Softwire. It gets more difficult when you’re using code written outside your project though, as most of the JavaScript ecosystem is written in plain JavaScript, without type annotations. This takes away some of your new exciting benefits; every library object is treated as having ‘any’ type, so all method calls return ‘any’ type, and passing data through other libraries quickly untypes it.

Fortunately the open-source community stepped up and built DefinitelyTyped, a compilation of external type annotations for other existing libraries. These ‘type definitions’ can be dropped into projects alongside the real library code to let you write completely type-safe code, using non-TypeScript libraries.

This is great! Sadly, it’s not that simple in practice. These type definitions need to be maintained, and can sometimes be inaccurate and out of date.

In this article I want to take a look at a particular example of that, around Lodash’s _.flatten() function, and use this to look at some of the more exciting newer features in TypeScript’s type system, and how that can give us types to effectively describe fairly complex APIs with ease.

What’s _.flatten?

Let’s step back. Lodash is a great library that provides utility functions for all sorts of things that are useful in JavaScript, notably including array manipulation.

Flatten is one of these methods. Flattening an array unwraps any arrays that appear nested within it, and includes the values within those nested arrays instead. Flatten also takes an optional second boolean parameter, defining whether this processes should be recursive. An example:


_.flatten([1, 2, 3]);                     // returns [1, 2, 3] - does nothing

_.flatten([[1], [2, 3]]);                 // returns [1, 2, 3] - unwraps both inner arrays

_.flatten([[1], [2, 3], 4]);              // returns [1, 2, 3, 4] - unwraps both inner arrays,
                                          // and includes the existing non-list element

_.flatten([[1], [2, 3], [[4, 5]]]);       // returns [1, 2, 3, [4, 5]] - unwraps all arrays,
                                          // but only one level

_.flatten([[1], [2, 3], [[4, 5]]], true); // returns [1, 2, 3, 4, 5] - unwraps all arrays 
                                          // recursively


This is frequently very useful, especially in a collection pipeline, and is fairly easy to describe and understand. Sadly it’s not that easy to type, and the previous DefinitelyTyped type definitions didn’t provide static typing over these operations.

What’s wrong with the previous flatten type definitions?

Lots of things! The _.flatten definitions include some method overloads that don’t exist, have some unnecessary duplication, incorrect documentation, but most interestingly their return type isn’t based on their input, which takes away your strict typing. Specifically, the method I’m concerned with has a type definition like the below:


interface LoDashStatic {
  flatten<T>(array: List<any>, isDeep?: boolean): List<T>;


This type says that the flatten method on the LoDashStatic interface (the interface that _ implements) takes a list of anything, and an optional boolean argument, and returns an array of T’s, where T is a generic parameter to flatten. Because T only appears in the output though, not the type of our ‘array’ parameter, this isn’t useful! We can pass a list of numbers, and tell TypeScript we’re expecting a list of strings back, and it won’t know any better.

We can definitely do better than that. Intuitively, you can think of the type of this method as being (for any X, e.g. string, number, or HTMLElement):


_.flatten(list of X): returns a list of X
_.flatten(list of lists of X): returns a list of X
_.flatten(list of both X and lists of X): returns a list of X

_.flatten(list of lists of lists of X): returns a list of list of X (unwraps one level)
_.flatten(list of lists of lists of X, true): returns a list of X (unwraps all levels)


(Ignoring the case where you pass false as the 2nd argument, just for the moment)

Turning this into a TypeScript type definition is a little more involved, but this gives us a reasonable idea of what’s going on here that we can start with.

How do we describe these types in TypeScript?

Let’s start with our core feature: unwrapping a nested list with _.flatten(list of lists of X). The type of this looks like:

flatten<T>(array: List<List<T>>): List<T>;

Here, we say that when I pass flatten a list that only contains lists, which contain elements of some common type T, then I’ll get back a list containing only type T elements. Thus if I call _.flatten([[1], [2, 3]]), TypeScript knows that the only valid T for this is ‘number’, where the input is List<List<number>>, and the output will therefore definitely be a List<number>, and TypeScript can quickly find your mistake if you try to do stupid things with that.

That’s not sufficient though. This covers the [[1], [2, 3]] case, but not the ultra-simple case ([1, 2, 3]) or the mixed case ([[1], [2, 3], 4]). We need something more general that will let TypeScript automatically know that in all those cases the result will be a List<number>.

Fortunately, union types let us define general structures like that. Union types allow you to say a variable is of either type X or type Y, with syntax like: var myVariable: X|Y;. We can use this to handle the mixed value/lists of values case (and thereby both other single-level cases too), with a type definition like:

flatten<T>(array: List<T | List<T>>): List<T>;

I.e. if given a list of items that are either type T, or lists of type T, then you’ll get a list of T back. Neat! This works very nicely, and for clarity (and because we’re going to reuse it elsewhere) we can refactor it out with a type alias, giving a full implementation like:


interface MaybeNestedList<T> extends List<T | List<T>> { }

interface LoDashStatic {
  flatten<T>(array: MaybeNestedList<T>): List<T>;


Can we describe the recursive flatten type?

That fully solves the one-level case. Now, can we solve the recursive case as well, where we provide a 2nd boolean parameter to optionally apply this process recursively to the list structure?

No, sadly.

Unfortunately, in this case the return type depends not just on the types of the parameters provided, but the actual runtime values. _.flatten(xs, false) is the same as _.flatten(xs), so has the same type as before, but _.flatten(xs, true) has a different return type, and we can’t necessarily know which was called at compile time.

(As an aside: with constant values technically we could know this at compile-time, and TypeScript does actually have support for overloading on constants for strings. Not booleans yet though, although I’ve opened an issue to look into it)

We can get close though. To start with, let’s ignore the false argument case. Can we type a recursive flatten? Our previous MaybeNested type doesn’t work, as it only allows lists of X or lists of lists of X, and we want to allow ‘lists of (X or lists of)* X’ (i.e. any depth of list, with an eventually common contained type). We can do this by defining a type alias similar to MaybeNested, but making it recursive. With that, a basic type definition for this (again, ignoring the isDeep = false case) might look something like:


interface RecursiveList<T> extends List<T | RecursiveList<T>> { }

interface LoDashStatic {
  flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T>;


Neat, we can write optionally recursive type definitions! Even better, the TypeScript inference engine is capable of working out what this means, and inferring the types for this (well, sometimes. It may be ambiguous, in which case we’ll have to explicitly specify T, although that is then checked to guarantee it’s a valid candidate).

Unfortunately when we pass isDeep = false, this isn’t correct: _.flatten([[[1]]], false) would be expected to potentially return a List<number>, but because it’s not recursive it’ll actually always return [[1]] (a List<List<number>>).

Union types save the day again though. Let’s make this a little more general (at the cost of being a little less specific):

flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T> | RecursiveList<T>;

We can make the return type more general, to include both potential cases explicitly. Either we’re returning a totally unwrapped list of T, or we’re returning list that contains at least one more level of nesting (conveniently, this has the same definition as our recursive list input). This is actually a little dupicative, List<T> is a RecursiveList<T>, but including both definitions is a bit clearer, to my eye. This isn’t quite as specific as we’d like, but it is now always correct, and still much closer than the original type (where we essentially had to blind cast things, or accept any-types everywhere).

Putting all this together

These two types together allow us to replace the original definition. We can be extra specific and include both by removing the optional parameter from the original type definition, and instead including two separate definitions, as we can be more specific about the case where the boolean parameter is omitted. Wrapping all that up, this takes us from our original definition:


interface LoDashStatic {
  flatten<T>(array: List<any>, isDeep?: boolean): List<T>;


to our new, improved, and more typesafe definition:


interface RecursiveList<T> extends List<T | RecursiveList<T>> { }
interface MaybeNestedList<T> extends List<T | List<T>> { }

interface LoDashStatic {
  flatten<T>(array: MaybeNestedList<T>): List<T>;
  flatten<T>(array: RecursiveList<T>, isDeep: boolean): List<T> | RecursiveList<T>;


You can play around with this for yourself, and examine the errors and the compiler output, using the TypeScript Playground.

We’ve submitted this back to the DefinitelyTyped project (with other related changes), in, and this has now been merged, fixing this for Lodash lovers everywhere!