Softwire Blog

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!

Volunteering with Code Club Pro

21 October 2015, by

At Softwire, we’re committed to educational outreach because it’s important to give children from all backgrounds the same opportunities, particularly in the tech sector. So we’ve been pretty excited by Code Club Pro, a new opportunity to contribute really efficiently to how coding is taught in every UK school.

A new primary school curriculum introduced last year requires children to learn coding from the age of 5. But most teachers don’t know how to code, so Code Club (a non-profit organisation running coding clubs in schools) set up Code Club Pro to help fill that gap. Code Club Pro recruits volunteers with computing skills (that’s us!) and gives them the training and materials they need to deliver training sessions to teachers. Essentially they teach us how to teach teachers to teach computing. The volunteers then organise sessions with schools through Code Club Pro.

Our own Jamie Humphries championed the cause internally and encouraged people to get involved, successfully persuading a large number of the company to sign up as Code Club Pro trainers, starting them off on the process.

Our first session was in April at a primary school in Manor House. This was slightly intimidating; we were trying to teach a class full of experienced teachers, and teaching is after all what they do all day! A guy from the local authority showed up to see how it went, which didn’t help with the nerves either. But we shouldn’t have worried – everyone was really nice and seemed very engaged with the session, and we got lots of encouraging feedback.

One lady in particular said she’d been worried by how difficult and tiring this session might be, especially after a long day at work. She wasn’t very comfortable with technical ideas, but during the session was clearly taking things on board. Afterwards she came up to us and thanked us for making the topic less scary to her.

We realised that despite not being teachers ourselves, we could genuinely reach out to children by sharing with these teachers our expertise and, just as importantly, our enthusiasm for coding. We hope that some of that passion will be passed on to lots of children, many of whom would otherwise never have learned to code!

What does it mean to be a charity trustee?

28 September 2015, by


I’ve been volunteering with Ghanaian charity Ashanti Development for nearly 7 years. Ashanti Development was started when Martha Boadu came to England from Ghana. Her plan was to save money that she earned for working so that she could personally pay to install clean water into her home village of Gyetiase. She teamed up with her neighbour in London, Penny David and they quickly found that this was achievable. Luckily lots of people believe in this as a goal and so they raised the money and put in a piped water system.

Following on from this they continued to received grants and expanded their work to include building latrines, hygiene training, health and micro-credit and economic development. They also expanded geographically to help the villages surrounding Gyetiase. In 2013 Softwire sponsored the local village of Bonkron and we continue to provide support to them. (We just built a kindergarten.)Cutting the ribbon

This year Penny asked me to become a Trustee of the charity. As a trustee, I attend board meetings and help make the executive decisions of the charity, to make sure that it is fulfilling its objectives and delivering as well as it possibly can. Like being a director of a private company, I am now (jointly with the other directors) responsible for ensuring that the charity is complying with the law and completing any necessary paperwork.


It’s early days for me, but I’m delighted to be able to contribute more to the charity, using skills that I have developed in my business career. As a trustee I do of course continue with all my other activities to support the charity – Softwire are going on a trip to visit Bonkron for the first time in January 2016.