WTF Does 'Run' Mean?
And Other Adventures in Helping Someone Learn to Code
- Suzie Grange
>> Hello.
There we go.
Welcome back everyone!
Again, I'm sorry about the snacks.
[laughter]
So our next speaker, Suzie Grange, and Suzie is going to talk to us about what it's like
to teach a friend to code in 2019.
Suzie, although she is an interesting person, she couldn't come up with any fun facts on
her own, however, I have pulled a couple out of her.
So Suzie is a musician as you will learn about in the talk and she came to New York in order
to found a startup that has like a really, really cool mission to help improve women's
health care which is a topic that is really near and dear to my heart, because I'm a woman
and she went came to New York she said I'll leave all that band stuff behind and she quickly
discovered that she was wrong and she needs to make music and now she's making music again
and she's going to tell us about that in her talk.
So let's all give it up for Suzie.
>> Thank you.
All right, hi, everybody, Day 3, JSConf, we made it.
Thank you for coming to my talk.
So this is actually my first talk so please excuse my verbal typos.
So I want to kick things off with a quick show of hands.
I say this but I can't really see y'all because it's kind of bright up here.
So here was once a junior engineer.
Trick question, friends.
And who considers themselves still to be a junior engineer right now.
Cool, well, you're in the right place and who considers themselves to be a senior engineer?
Cool.
And who considers themselves someone who knows everything there is to know about software
development?
[laughter] Oh, I saw one hand.
! Well, yeah, junior folks, as you can see from that, if you feel like you don't know
enough right now, rest assured that you probably never will, so yay for that.
So and what unites us all is that we all have to start somewhere, but that can be different
places.
Maybe you knew from the minute that you had a family PC that you knew you wanted to code.
You knew you wanted to manipulate this machine or maybe inspired by customizing your my space
profile or maybe you did computer science as a degree.
Wherever we came from, we all ended up in this crazy journey.
So last summer my friend James decided to join us and he took the brave decision to
career change to become an engineer.
So me being a mostly decent human being, I offered to help, I mean how hard can it be
in 2019 with the finest Google search results and videos and courses online?
Well, spoiler, it was hard.
Way harder than I thought or I think he even thought, to be honest.
So today I want to share ten things that I learned as I followed James on his coding
adventure.
My name is Suzie.
My pronouns are she/her, I am British, not Australian, so congrats for those of you who
guessed that in the guess the accent sweep stakes and I work on the front-end tech lead
at Maven clinic in New York City.
We partner with employers to support their employees through pregnancy, surrogacy, adoption
and return to work programs.
So that's my shameless plug for now.
Also we're hiring, so if you're interested in either of those things, please come to
talk to me later.
So my path into this is that I was self-taught or I like to call myself an accidental engineer.
See, music was always my thing.
When I picked up guitar at age 12, I kind of knew that was it for me, that was what
I wanted to do, so for the rest of my teens and early 20s, I spent most of my time playing
shows in dodgy dive bars and venues across the UK, but after playing my first show, I
think I was 14 or something, I was backing in the glory of success, I thought that the
this is the late '90s and early 20000, and I had no shortage of I inspiration.
The web was full of fonts, and let's face it questionable design choice, they were great
times.
So armed with cutting edge tools and zero experience I drag and dropped my way to creating
my first website.
But then what?
I had this thing on my computer and I knew I had to somehow get that onto the interwebs.
I heard that hosting was a thing, so I got some low-cost hosting, I think and I emailed
my band's email list and I asked if anyone knew any FTP sites.
With no skills, I had become a freaking webmaster.
It was good times.
So sadly, archive.org didn't start until 2001, so my 1999 handiwork is lost to the ether,
but rest assured it looked pretty great.
This is all that remains of it.
Eventually I graduated from publisher to front page and then definitely very illegally obtained
of DreamWeaver.
Tables and frames came and went and CSS came along and allowed me to look pretty.
But still for me coding was a hobby.
It wasn't a career if you had to do a career in computer science, you had to go and do
a degree in computer science, right, that's how it works?
So fast forward, I did a degree in music technology, I worked in retouching for a bit, I worked
in IT support for a bit.
I had something of a mid-20s crisis trying to figure out what I was doing with my life
in which I considered everything from being a lawyer to a teacher to a social worker and
then I heard about this startup scene thing that was happening in the US and that kind
of sounded like being in a band to me.
You know, it's you and a bunch of people and you're creating this product that you're trying
to put out into the world in order to be successful and famous and happy or something so I figured
maybe I don't need a degree to do this.
So I decided to learn to code properly.
So I read some books, I built some bad PHP apps and I badgered some people on Twitter
until thankfully someone gave me a chance and gave me a code.
So I taught myself Ruby, discovered SVN and git and I taught myself JavaScript and here
I am today, giving my first talk at the biggest conference in our industry, so that's weird.
[applause]
Thank you.
So just to recap, the things that I needed to do in order to become an accidental junior
developer, I pretty much needed to know HTML, some dodgy inline styles, I needed to know
how to use an FTP client and a generous smattering of GIFs, obviously.
So accidentally becoming a developer wasn't really that uncommon back then.
Maybe as I said earlier, people started tinkering on MySpace profiles or maybe.
Interactivity was pretty much copy and pasting a Java applet or maybe a Marquee if you were
particularly creative.
So here we are in 2019, meet my friend James.
We actually made music together.
But that's a story for another time.
But he had a real job in construction so he was basically building skyscrapers and swinging
off bridges and doing you know, real work but he also produced videos and animations
and sound design video games, so a talented guy in general.
So last summer he decided he wanted to learn to code.
So me being self-taught and having mostly learned through a baptism of fire was OK,
how hard can it be?
What do you need to know.
And to recap I got my first job knowing HTML, CSS, really bad PHP and that was kind of it.
Source control?
I probably thought that was a foodstuff.
So this is what it turns out James had to learn.
So he got the classics of HTML and CSS but in addition to that you have to know about
Sass and Less and CSS in JS and how to fight in Twitter about CSS in JS, JavaScript, obviously,
React and Angular and Vue and whatever the cool kids are using right now and let's face
it there have probably been 3 JavaScript frames come out in the time that it's got me to this
time in my talk.
Git, and databases and APIs and be a good citizen of the web and accessibility.
If you want to get an interview, you into need to know about algorithm data structures,
cross-browser testing and whatever everyone is talking about in Hacker News this week,
too.
So that brings me to thing No. 1 on my list and that that is is that the barrier for entry
is way higher now, like, damn.
So what are some ways folks get into engineering these days?
Well, seeing that you know Matrix star downloading information into your brain is not an option
yet, CS degree.
Fantastic, cost you many bags of money and take you four years but you'll be able to
contribute as a junior engineer pretty early on, or you can do the boot camp path which
will cost you some bags of money and take you 12, 14 weeks and you'll be out being able
to contribute again or you can do my path which was the self taught path, which could
cost you nothing to some amount depending on how much you put into it and it could take
you any amount of time.
Which thinking about these things brought me to thing No. 2 is that coding isn't that
open to all when you think about it.
I'm not sure if you remember the code year initiative that happened I think it was around
2012 by things like then-mayor of New York, Bloomberg touted that he was going to learn
coding and if he could learn it anybody could do it.
It's open to all.
Why would you not want to do this.
That's all well and good, but you need to remember that not everyone grows up access
to a computer.
Not everyone can spend 12 to 20K on tuition fees plus living expenses and loss of earnings.
Not everyone is able to work a job or two or three and spend their time outside of work
learning to code.
There are some great initiatives out there, there are loans out there, but it's still
a huge commitment and there's no guarantee of how soon, if at all, you'll get a job.
So nevertheless, James chose the boot camp path and why would you not?
It promises a pretty amazing return on investment.
It if you go from zero to being a developer in 12 weeks, you can according to some of
these boot campsites have a 70X salary increase.
Sox of them even have money-back guarantees.
But again to get into top-tier boot camps a lot of them require you to have a lot of
knowledge in order to get into a camp that teaches you to learn code.
So that was weird.
So his school gave a few resources there but he decided he wanted to do a thorough job
and figure out how he could best learn with the resources available to him.
Which brings me to thing 3 is there are so many resources out there.
When I started there was books and trying things and failing and that was kind of it.
But now there's so many things out there, which is great, right?
There are so many choices but how do you know which one is best for you?
How do you know which learning style is best for you?
Where should you start?
Should you pay for one?
Trying to figure out where these things start and which one works for you.
Nevertheless, James started with Code Academy.
It's a great browser-based IDE which gives you hints.
It's really cool.
So his boot camp was going to involve Ruby.
So he did some code academy resources, eventually he could write methods and he could do simple
algorithms in his browser.
He could Fibonacci, he could do Fizzbuzz, awesome, so I was feeling like a mental bad
JavaScript.
So I decided it would be a good idea for him to install Ruby locally.
He went on this site and it had a bunch of commands with a dollar sign in front.
What even is that?
So I replied oh, yeah, that just means you have to run those in your terminal, simple.
So he was like, yeah, but what does that even mean?
What even is run?
So for some reason that question hit me, not because I couldn't tell him to open up the
terminal app to copy and paste that website and hit return and that would do what he wanted
but I guess at that point I realized how much learning to code involved.
Short of run something you were just telling but even then, what does the dollar sign mean
and how do I explain those two fairly simple seeming things without explaining kind of
everything in computer science so at that point it dawned on me that this journey he
was about to take was huge.
He conquered Fizzbuzz and algorithms but he didn't know how that runs on a server or even
what a server was, all of these things that I, as I turns out kind of had forgotten were
not part of the common vernacular for nondevelopers.
Which brings me to point 4.
Coding is kind of this giant game of joining the dots, but you don't know what the dots
are, and as soon as you join one dot, another 1 or 3 or 12 more start coming into view.
Now, computer folks, this is not, you've got those fundamentals kind of down, but for boot
stamp and self taught folks, sometimes we skim over those things in order to get productive
fast and then we catch up later.
So for James he understood about running code in the computer versus server, he knew what
HTML was, we noticed some other ones, like what's an API, what's a database, all things
that I had taken for granted as things everyone would have some knowledge of which it turns
out they don't.
He learned a bunch of Ruby and he passed the entrance exam for his boot camp of choice.
Complete, awesome, but as it turns out, more knowledge means more questions.
He went through the bootcamp and we continued to meet up when he wanted help with something.
He built some Ruby apps and moved to JavaScript and eventually build full-stack Rails and
React.
But the more you learn, the more questions arise.
Ah, console errors.
These can be useful for 70% of the time but for a new developer this seemingly never-ending
stream of scary red text can feel meaningless.
I'm pretty sure everyone in this room has Googled that at some point.
So what next?
Over to Google, right?
And then you get met with a casual 15 million results and within those results, a plethora
of probably passive-aggressive StackOverflow answers to sift through.
Always fun.
And that's if you know what the issue is and if you don't know what the issue is, how do
you know what to Google?
And even if you do, how to you phrase the question in order to get the search results
you need?
Early on, James had been prepending his searches with JScript thinking it was short for JavaScript
which returned some pretty short results.
And in the interest of googling: React class, it's pretty huge in terms of the relevancy
of your results and that's if you have a stack trace to begin with.
I guess I'd kind of taken for granted how second nature it had become for me to just
search things and usually get the right answer and how to debug things when issues arose,
learning to code is as much about learning to debug as it is about writing code in the
first place, as it turns out.
So James learned about debugging and built some frankly impressive apps for someone who
only to code a few weeks ago.
So his school set out some guidelines as to what to do, to begin with the good chance
of getting a new job.
One of those guidelines was to apply to 50 jobs a week.
Five-zero jobs a week, that's kind of a lot.
In addition to that he had to study algorithm, create new projects, work on technical interview
skills, work on general interview skills, things like a life had to factor in there,
work on his resume, and practice whiteboarding.
If you're lucky, you get to do code challenges and prep for interviews.
But still it's a lot of stuff.
And all of that is exactly because competition is so fierce right now.
There was 20,000 boot camp grads in 2018 and no doubt more than that in 2019, something
like 65,000 computer science grads and how many self-taught folks common to the market
each year, which is great because in the USA there are plenty of software jobs out there
but the problem is there are very few junior ones, and the one that is do hire aren't always
that great at supporting their junior developers.
I have a friend who ended up quitting because she got so little support, they just didn't
give her any training, they kind of metaphorically threw her into a swimming pool and told her
to learn how to swim.
So unsurprisingly she left that place and now is spending a bunch of money to getting
a computer science masters because she didn't get the support that should have given it
to her.
So sadly No. 7, the potential for burnout starts early.
So I've definitely experienced burn outmyself.
I guess it's a combination of working in a high-pressure startup environment, working
fast, always shipping and making sure that the company stayed together, it was kind of
inevitable and as someone who thrives on being hyperproductive all the time, I really hated
feeling that way and I wouldn't wish it on anyone.
Quick recap: Burnout is defined by the WHO as feelings of energy depletion or exhaustion,
increased mental distance from one's job or feelings of negativism or sin nix related
to one's job, and reduced professional efficacy.
So James towards the end of his bootcamp was definitely walking on a tightrope but he definitely
came close and that was really sad for me to see and I guess that's not surprising.
Boot camps require something like 80-plus hours a week of study.
Plus the pressure if you failed the exam, you could leave with debt and no job to show
for it and if you're someone like James who didn't go to University and never sat for
exams, doing an exam and having to go into intensive study in order to not get kicked
out of boot that was intense.
Thankfully he came through it, but plenty of people don't.
Even once he gets a job, the prospects on that job weren't great.
A 2018 survey asked close to 11.5 thousand tech employees if they felt burned out and
60% of them did.
The best company on that list, Netflix, had 40%.
So the pressure of this environment and keeping up with the fast-moving field of engineering
takes his toll.
Which brings me to thing 8, resiliency is so important.
James survived his boot camp brush with burnout.
And now he has to make but the reality is pretty far from that and that can
be a pretty demoralizing wakeup call, but it's not just the job hunt that needs strength.
Being an engineer means keeping up with this constant sea of changes and that can be pretty
exhausting and James got his first taste of this very early on.
He'd learned about object oriented programming and then React.
And then along came React 16.8 and sorry, kids, now hooks is the thing, forget about
classes, you don't need them anymore.
So before he'd even graduated, the thing that he'd learned was the right way of doing things
was no longer the right way of doing things, which kind of sucks, coding is really this
career-long marathon and boy had you better be ready to change your route, running shoes
and technique continually for the rest of your race and the rest of your career.
So OK, that all sounds kind of doom and gloom, but I guess thing No. 9 was the thing that
surprised me the most and that's helping someone learn to code is really great with helping
with Imposter Syndrome.
Now because of that constant struggle to keep up with what was going on in our industry
or perhaps because I'm self-taught or because I'm a naturally anxious person.
In fact when I first suggested to James that I help him to code I was secretly terrified.
What if this exposed me as not knowing anything?
So a quick refresher on Imposter Syndrome.
David did a great talk on this yesterday so if you didn't see that, I would definitely
recommend watching it on YouTube.
So good job, David, but Imposter Syndrome is referred to as a psychological pattern
in which an individual doubts their accomplishments and has a persistent internalized fear of
being exposed as a fraud.
I constantly feel like someday I'm going to be handed a challenge that I can't solve and
I'll be exposed as this fraud that I think I am.
In spite of the fact that 10 years professionally and many years as a hobby that's not actually
happened.
Throughout my career I've definitely downplayed my achievements.
For fear if I was going to say I'm really good at this, someone would say, prove it.
And I know it sounds ridiculous but it's kind of a pattern that I've been in for a while
and I know I'm not alone in that.
So I knew if I was going to be any use to James at all I was going to have to confront
some demons about what I did know and what I didn't.
So that was pretty scary.
When teaching myself code I felt I had to move past some basics to prove that I was
employable and productive and basically to get hired.
So being a pretty methodical person I decided to make a list of all the things that I knew
or thought I knew or felt I needed to know a bit more about.
If I came across something that I wanted to dive in on more, I did.
It turns out, for the most part, I knew way more than I thought I did.
As I went through my list studying things and figuring out what I was maybe a bit fuzzy
on and checking things off that I actually found out I was good at, I started to feel
better.
Some of that gnawing feeling started to subside and it occurred to me that I maybe wasn't
entirely a fraud.
Being at a startup I kind of had to prioritize shipping things rather than learning things
that weren't definitely related to my job.
So that was a bonus, too.
OK, so thing No. 10 is a bit obvious, everyone knows that the even the romance knew that
back in their day, but I guess it never occurred to me quite how impactful it could be.
Another factor is that more than not I'd learned things through reading things on the internet
and basically trying things and breaking things and trying them and breaking them again until
they eventually worked.
I never had to explain to anyone in real life what I was doing, I never had to talk through
a function that I'd written and saying what it did or saying why things didn't work or
exactly what was going on line by line.
But I think doing that really helped me with things like technical communication and explaining
those things really helped me in ways that hadn't really happened before.
And one of the cool things that happened is while James was at boot camp he started teaching
other people.
He'd got handle on something and he told me he would run little impromptu teaching sessions.
So that was really awesome.
OK, I'm getting toward the rest of my talk and I wish I could say that James is living
his dream but the fact is that he's still applying to those 50 jobs a week.
He's had interviews and code challenges but the reality is despite his talents, there
is a numbers game and it's going to take a while.
Now for me as a hiring manager I will admit in the past I've been frustrated by the huge
numbers of new grads applying to mid level jobs that I've posted one the where we specified
three to four years experience but I need to remember that each of these applications
is a human and they've gone through a struggle to get there.
They have to do this in this numbers game that eventually a company will bite.
We as hiring managers we need to hire these folks.
In fact you'll often reduce the velocity of a team at first, but as a saying that a team
of senior developers and no junior developers is just a team of developers.
It's so true.
Hiring junior engineers who are excited and super dedicated to learn will elevate your
team in so many ways.
But to make sure that you have a real training program in place, because they deserve that.
Don't hire them just to do the stuff that you aren't interested in or too bored to do.
So to sum up.
I didn't think that this was going to be anything but beneficial to him, but it turns out that
it helped me face uncomfortable demons and I think made me a better engineer for it.
So whether you've just started to code or whether you've a senior, grizzled, engineer
like me, try teaching someone.
You might be surprised by what you learn.
Thank you.
[applause]