The past several years have seen a monumental shift in how the tech sector in Northern Ireland is seen, both by global investors looking for new opportunities and by local students trying to decide on a career. The number of women entering the tech and software development industry here has improved markedly thanks to young students getting wider exposure to the field, but tech still has an inclusivity problem and can be very intimidating for newcomers. Could part of the problem just be how we communicate information to our colleagues and clients?
This was the interesting point raised by Tech Speaker and Senior Software Engineer Kenigbolo Meya Stephen at this year’s NI Dev Conf, that we can make tech more inclusive by paying attention to the language we use. From replacing accidentally gendered language in an email meant for a group to writing documentation with consideration to how understandable it would be to a less experienced developer, there are definitely things we can do to improve the way we communicate as developers.
Here at Sync NI, we’re looking back at some of our favourite talks and speakers from this year's NI Dev Conf. We caught up with Kenigbolo Meya Stephen to get his thoughts on tech’s inclusivity problem.
Related: NI Dev Conf: Who cares about accessibility? Andrew Gribben does!
Related: NI Dev Conf: Using tech conferences to empower your people
Related: Opinion: NI Dev Conf makes the NI tech industry something special
Sync NI: In your talk, you mentioned some of the simple things that developers often get wrong in how they communicate their work, in particular with documentation. What are the most common pitfalls you’ve seen?
Kenigbolo Meya Stephen: The most common pitfall I’d highlight first is assumption. More often than one would like, developers craft documentation based on several assumptions and the frequent one I’ve noticed is them expecting everyone to have the same level of understanding as themselves. There are a few others as well, the most common ones being inconsiderate writing styles, unhelpful phrasing, gendered phrase and documentation clutter (which is probably the most common pitfall you’ll find around).
Sync NI: One of the major points you made was about inconsiderate writing, such as the use of gendered phrases for documents or messages meant for everyone. Can you give some more examples of other phrases we might not realise are problematic?
Inconsiderate writing and gendered phrases have become a very common phenomenon in documentation. It is most times the case that it might not be done intentionally, however the effects are definitely felt by those consuming the docs. Typical examples here are words which have been used for decades in tech e.g.
Master/Slave - This has been used for decades in representing a bi-directional relationship hierarchy. Whilst this might seem harmless, for someone whose history goes along that part this is definitely highly offensive, especially considering that there are better ways to rephrase this such as primary/replica or parent/child
Whitelist/Blacklist - This is also one which has been used for decades and absolutely has a racial tone engrained in it. This could for example easily be changed to allowlist/denylist. For some reason, this term is still widely used even amongst companies that claim to support diversity and inclusion, as well as still being commonly used in high level specification
Sync NI: Tech has an inclusivity problem across factors such as gender and race, and part of it is definitely in how we communicate information at all levels. What small changes can a company make to improve its inclusivity in this regard?
I believe one of the best ways to improve inclusiveness in the workplace is actually showing up and walking the walk. What I mean by this is that “diversity and inclusion” shouldn’t be something a company says they are, it should be something people see in a company and point out. If you have to be the one to say you’re a diverse company then you’re doing something wrong.
One easy step to improve inclusivity is to look at the representation in your teams and see if it represents what a diverse team should look like. If it doesn’t then the first and most important change you can make is to accept that you’re not a diverse/inclusive team/company yet. The truth is that you cannot work towards a problem you have failed to identify.
Once there is a consciousness of this fact, the next appropriate step is to find out why this is the case. Does it have to do with HR policies? Does it have to do with something else? Is it just an unfortunate unavoidable issue at that particular point in time? Identifying the root cause helps you know what small changes you can implement to proceed. It could be anything from joining more diversity events, encouraging a more open office where people can talk about their feelings and women do not feel like they’re spoken over by their male colleagues?
HR digging a bit deeper to make people understand all candidates are welcome to apply? Reach out to other companies who have navigated it to get more insights? A good example of this is Slack, a company so diverse and inclusive that they never need to advertise about it because it is seen from any angle you look at the company.
Sync NI: If there’s one message you hoped people would take away from your talk at NI Dev Conf, what would it be?
Documentation is equally as important (if not more) as code. Give it the same (or even more) attention like you would give to your code. It is a communication tool that is supposed to explain both your thoughts (technical and implementation wise) way after you leave your role. Also just like CI/CD, documentation should be continuous as well.
Sync NI: Thanks for your time!
Follow Kenigbolo on twitter at @expensivestevie.
