Sociolinguistics and the JavaScript Community: A Love Story
By Harriett Lawrence
[ Applause ] >> Okay.
Hello, I'm Harriet.
As Glenn said, I'm from Melbourne, Australia.
And today I'm going talking about community building with the help of sociolinguistics.
This is a talk about what it is, how to use in the JavaScript and how we can use it in
daytoday communications to make it more welcoming and a thing to be a part
Of before that, a little bit about me.
I work as a technical writer.
We're a continuous integration platform.
Our product is mostly used by other developers.
So I spend a lot of time thinking about how best to explain parts of our product to nontechnical
users who may or may not be familiar with integration.
I worked for five years before I found I was interested in writing documentation and helping
other developers use cool tools than writing code.
This kicked off my master's degree.
And I'm mostly through a master�s of applied linguistic at the University of Melbourne.
I got interested in the intersection of linguistics and computer science.
This started as a paper for uni, this paper, in fact.
And gave me the opportunity to prepare a tutorial that introduced JavaScript from a few years
ago.
I can't squish 4 or 5,000 words into a 25minute talk.
But I'll do my best and you can find me afterwards with questions.
For so let's talk about communities.
What is a community?
Pretty much just a bunch of people all together doing a thing.
In linguistics, it's a community of practice.
It's a shared meeting making.
And usually this term is used for communities formed around a specific goal.
Like a project or an open source tool.
But we can take this further and look at communities that form around programming languages.
They're communities of practice just like those that form around natural languages.
We need to look at what the community looks like from the outside as well as from the
inside.
This is how it looks to potential members.
When they want to join the community, they have to look at what they are doing differently.
And we are part of the JavaScript and part of other ones as well.
How do you feel beauty talking about using JavaScript versus Ruby and Erlang.
They can be divided into language and culture.
The language is jargon and communitywide injokes.
That kind of stuff.
The cultural things, our approach to open source, diversity strategy, how we go about
solving problems.
Problems with communication as well as programming problems.
The language can also be described in linguistic faction early, and social factors.
We mush these together, we get sociolinguistics.
And we have definitions.
Sociolinguistic, study of how language functions in a society.
This is a really broad field and covers way too much stuff for this talk.
So something relevant to us is language socialization.
Becoming a member of society through the use of language.
I said this talk about would be about sociolinguistic, I lied.
It is about socialization.
But doesn't sound as exciting.
In the natural language learning sense, socialization is the words we use and all of the other stuff
that's not words as well.
You might be familiar with this concept.
Have you found it's easier to learn a language if you're living in a country that speaks
it?
You get the pronunciation and the slang and the body language and all this important junk
at the same time.
All of this together is socialization.
So being part of a community means that you're helping to build it.
And we want nice communities.
We want people to feel welcome.
And we want it to be easy for them to join.
And these things are really important because we want people to be part of the JavaScript
magic.
Let's look at how we can do this better.
The JavaScript people are pretty great at this stuff compared to a lot of other tech
communities.
But what does socialization look like in practice?
The most important thing for us is the language that we use when we talk about JavaScript.
So there are different programming languages.
We have different ways of being a member.
So how do we let people know what our special JavaScript way of doing things actually is?
We use socialization strategies.
And there's heaps of them and I'm not going to cover them together.
I have picked out some and divided into three categories to make them easy to use.
We have welcoming, focused and communityfocused.
There are two types of welcoming.
Positive and negative.
So an example of some positive welcoming is something like this.
So here's my tiny project.
Learning this thing was hard, but was also fun and worth it.
So let's break this down into sections.
Here's some of my tiny project.
This little bit actually tell us quite a lot about our community of practice.
It tells us that posting a small project or a fragment of one is totally normal and things
don't have to be huge, brilliant ideas or finished or perfect for us to share them.
Learning this thing was hard.
This shows people who are reading the Tweet that JavaScript developers are comfortable
with vulnerability and it makes vulnerability okay for others as well.
And it was also fun and worth it.
So this shows that there's a payoff for all of this work that you're putting in, and you
don't have to finish things for them to be worthwhile to share.
So these things together, when viewed from outside the JavaScript community, welcome
people in a positive fashion.
Seeing Tweets like this fosters good will towards our community and could spark people's
interest in learning JavaScript.
So seeing Tweets like this is great for users who are new to JavaScript.
But it's also nice for people who are already members.
It helps everyone feel more comfortable about using JavaScript and being associated with
our community.
Just as a side note, it's often not possible for people in minority groups to post things
like this.
They can be seen as less capable and less experienced even if they're an expert, and
it's potentially damaging to their job opportunities.
So those of you in positions of privilege, please use that privilege� so many Ps�
to make this communication style the norm.
Next up we have negative welcoming.
I have made this pull request.
How about this for the photo?
My friend has commented on it.
LOL, so gross.
This might be an injoke, we know it's sarcasm.
But for those not in the sarcasm club, it might look mean.
It's actually a joke, right?
No, it's not it makes it look like when someone makes a pull request, we're going to make
light of their efforts and could be alienating to existing team members as well as newcomers.
Could entirely scare off external potential contributors.
Negative welcoming like this and other hazing confronts new members with their short comings.
Imagine seeing this when you just starting using JavaScript and you thought this PR looks
great.
If they're saying this about this code, what are they going to say about mine?
That's discouraging.
Next up we have learnerfocused strategies.
And start off with legitimation.
This is telling learners and members that the things that they have been working on
are legitimate.
So being encouraging to people working in JavaScript or on a particular project.
It's kind of like positive reinforcement.
So it's hard to be in the JavaScript community if no one recognizes the work you're doing
as an appropriate use of JavaScript.
For example, a colleague post this is pull request.
Updates to the new sign in page.
And I have gone into cool� thumbs up.
At first glance, this is friendly and supportive.
But what if we took this a step forward with something like this.
Nice use of props, you're really getting the hang of React.
This is not much longer, but conveys the same message as the previous comment.
But makes it so clear to the author of the pull request that the work they have done
is a good use of the language they are working in.
And use this strategy if they tried a new approach to a problem that didn't work out
or a pull request that's not going to be merged.
These scenarios should not delegitimatize the work that's done.
Make sure that the authors still feel good about working with java script just by changing
how we talk about.
This leads into our next strategy, normalizing failure.
So failing to complete a task shouldn't reflect on you personally or your coding ability.
We all know that writing java script is hard and we're not perfect all the time.
We need to make sure that our juniors and people outside our community know this as
well, as well as our existing members.
For example, I've personally been trying to stop using the words "easy" and" Simple" in
documentation we write.
We have some setup introductions.
My setup instructions.
Get set up with the short and easy instructions.
Spin up the Docker container, run tests, run build, party.
We have both the words "Easy" and" Simple" here.
These are fine if you know how to do all the steps and they run smoothly.
But if you don't know how to use Docker or anything goes wrong, we have undercut the
user's confidence by telling them it's easy.
By adding a few extra bits to the instructions, we could make people more comfortable with
not succeeding on their first shot.
So let's add more to the introduction.
The steps below will help you set up the project.
If you run into trouble, check out our FAQs or ask a question in Slack.
We have removed the word, easy, which is a great start.
And by mentioning that you may need help, we are immediately noticing the possibility
of failing to set this up.
So we can make a list of instructions better too.
Spin up a Docker container, run test.
Build the code with npm run build.
So by removing the word "Simply" from the first step, we have changed the expectations
how difficult this task is going to be.
And by removing the links we have removed the frankly unreasonable assumption that you
know what you're doing and don't need to look anything up.
So these two learnerfocused strategies, legitimization and normalizing failure work together to make
it easier to persevere when we are faced with problems we don't know how to solve.
Next up is selfefficacy, which is about supporting the belief to succeed.
The first study in 2012, their coding abilities learning how to program.
If they didn't believe in their own ability and succeed and successfully write code, even
if nay made a lot of mistakes along the way, both their performance and their mental well-being
decreased dramatically.
One of the major takeaways from the study was that if students have much higher ratio
of successes to failures when they're first learning, they're much more likely to develop
resilience and positive selfefficacy.
So we can take that suggestion and apply it to our community.
When people are learning JavaScript, help them have a good time with it.
If your project or team has new contributors, start tagging your tasks even if you know
it's something you're working on.
So lots of projects use tags on their issues and usually look like this.
Here we have an issue.
Update team photos to use team module.
Three tags, frontend, new contributor� and they flag things appropriately for those starting
out.
But I think we can do one better.
What if we were tagging with more useful and less� reaction like these� React only,
selfcontained and documented.
These provide even more information.
And they're not tying in people who have contributed.
Juniors can identify this is a task they're capable of and provides all of the pertinent
knowledge straight up, rather than having to wade through an issue description.
It tells you it that's React, so you know you won't suddenly find yourself waiting for
a C library.
And adding that it's documented lets contributors know there's help available.
So having� busy work junior task, which to be quite honest I hated being assign when
had I was a junior.
And the legitimate useful work that it is.
And it is much more appealing for developers at other stages of their career.
As a senior developer, you don't want to be rearchitecting parts of your code, or shaving
yaks while looking at complex bugs.
Sometimes you need small tasks that are well documented.
The last strategy I'm going to talk about is legitimate peripheral participation.
This one I'm particularly passionate about, so it gets rockets.
So this is about ways that you can participate in the JavaScript community that aren't writing
code.
But are still important parts of being a member.
Things like uploading stack questions and answers.
Or asking and answering yourself.
Tweeting about new thing was done or challenges you are facing.
Making these activities just as important as writing code makes our community easier
to join.
And it's easier to be a part of for existing members.
Writing code is a cool part of our community, having other activities be equally important
is way more fun and provides us all with legitimate ways to engage when we can't or don't want
to be writing code.
So finally, we've got a communityfocused strategies.
First one I'll talk about is active participation.
This is about encouraging people to do communication well.
And we don't get awesome communities without people interacting with each other.
So even though this is called active participation, it covers activities like reading blog posts
or looking at things on stack overflow, as well as obviously active things like talking
to other developers and attending meetups.
Everyone here has take a great step for this one by attending this conference.
And now you can all take it a step further.
Tell the people that you meet what you're working on.
Even if you don't think it's particularly exciting.
Or if you're willing to really commit to improving your community, tell people what you're struggling
with.
You might find yourself talking to someone who has that exact same niche web compact
con fig bug and can help you fix it.
For next up, strategies for getting help.
Defining how people can find help relating to your project.
Applies to internal projects as well as open source ones.
Rather than just listing the names of the maintainers and assuming people can get in
touch with you, have a go at figuring out ways that users or team members can get help.
We want to define as much as we can so people are comfortable trying to help themselves.
If that doesn't work, they're also comfortable asking other people for help.
This can be scary.
It's a bit like booking your own doctor�s appointment and talking to people on the phone
is not a good time.
But it's vastly improved if you know what you should say and what to say it.
In the same way, asking for help with JavaScript can be much less difficult if you know there
are steps you can follow.
So add more to the read me.
We can add sections for debugging.
Maybe different parts of your project have different debugging strategies.
Like installation versus rung tests.
You can add an FAQ.
If you have community support, like Slack groups or local meetups.
And tell them where to ask questions.
So other places that people can go to ask question it is they can't sort is out for
themselves.
So where to ask questions is really a whole point of its own and leads me to my final
communityfocused strategy, support structures.
These are really vital.
There are so many different places you can get help in the JavaScript community.
There are thousands of online tutorials, meetups, Twitter, conferences, GitHub issues, Slack
groups, and so many more.
But we need to let people know where to go and that it's okay to do so.
So JavaScript already does this pretty well.
We encourage people to talk about things that have gone badly as well as the ones that have
worked.
But we can set an even better example for our newcomers by posting about things we have
learned at every level.
So doesn't just have to be junior developers writing about their first experience with
JavaScript.
Or senior developers talking about superadvanced and deep technical concepts.
It's how you have been working with JavaScript for five years and set up your first express
server the other day.
Or finally looked up what that actually means.
Opening up the conversation at all levels combines and creates the support for all levels
no matter where they are in the JavaScript journey.
So let's recap.
Socialization is all the things that we do to become members of a new community.
And all the things that I talk about today are used all the time in natural language
learning and really effective at building language communities.
They're all things that we can start using in our programming communities.
So let's start thinking about the language that we're using when we interact with our
fellow developers, when we're training new team members, when friends ask about JavaScript
or start using it for the first time.
And especially when we post on the Internet about JavaScript.
By thinking about the language we use when we talk about JavaScript, each of us can make
our community a friendlier, more welcoming place for new people and new ideas.
Thanks.
[ Applause ] >> Thanks Harriet.
I think we're going to take a short break here as we have a few minutes before we sync
up with the next session at 4:30.
Thanks.