25 May 2017, by Andy Patterson
Software engineering is the foundation that allows new consumer services, efficient back-office systems, and market-disrupting products to be created. As with all foundations, it’s important to get the basic principles correct, and we believe that these principals are not only technical but creative. There are so many possible implementations of software applications that an environment which stimulates creative and innovative solutions will deliver the best results.
If we start with the humble software engineer, we can look at what motivates them to do their job effectively and create software to make a difference. A large body of research exists (summarised neatly in Drive) to demonstrate that extrinsic motivators (reward and punishment) work well for simple rule-based tasks, but work very poorly for creative or complex tasks. For these types of task, we can measure the presence (or lack of) three types of intrinsic motivation:
- Autonomy: the urge and capability to direct our own work and make our own decisions
- Mastery: the desire to master our tools and improve our skills
- Purpose: the need to do something with meaning, and with clear direction
These motivators provide us with a language to discuss how to create an environment that is productive and efficient, producing brilliant software; conversely, it provides terms to explain why companies can have environments that are stagnant and inefficient, leading to software that no one wants to use.
We start with the hardest motivator: autonomy. It might seem confusing that autonomy is important – isn’t the job of a software engineer to implement something that the business has decided is necessary? Allowing engineers to dictate their own workloads is only a single example of autonomy (and, incidentally, one that Google and others have used to great effect). Indeed, most engineers are happy to admit that UX or business analysis are not their areas of expertise. However, autonomy is much deeper than this – it’s about giving engineer the freedom to decide how to implement what’s required (what processes or frameworks to use), and the responsibility for delivering working software to end users. Teams with high autonomy are more efficient, as they’re empowered to remove processes that slow development effort down, and free to adopt better tools or frameworks as they become available.
One of the reasons that agile practices (and by extension, practices like Continuous Delivery and DevOps) have been so successful is that they push autonomy down to the team level, focus on cross-functional teams, and encourage continuous change. This isn’t to say that agile methods such as scrum or kanban are the only methods for achieving autonomy: they’re just a particularly well-known and effective one.
For software engineers, mastery of a toolset, skill, or framework is immensely satisfying. However, Mastery is more than perfecting one skill: it’s heavily reliant on continuous improvement. It should be obvious that technology is a rapidly-changing industry, and that adopting new tools and skills as they become available is the key to success.
Mastery of technical improvements
By now, the analogy of technical debt is well known and addresses one aspect of mastery (the desire to improve the code being worked on). Long-running codebases with low technical debt are strongly correlated with products that are reliable, high-quality, and respond predictably to change requests – Google is an excellent example of a company that invests heavily in reducing debt. However, technical debt is an imperfect analogy as it is unquantifiable, and must be measured by its side effects: slow, unreliable delivery, and disenfranchised, unmotivated developers. Business that focus solely on putting features in front of customers win in the short term, but over the long term incur sufficient debt that delivering even simple features takes a huge effort.
Mastery of personal development
While developers will generally self-improve over time, this can be greatly accelerated with the right support and processes, including formal and informal training. These two approaches differ in what they aim to achieve, and personal development is normally most effective when they’re combined. Training courses and conferences aim to teach a specific skill, or give a breadth of knowledge about the industry. They also provide opportunities to network and engage with companies working on similar problems. By contrast, coaching and mentoring are much more individual, helping developers improve their strengths and mitigate weaknesses. These approaches can deliver huge benefits to teams and organisations:
- Ensuring that knowledge is spread across the team, removing single points of failure and improving consistency
- Improving skills and abilities
- Allowing individuals to take on more responsibility, resulting in more capable teams
The rate at which software development changes is phenomenal; the tools and technologies for most new projects have changed in the last 5 years, and are radically different to those 10 years ago. The NodeJs ecosystem is the canonical example; just over 5 years old, NodeJs and npm now have over 4 million active developers, and are used by thousands of companies.
Mastery deals less with each individual change, and is more concerned with the process of adapting to changes over time. It’s important to determine where best to invest in changing technology, but as we saw from autonomy, the correct place to make this decision is within an engineering team.
Given that most software engineering is product or service-focussed, providing a clear backlog and direction of work gives a purpose to both individual and team efforts. In addition, a frequent and well-defined release schedule provides a visible goal to focus on. A purpose can be highly effective when combined with the goals of Mastery; to not only deliver software, but to get better at the process of delivering software. Teams with a strong sense of purpose are more likely to succeed, and less likely to get distracted and solve unrelated problems.
Scaling and disruption
Autonomy, mastery, and purpose are useful tools as they allow us to examine teams (or individuals) separately, and suggest targeted improvements. Some teams may have a strong sense of purpose, but are held back by poor tooling, whereas other teams may be able to make wide-reaching decisions but lack a clear goal. The ability to address the needs of each team in isolation allows this approach to scale. There are obvious technical challenges with scaling development work across multiple teams (particularly communication overhead made famous by the Mythical Man Month), but teams that are motivated to succeed will overcome these problems for themselves.
Looking at the world through the lens of intrinsic motivation it’s possible to see why a startup can deliver a disruptive product, but an industry behemoth can struggle to update its flagship products and services. The startup’s developers have autonomy (freedom from constraining structure and processes), mastery (time and money to improve skills and tooling), and purpose (the vision of the startup). Large organisations can be disruptive – Apple, Amazon, and Google regularly deliver ground-breaking products – but to do so requires continual effort and focus.
 The perils of ignoring software development: http://www.mckinsey.com/industries/high-tech/our-insights/the-perils-of-ignoring-software-development
 Drive: the surprising truth about what motivates us: http://www.worldcat.org/title/drive-the-surprising-truth-about-what-motivates-us/oclc/311778265
 Google’s “20 percent time” in action: https://googleblog.blogspot.co.uk/2006/05/googles-20-percent-time-in-action.html
 Searching for Build Debt http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/37755.pdf
10 May 2017, by Helen Hosein
The technology industry is notoriously bad at embracing diversity. Almost everyone acknowledges the problem, but a lot of folks don’t know where to start. As a non-binary person of colour who’s worked in technology for their entire career, I’ve seen and experienced a lot of things that I think could be better. Here at Softwire, my colleagues often ask me what they can do to help. This is where allyship becomes important – to amplify our voices and help make the technology industry (and the world!) a more equal place.
Who can be an ally?
Anyone can be an ally! It doesn’t matter what your own background is, or how you identify. Even if you’re going through your own struggle, you can still be an ally to someone whose struggle may be slightly different than yours. If you don’t think that applies to you, that’s ok too – there’s no need to feel guilty about privilege. What we call privilege may just mean that there are more ways that you can help out.
A good ally isn’t a perfect human being either – we’re all flawed, and we all carry our own biases. Part of allyship is educating yourself and working to overcome yours.
What do I have to do?
I can’t speak for all marginalised folks (nor would I want to!) but here are three steps that I’d suggest to get you started.
Step 1: Talk to us
Ask your friends and colleagues what it’s like for them (understand, though, that sometimes talking about it is hard, so be patient). You may already have done some reading up, which is awesome, but don’t assume that you already know what your friend’s or colleague’s experience is like. Everyone’s experience is different. Your friend may have a very different experience from someone you’ve read about, or someone you’ve talked to in the past. The more you talk to us, and listen with humility and an open mind, the more you learn about us as individuals and as a group.
Step 2: Believe us
When you talk to us, some of what you hear may surprise you! It’s easy to imagine that our negative experiences are rare, not only because you may not experience them yourself, but also because you may not hear about them. For a person who feels marginalised, it can be embarrassing, or worse, frightening, to face the prospect of coming forward. In some cases, they may feel personally threatened.
Those who do speak out usually feel more comfortable doing so among other members of their group – they know these are people who will understand. If you’re not a member of that particular group, you may never get to hear those stories. That makes it all the more important, when someone does make the leap of faith to confide in you, that you believe everything they say. By believing them, you demonstrate that it’s safe to come talk to you about their experiences.
Step 3: Support us
Get involved! There are loads of ways to help support marginalised and underrepresented folks in the technology industry. You can lend your skills at events like codebar, support inclusive events like AlterConf or Diversity in Tech, sign the Minimum Viable Diversity Pledge, or do lots more stuff like those.
Don’t neglect the people you already know, as well. If you’re managing someone who may be from a marginalised group, check in on them. If there’s something they’ve asked for in your 1:1s, make sure you follow through.
Most of all, make sure you give us space to be heard, and back us up when we need it.
Remember that “ally” is not just a noun, it’s also a verb, so make sure you do the work to help out. This article is just a starting point; there are a lot more useful resources out there when you’re ready to take your journey as an ally further. The job is never done – there’s always more to learn, and more to do, so keep working at it!
8 February 2017, by Harry Cummings
This is part of a series of blog posts on code reviews, based on two sessions of an internal discussion forum at Softwire. See the first post in this series for more information. In this post, we’ll discuss improving the interaction between the reviewer and the recipient of the review (i.e. the developer).
How do we mediate reviews?
There are all sorts of ways to mediate a review:
- Specialist review tools like Crucible and UpSource
- Repository systems with review features, like GitHub, GitLab, and Gerrit
- Sending diffs/patches over email
- Talking through the code face-to-face, e.g.
- Have the reviewer sit with the developer at their computer
- Reviewing code as a team around a big screen
- The old-fashioned way: Print out the code, stick it to the wall, and scribble over it together
- Pair-programming is arguably a form of code review, taking place as the code is written
Broadly speaking, all of the above approaches fall into two categories: asynchronous online reviews, or in-person reviews. Which kind of approach people preferred was probably the most contentious part of our discussions at Softwire. There was a range of opinions here, highlighting benefits and drawbacks to each approach.
Asynchronous online reviews vs. in-person reviews
Several people made the point that in-person reviews can be more useful for training, and for knowledge sharing in both directions. Face-to-face discussions make it easier to provide context around the code changes. They also give the developer a chance to talk the reviewer through the changes in a sensible order, or perhaps commit-by-commit. This might be better than the arbitrary order in which changes are presented by a diff/patch or an online review tool.
In-person reviews may also provide opportunities to pick up other context that might not be directly relevant to the code quality but is useful for the reviewer to know. For example, any frustrating obstacles the developer encountered while working on the task, which the team might need to address. Reviewing in-person can also save developers from context-switching. If you have enough reviewers on a team, developers can get a review as soon as they finish their code rather than starting on another task and subsequently switching back to deal with review feedback. This obviously comes at the cost of the reviewers having to make themselves highly interruptable though.
A lot of the literature on code reviews also favours some kind of in-person reviews. Here’s one particularly strongly stated example:
“Effective code reviews are not done via a tool or remotely—they are done when you’re sitting side-by-side with the person or pair who just wrote the code. This personal way allows you to share and teach much more information than you can pass in a text-based tool. Don’t skimp on this! If you’re going to do code reviews because your code sucks, do them right.” – Roy Osherove in Notes to a Software Team Leader
On the other hand, some of our reviewers felt that asynchronous online reviews were better partly because they don’t provide the reviewer any additional context. Online reviews arguably make for a more authentic review of maintainability (future developers on the project probably won’t have the luxury of talking through the code with the original developer). Also, coming at the review from their own angle might allow the reviewer to spot issues that the developer has missed.
One major advantage of online tools is that they leave a permanent record of review comments. Some tooling combinations make it particularly easy to go back through old reviews (for example, Crucible with JIRA integration). Several people had worked on projects where they had benefited from the ability to do this.
Several people found it useful to mix online and in-person approaches, perhaps depending on the nature of the change. For example:
- Performing a high-level review in isolation first, then talking through with the developer for context, before finally performing a line-by-line review online.
- Saving face-to-face reviews for bigger or more complex changes
- Carrying out most of the review discussion in person, but using an online tool to track this. That is, initiating the review process and documenting any important outcomes of the discussion.
Reviewers: Making code reviews better for the developer
Quite a few people found phrasing review comments to be a challenge, especially when using online review tools. Some of our reviewers were concerned whether we did enough to make new-starters comfortable with the process, and to make it clear that they can and should challenge their reviewers. After all, the developer is always closest to the code and knows it best. It can be worth a reviewer (particularly one in a more senior position) reminding the developer of this explicitly.
Ways to make reviews more positive included:
- Phrasing review comments as questions or suggestions rather than statements
- Talking through major issues in person rather than writing lengthy review comments
- Talking through and fixing batches of very minor issues in person, rather than writing lots of tiny review comments
- Remembering to always make some positive comments (especially in reviews with some criticisms elsewhere)
This might be more or less important depending on the developer. Generally, reviewers should be conscious of the recipient of the code review and tailor things to them. Extra tact may be required when reviewing code from external third parties, which can be politically awkward.
Developers: Making code reviews better for the reviewer
This wasn’t a question we had set out to answer with our discussion. However, people naturally mentioned how they approached submitting their own work for review, and several common points arose:
- Performing their own review of the changes first (ideally in the same review tool the reviewer will be using)
- Linking to any relevant context (e.g. the relevant ticket in the project’s issue tracker)
- Keeping auto-generated files out of the review (if appropriate and the review tool allows)
- Splitting into sensible commits
- Especially keeping big renames, file moves, or other refactorings separate
- Also splitting code changes across multiple commits where appropriate)
- On one project, we experimented with commiting and reviewing one test at a time, resulting in many small reviews. On a small team, this turned out to be a very effective workflow.
As we saw in the previous post, there are many different valid approaches to code reviews. Organisations should give teams the flexibility to choose a code review process that meets their needs. The first post in this series covered the wide and varied benefits of code reviews. As a team, you should reflect on your code review process, considering what value it provides and what further value it could provide. This will allow you to evolve your code review process to be more effective. I hope this series gives you some ideas that you find useful. Please feel free to share your own ideas on code reviews in the comments below.
1 February 2017, by Harry Cummings
This is part of a series of blog posts on code reviews, based on two sessions of an internal discussion forum at Softwire. See the first post in this series for more information. In this post, we’ll cover some of our current approaches to code reviews.
We tend to at least implicitly perform code reviews in multiple passes. These break down into three stages:
- “Outside-in” preliminary review
- Reading through the original user story or defect
- Reviewing the design
- Checking out the dev branch and doing some cursory testing (this can be useful for reviewing UI issues or things that are hard to spot from the code or by automated tests)
- Reviewing the tests at a high level (do they function as good developer documentation for the code)
- Review of the code itself and the tests in detail
- Review of any activities surrounding the code change, e.g.:
- Manual testing
- External documentation
- Risk/impact assessment
Note that not every project needs all of these passes. The point is that “code review” is a broad term covering a range of activities. Which activities you carry out, and when, may vary by project. Although within each project, there’s a lot of value in being consistent. Consistency helps developers become comfortable with the review process, and makes code reviews a much more reliable tool for quality assurance.
When do we review
As noted above, different code review activities may be carried out at different times. There was a general consensus in our discussions that reviewing earlier is preferable. Most projects insisted on at least some form of review before commit, although a few relaxed this in special cases (depending on the type of project) to avoid becoming a bottleneck.
About half our teams are actively performing up-front High-Level Design reviews. These can be useful for everyone but especially for less experienced developers (which might just mean less experience with the particular project). They encourage working through design issues up front, avoiding wasted time at the implementation stage. It also means the code reviews can then focus on just the code. The only problem mentioned with HLD reviews was that it can be a bit unclear what we mean by an HLD, and sometimes people go too low-level. For projects broken up into well-sized tasks, an HLD could just be a couple of sentences and a few bullet points.
An alternative to up-front HLD reviews is reviewing roughly implemented code, essentially a spike or proof-of-concept. This can be particularly useful on tricky legacy codebases, where it might be hard to see how to go about introducing new functionality.
Who carries out reviews?
Most of the people in our discussions were their team’s technical lead. Unsurprisingly, tech leads were doing reviews themselves, but there was a lot of support for reviews being done by not only the tech lead. Getting more people involved in the review process is a good way to build people’s confidence, share knowledge within the team, and help people become more comfortable with the review process. One person doing all the reviews can also become a bottleneck and slow the team down. Perhaps more importantly, giving developers the autonomy to carry out genuine peer reviews is a show of faith in the team’s ability, and makes it easier for reviews to act as a positive motivator.
One problem with having multiple people involved in reviewing is that it can become confusing for developers. It’s not always clear how to pick an initial reviewer, or when a review would be considered “done”. It’s important for each team to agree on a consistent approach, although approaches can of course vary between teams. Most of our teams use one of the following approaches:
- Let the developer choose the initial reviewer and allow the developer or the reviewer escalate to the tech lead if needed
- Have a high-level second line review as part of the standard review process
- Include the tech lead on every review, but allow developers to merge their changes as soon as at least one person has reviewed it. This prevents the tech lead becoming a bottleneck but still gives them a chance to go into detail on any red flags.
All the above approaches include the possibility of the tech lead acting as a second line reviewer. Our tech leads would go into more or less detail in their review based on the nature of the change and the experience of the other people involved (i.e. the original developer and reviewer). In some cases perhaps just reviewing the comments from the first-line reviewer and/or looking out for changes within common problem areas of the codebase.
How much detail to go into in a second line review is a matter of judgement and may not be obvious. It can help to think of the goal of reviewing as gaining trust that the code is up to standard, and getting involved enough to meet this goal. Of course, it’s still worth bearing in mind the importance of code reviews for training and mentoring. A second-line reviewer may be looking out for learning opportunities for both the developer and the initial reviewer. They’re also in a position to assess the quality of the interaction between these two roles. This will be the subject of the next post.
25 January 2017, by Harry Cummings
There is a lot of writing on the importance of code reviews and how to go about them at a low-level (i.e. what to look for in the code). This series of posts takes a higher-level look at how to approach code reviews and how to maximise their benefits. We’ll also refer throughout to other useful writing on code reviewing and how to make the most of it.
At Softwire, we have always carried out code reviews in one form or another. But our methods and tooling have evolved over time, and often varied between projects. This allows each project team to find a way of working that best suits them.
We recently ran couple of internal lunchtime discussion forums to talk about code reviewing and pool our collective experience. The goal here wasn’t to try and agree on “one true code review methodology”, but just to share ideas between teams. We discussed the perceived benefits and overall aims of code review, and how we go about achieving these.
It turned out that the approaches to code reviews within the company are even more varied than I’d thought. But there was some broad consensus on the benefits and aims of code reviews. However, the benefits that we valued most may surprise you.
What value do we get from code reviews?
Both of our discussions came up with a similar consensus on the range of benefits provided by code reviews. In rough order of their prominence in the discussions, these were:
- Training and mentoring
- In fact, several people felt that the healthiest approach to code reviewing was to treat it as a training opportunity first
- Knowledge sharing
- In both directions (i.e. both the developer and the reviewer had opportunities to learn from one another)
- This includes sharing domain knowledge, general technical knowledge, and knowledge of the specific codebase
- Encouraging people to produce better work (knowing that it will be scrutinised by your peers)
- Keeping the codebase consistent, in terms of style and structure
- More generally, keeping the codebase maintainable
- Catching defects, or at least catching them earlier (and so making them cheaper to fix)
One point I found interesting here was that “catching defects” was one of the last points to come up, in both discussions. There was a lot more emphasis on the holistic benefits of code review: training, knowledge sharing, and improving the overall codebase.
Quality assurance is the main focus of some widely-referenced sources on code reviewing. For example, Jeff Atwood’s blog post Code Reviews: Just Do It, and the two books that it references (Peer Reviews in Software and Code Complete). These mainly focus on reducing errors/defects/bugs, and only briefly mention other benefits. Of course, improving defect detection is not a bad argument for doing code reviews. Perhaps it’s also the most persuasive one in organisations that don’t have a history of doing code reviews and are reluctant to let people start spending time on it.
Defect detection is a valuable and somewhat measurable benefit, which may make it a good angle to sell the idea of doing code reviews at all. However, for the developers and tech leads who actually carry out code review, it doesn’t need to be the only aim or even the primary aim of the exercise. So how do we go about code reviews at Softwire? We’ll cover this in the next post.
22 December 2016, by Jiang Yingxin
Check out all the awesome fundraising events we’ve held in the last 2 months!
We happen to have lots of amazingly talented musicians here at Softwire, and this year our top lead guitarist Harry organised our popular Charity RockStock in aid of mental health charity Mind, and WarChild, a charity based right next door to us in Kentish Town who are doing fantastic work protecting the rights of children caught up in war. We had a blast and raised nearly £600, which was doubled for a total of £1200 under Softwire’s generous charity matching scheme!
As usual, our resident quizmaster and commercial director Tom wrote and hosted our annual quiz in aid of Médecins Sans Frontières. As a result of his reputation for setting really fun and interesting quizzes, his persistent marketing campaign in the weeks leading up to the event, and his glamorous assistant Lachlan’s raffle-ticket-selling skills, we raised a whopping £4,850 for MSF after Softwire’s doubling.
The Great Softwire Bake-Off
Our kitchen team Helen, Dom and Massimo have been hosting regular Charity Breakfast Clubs for Refuge. This month they put on something extra special – to help us through Bake-Off withdrawal the week after the final, they hosted a lavish bake-off with plenty of cake, tea and cocktails for bakers and non-bakers alike. We had lots of stunning entries from various Softwirians an impressive chequerboard cake, mille-feuille, and a gingerbread house beautifully decorated by our director Dan’s two children. Star Baker went to James with his delicious fruity sponge cake. With Softwire’s matching, we raised a total of £1,400.
We’ve been holding regular Charity Saturdays since our founding director Dan came up with the brilliant idea three years ago. It’s a day in which we all come into the office to do what we do best – a normal day’s work – and Softwire donates all the money earned by the company that day to charity. It’s incredibly efficient and is by far our most successful fundraising event each year. We raised nearly £11,000 in just one day! The money went to our usual favourites – SCI, Ashanti Development, Home-Start UK and Giving What We Can.
Christmas Jumper Day
To round off the year, we showed off our silliest Christmas jumpers for Save the Children during our annual Christmas pub lunch, and raised another £145.
We’ve raised over £18k in the last two months, for a year-end grand total of over £30k, and we’ve had lots of fun doing it too!
21 October 2016, by Anna Tindall
As a second year Computer Science student at Cambridge without much free time, I had learnt a lot of theory but had done surprisingly little useful programming. I therefore applied for a summer internship at Softwire to change this. I wanted to gain experience working a proper project from beginning to end and Softwire did not disappoint. I did a four-week training internship starting at the end of July.
6 June 2016, by Emily Penycate
At Softwire the staff are introduced to a lot of interesting new activities, and Thursday 14th April was no exception as Softwire London’s Chillout was transformed into a swinging dance floor from the 1920’s!
Staff donned their glad rags, rock-stepped and shuffled to their first swing dance lesson, provided by the Mudflappers’ teacher Olly. The class was aimed at complete beginners and the hope was to provide people enough simple moves they can string together to make a number to any swing song. Some of the class were lucky enough to have done a fair amount of partner dancing before; like Suzanne who does West Coast Swing every week, and Dom who has been to the Bristol swing dance festival a couple of times!
After a funky warm up which had everyone groove stepping around the room and waggling their hands over their heads, the group partnered up and learnt about 6 and 8 beat steps. Swing, and in this case ‘lindy-hop’, is in 32 beat phrases; this means you need to select the right number of 6 and 8 beat moves to finish with the end of a phrase. Olly armed everyone with a 6 beat basic (twice), a tuck turn, a bring back and then a fancy finish called ‘Johnny’s Drop’ to which the group responded with great enthusiasm and abandon.
Swing dancing, like salsa and tango, is a ‘led dance’ which means the class split into leads and follows. Traditionally this is split along gender lines, in true Softwire fashion everyone got a go at both roles. This created the occasional interesting pairings like Dom 5’5” leading Alex 6’7” in some pretty spectacular twirls!
Everyone involved had a great time and have decided to head along to Olly’s normal lesson, in Dalston, in the coming weeks.
23 March 2016, by Vikki Vile
At Softwire they’re very lucky to have freshly prepared lunches cooked for us every day by our amazing kitchen team, Helen, Dom and Massimo. Undoubtedly this is something that hugely contributes to what makes Softwire such an awesome place to work and helped us achieve 14th in this year’s Best Small Companies to work for.
Our kitchen team is committed to sourcing the best and most sustainable fresh ingredients for our lunches. When they are not cooking for us they are always looking for new ideas, suppliers and products to enhance and improve the lunches on offer.
Apart from baking bread and making pasta (actually they do sometimes do this as well!) the kitchen team pretty much prepare and cook everything we eat in the Softwire kitchens. They use fresh herbs, seasonal ingredients and quality suppliers to deliver lunches that are a highlight of our day.
In order to consistently offer us such high quality, all food is sourced from local North London suppliers; eggs are always free range and from reputable producers (Clarence Court or Black Farmer), fresh chicken, pork, lamb and beef is always free range (supplied by Meat Naturally) and fresh vegetables delivered daily. Seasonal vegetables are used whenever possible to minimize food miles and to maximise flavour and value for money. Cheeses and dried goods are sourced from Carnevale (Italian supplier) and Ocado. Our kitchen team always select the products that offer the best quality and flavour and will use organic whenever possible to produce roughly eighty delicious lunches every working day.
16 February 2016, by Jenny Mulholland
Following 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.