Javascript is for Everyone! by Meya Stephen Kenigbolo | JSConf EU 2019

Subtitles section Play video

That's it!
Now I'm a star.
I'm done!
Thank you.
Okay, today I'm going to be talking about JavaScript is for everyone.
That wasn't supposed to happen!
And also that wasn't supposed to happen!
Okay, hello.
I'm Kenigbolo Stephen, a lead and advocate.
I'm also the community manager for Code Afrique story, and I will tell you about the Code
Afrique story and why JavaScript is for everyone.
You can find me on Twitter.
Please don't ask me how I came about that handle!
It's one of those things I don't really want to talk about!
But, yes.
I work in Finland.
Who knows about Finland?
That's nice.
This audience is way better.
In Finland, we don't smile, so it is do you know about Finland?
That's pretty much it!
I'm going to be talking about JavaScript being for everyone.
This is basically how it's going to go.
I will talk about what Code Afrique is, why we do what we do, an important disclaimer:
you may not like a lot of the things I'm going to say today but I think it's important to
state these things.
There's been a huge dysfunction between teaching JavaScript and getting beginners into the
industry.
I'm going to talk about the team behind Code Afrique.
I'm going to be telling you how we teach JavaScript.
I'm going to tell you about Amber, how the conventions of configuration have changed.
Beginner concepts that we used Ember to do, and a history of where we came from and how
we decided to go with this.
What is Code Afrique?
Nothing fancy, just giving back to the community.
It's a bunch of students, doing a masters in software engineering.
We figured out the problem in Estonia and decided to get together to solve it.
I'm going to tell you what we did.
What do we do, and why do we do what we do?
Who understands what this means?
Okay.
Very few hands.
But this basically explains why I'm giving this talk.
In case you missed it in my previous slide, I used the word "under represented" highlighted
in red for a reason.
I would like to redefine this word.
I see myself as a marginalised person.
In 2015, I was doing a Masters in software engineering?
In Estonia.
We have a lot of people of colour in the country, not so many but a significant number.
The issue was it was difficult to get jobs, right?
There were a lot of people who wanted to get into the tech space and it was difficult to
get in and the reason was we had created this barrier for them, assuming that everyone had
the same cognitive abilities.
This is a bias, a lot of us have.
We don't necessarily do it intentionally, but this is it.
A random question: how many people who make tutorials or teach people think about learning
disabilities like ADHD, for example?
Very few hands.
How many people think about people who are not really able to learn not because they're
not smart enough, but because they didn't have the same privileges that you had?
Do you ever think of that?
How many people here got their first computers before 15?
Okay.
You see these hands?
I never got a computer before 15.
So, what whether I like it or not, I didn't get the advantages that others had.
This is why we came about Code Afrique to actually try to boost that gap and give people
the ability to actually get into the industry without thinking so much.
Yesterday, something happened, and I basically wanted to call out this.
I thought it was important.
I would like to change the narrative of we being under represented.
I quote Brian Lyells when he says you're not under represented before, you're over represented.
I'm sorry, but this is fact.
We are black, indigenous people of colour in IT, and we are supposed to be here.
We're not here as a quota, we are here because we're supposed to be here.
We don't want to use negatives to address ourselves in the industry, we want to be seen
as people managing our lives, not under represented.
Hopefully, I hope that by the end of this talk everything thinks this back and puts
it on the back of their minds.
Would you believe me when I tell you there are a lot of amazing ideas that because it
belongs to a person of colour or a marginalised community?
How many people actually believe this?
It is always difficult when you need to go and talk for funds when you belong to a specific
demographic.
It's not as easy as a lot of people think.
This it is one of the reasons where we decided we want to bring this community to get people
together, people who belong to these under represented groups and then teach them JavaScript
in such a way where they don't need to be so much worried about the toxicity we have
not industry.
They could just come and learn, and afterwards explore.
So, yes, like everyone else, I think we all deserve an equal chance.
It might not be nice, it might not be comfortable for some people, but we all deserve an equal
chance.
I'm not sure about pizza and - I'm a pizza person, so maybe the Americans may not be
so happy but I like pizza more than ... we're a bunch of regular people.
The folks who work at Code Afrique, that's Gabriel.
This is Sunday.
And this is Victor, all senior software engineers.
Two work in Canada and one works in Estonia.
We started Code Afrique together in 2016, and we've been going strong there ever since.
I'm going to give an honourable mention to a friend called Fortuna based in Estonia.
He helped us discover a better way to actually accommodate people when we need to teach JavaScript.
Now, one of the biggest things we found out about JavaScript and getting people into the
industry is the conceptions of pure evil.
One of the preconceptions is that JavaScript is easy.
You can say that when you're not a beginner.
If you've never written a line of code, programming is never as easy as you think, and this is
something I want us to remember when you have to teach people.
The fact that you understand it does not necessarily mean they will understand it the way that
you do.
The fact that you have the ability to assimilate things does not necessarily mean they would
have the ability to assimilate it in the way that you will.
The JavaScript community out here, there is no control of people grasping the concepts.
This is not the fault of JavaScript but down to the fact that people learn differently.
Where we've made the mistake is not taking time to find ways to accommodate the different
type of people who need to learn.
We have been very mainstream in the way we teach JavaScript, and I'm hoping that, as
we go back today to mentor people, those who have junior developers, we take this into
consideration about who we are teaching what the situations might be.
Sometimes, it's not only about learning disabilities, it could be emotional, mental, physical.
Let's always put that into consideration when we need to teach.
Now, JavaScript does not have to be complicated as much as we tend to make it complicated.
I strongly believe it doesn't have to be.
JavaScript is a beautiful language.
I didn't come from a JavaScript background.
I came from a C++ background but of since I got here I don't want to go back because
I love being here.
However, we have created a barrier that makes it difficult for people to come into the industry,
and just before I go, a quick question: how many people here work in front-end development?
Awesome.
That's a lot of hands.
Okay.
This should have been named JSConf front-end!
How many people as front-end engineers have had to traverse a binary tree in their regular
day jobs?
That's very few hands.
I can't even count.
How many have had to use the big notification in the regular jobs and front-end engineers?
Also very few hand.
Now, think about it: why do we need to actually make beginners scared of getting into the
industry by bombarding them with all this information instead of getting them in and
easing them into learning?
Why can't we do that?
Why do we always have to make it so complicated?
So we designed a simple way to actually teach beginners, and it's basically this: because
whether you like it or not, these are the three building blocks of JavaScript.
The moment you can understand these three concepts, it makes it easier for you to go
on and explore different other things.
We basically decided to use the pattern explaining variables and objects and methods going through
this way.
We think it's easier.
It has worked for us and enabled us to get out the 15 students we initially take, get
nine of them into the industry, they're good engineers, they're still young, they still
have a lot of time to improve, but they're learning, and it has shown us that there is
a possibility to actually ease people into the industry without necessarily complicating
the entrants.
We need to think about the different type of people.
We need no to think about the different communities and find a way to get everyone in without
necessarily unintentionally excluding them.
Now, the biggest problem we face when we need to teach people, and this is not - this is
by no means me lashing out at anyone, or any particular thing, I'm just saying the JavaScript
community has grown so big, and something that is supposed to be a huge help for us
has unfortunately turned out to be a problem, and that is that?
This is it.
Yes.
And, again, pretty much frameworks.
Frameworks was supposed to make software development easy.
Frameworks were basically - we started building frameworks to enable people become productive
easier.
Unfortunately, we have started making frameworks that by making it more complicated for people
to get in, and this is now not a lash-out to anyone or framework.
In my team, we use four different JavaScript frameworks for different projects.
Every one has its pros and cons.
I think that it's important that when we build this, and even when we make tutorials, we
take into consideration the different type of people that need to learn.
Now, I like Ember, and I'm going to make a disclaimer: I am not sure I'm not connected
to Ember.
I'm only speaking it in the context of how we use them by giving people simple instructions.
There's something very controversial about Ember.
I wouldn't say controversial but a diverse opinion.
It's a convention over configuration.
A lot of people feel that this is not so good.
And that's not justified.
They have their reasons.
A lot of people do believe that conventional over configuration is quite important, and
they have their reasons.
Now, starting in Code Afrique, we actually went ahead to teach people in terms of the
different things that we needed to show them.
What we discovered was that it was easier to actually use Ember because we could give
them a set of instructions to follow.
One of the most important things you enjoyed as a beginner was writing the line of code
and seeing it work.
We gave them an opportunity to see their work progress, enjoy that excitement, and then
go on to dig deeper behind the basics, why this works the way it works, with , instead
of working in the reverse pattern.
So typical pit stalls we encountered with trying to use frameworks.
Lazy-loading.
Too many computer science concepts that is front-end development.
It doesn't have to be so complicated.
Come on.
Some frameworks seemed to be front-end frameworks designed for back-end developers.
A lot of people here can agree with that, I'm pretty sure we've all seen it.
You probably know what I'm talking about.
Yes, and then some things aren't designed for beginners, it's true.
As much as we would like to say it is, it's just not designed for beginners.
It's not beginner-friendly.
There are tons of other things but I will skip that and talk about the basic ones.
At this point, I'm going to play a nice video.
Hopefully, the musical part is actually removed.
This was a video made by one of our students and I promised him I was going to play here.
>> Thank you.
God bless America.
[Applause].
>> It's a representation of how the different technologies and frameworks.
[Video]: "Nice to meet you.
What's up, Graham.
You know this.
Heath Williamson.
Nice to meet you, sir.
Come on.
Come on.
Emily George.
How are you doing?
All right.
Never forget about that.
That's all we got.
Nice to meet you.
All right.
Oh, bring it in!
Starting from the bottom now we are here.
Nice to meet you.
All right.
All right.
Nice to meet you.
One - bring it in there.
[Voices overspeaking].
Nice to meet you.
My goodness.
Look at this.
Oh.
She is so beautiful.
Mmm.
I want another one.
There you go.
Precious.
Beautiful.
Beautiful.
What's her name?
This is Libia Roogie.
Come on, there he is!
All right, very good to meet you.
Here we go.
[Laughter].
" >> Okay, so I'm just going to round up.
That was pretty much it.
I would say a big thank you to all the people who work with Ember guides, teaching Ember
and JS has been amazing because of the way the documentation is designed.
A huge shout-out to your communities.
The documentations are totally amazing and they make teaching easy for us.
Routers, and this is no beef against any framework, but not having to teach people about routing,
not having to tell people listen, I need you to go and install this particular framework
router to get started helps us a lot because it eliminates the need for people to worry
about that.
When they want to learn about routers is doing it in their own time.
They want to get productive and learn code.
Handle - data binding.
We can't actually teach data-binding without teaching data-binding.
Basically, they can get productive and understand it and when they want to dig deeper, they
have a better overview of what data binding should be and how it should work.
Lastly, convention.
We all have different ideas about convention, but as someone who has taught Ruby on Rails,
and em-R Ember, I think for beginners, it's important to give learners a set of guidelines
to use and work in.
Just I'm going to show a couple of little things.
So this is pretty much lazy-loading in Ember.js.
This is how straightforward it was.
I only need to explain what Lazy Loading is and show them is.
No disrespect to Angular, if I want to do this in Angular, it's not so straightforward.
This is one of the issues we face.
You need to make sure you can go into a lot of core concepts.
Going into a lot of core concepts for people you're trying to get into the industry might
just be a way to chase them away.
So using simpler methods, using this kind of method, and using convention over configuration,
we can do this and show it to to them better.
I hope a lot of frameworks will make it easier for people getting into the industry.
This is a simple routing function in Ember.js.
This is a simple explanation.
This is all I need to tell the student that how the routing itself would work, and this
would make logical sense because it follows systematically the way it will flow.
Lastly, this is a code written by someone who learned JavaScript for four days.
He literally just learned objects, variables, and functions, and then he came up with this.
I promised him I was going to put this up there because four days in, I couldn't write
this.
Somehow, we are actually doing something right, and I'm hoping as we go back, we learn to
actually help people learn properly.
Moving forward, we've run the code to reload.
We still have Code Afrique as an online version and Reload is a boot camp for people who identify
as marginalised groups.
You can find us on Twitter.
If you would like to be a mentor to some of our students, we would love that.
And many thanks to the following organisations.
The Association of African Students in Estonia.
They gave us to the - and the Talin Institute of Technology.
Our classrooms are located in the institute, and a huge thanks to my company.
I'm paid to be a developer-advocate that doesn't need to come and talk about ... but I - our
huge thanks to them.
Lastly, I wanted to mention about mentoring, because this is also a fundamental part of
JavaScript that we have actually forgotten.
Now, a huge shout out to the node.js community.
They have an awesome mentoring system.
It does have a little flaw and hopefully sometime I'm going to bring that up when I can, but
I just wanted to point out that if you know you mentor anyone, if you know you're a senior
engineer and you have junior engineers in your team, mentoring is not good enough.
You need to open them to your network.
You need to give them opportunities.
It's wanting to say yes, I'm a teacher, I have four mentees.
How many are working?
It's important that we keep this at the back of our mind when we teach.
It's another thing to pass knowledge and another thing to give people confidence.
While you mentor people, giving them opportunities.
I used to be at fault for this because I have seven meant yes, sir - what was I missing?
On linked linked, if I see a job, I - if - I can say all seven are working today.
One will be a senior engineer, he's just within three years be he is smart because he has
a CSS background.
It's important that we open up people to our networks.
I'm highlighting the mentees that we have at Code Afrique because they came from a very
different background.
He's a journalist, and when I look down there, he actually also doesn't have a CS degree.
She started studying marketing, but they're all engineers now, and we're really proud
of what they do.
I hope we can encourage people to get into tech this way.
Lastly, I'm going to point this: who has had this raised before? - who has heard this phrase
before?
What this means is that it is all about sharing what has been bothering you for a long time.
Mostly things that, you know, you usually don't have anyone to talk about, but you would
like to talk about it.
The reason why I do this is because every time I come to a conference, I have students
who are back home listening, and I want the experienced developers here to please go on
Twitter and talk about your most vulnerable times, talk about those things that you can't
remember.
You can go on Twitter, for example, every single time I need to Google how to use the
reduce function because despite the fact I've been programming for over five years, I don't
seem to grab it.
I have to check out the reduce function.
When you say this to young people, it doesn't matter the age, but people who are young in
the industry.
You give them some sort of confidence and let them know we're not all Superman.
Everyone makes mistakes and has a part they're not comfortable with.
I want you please to share your stories.
I'm going to go on Twitter quickly and post this.
So please indulge me.
I prepared this tweet just ahead of time.
You can go on the there and write the themes that you consider to be the most vulnerable
things as a senior developer, what things do you forget regularly?
As a senior developer, no matter how much I think I know, I really don't know shit,
unfortunately, because, when I went to EmberConf I sat with Yehuda who was a role model for
me, when he started to contribute - I realised, like, oh, boy, I have a long way to go, you
know?
So please share your stories with them, and encourage them and make them understand that
it's okay to make mistakes.
We all make mistakes regardless of how many years experience we have not industry, everyone
makes mistakes and you can learn from them and be better.
I started going back.
And with that, I say thank you.
You can find me on GitHub, and Twitter, and you can send me an email.
The word you see there is the one thing I want you to learn about Finland today - how
we say thank you.
Thank you very much!
[Cheering and applause].