Learn to Code episode transcript

2019-06-28 Learn to Code_complete.mp3 transcript powered by Sonix—the best audio to text transcription service

2019-06-28 Learn to Code_complete.mp3 was automatically transcribed by Sonix with the latest audio-to-text algorithms. This transcript may contain errors. Sonix is the best way to convert your audio to text in 2019.

Tyler:
So you want to be a web developer. What's the one thing you better be able to do before the interview. That's right. Code. Welcome to Manager J.S..

Tyler:
Given how important coding is and how frequently I have to give this guidance to candidates. I felt I had to start this season of Manager J.S. with this cast on learning to code.

Tyler:
I've got other casts in production but if you only hear and heed one of my casts this is the one. But of course keep listening. The rest are going to be wonderful. But I'm surprised how often I have to coach people on this. It's part of the job title and yet so many candidates don't come ready to code.

Tyler:
For my part the word developer in web developer means coding it means programming.

Sound Effect: Road Noise

Tyler:
Like I said I give this guidance all the time but this cast has been hard for me to write. Like a half heard song it got stuck in my mind for days.

Tyler:
One day on the way to work I recorded a 20 minute voice memo trying to pour out all that seems important to me on this topic. But when I was reviewing the memo I realized that it actually had the basis for several casts in it. It kept spinning out on other trains of thought related to the entire job interview process but not just how to learn to code. So I'll cover some of that other material in future podcasts but I still needed to focus in on just how do you learn to code. Something that basic.

Tyler:
I realized that I had to take another approach. So I switched how I was getting to work. I moved to mass transit and instead of thinking out loud I tried writing down my thoughts.

Sound Effect: Trax train accelerating

Tyler:
It was actually really helpful. I could finally start separating out some of the secondary subjects from the primary concern: How good do I have to be at coding before I start interviewing and how do I get that good.

Tyler:
Well, here's the first headline: You do need to be a coder to get a coding job. As obvious as it may seem, many candidates don't realize they need to be able to code before the interview. But I can understand. I can imagine them thinking the internship is where they will learn to code. Maybe it is elsewhere. Maybe other places in their coding internships they're taking people off the street that don't know anything about how to code. But almost all of the interns I hire have already been paid to write code somewhere else before we hire them.

Effect: Spoken as if on the phone

Second Person Tyler:
Ok. Tyler I get it. I have to be able to code but how am I supposed to get experience coding if you won't hire me without coding experience.

Tyler:
If you haven't had a job coding it's going to be OK. You just need to bootstrap yourself. Once you've got that first real coding job, your growth is going to explode. You just need to get good enough for the first real job.

Effect: Spoken as if on the phone

Second Person Tyler:
Alrighty then. You mean getting certifications and taking classes. I'll go to school or a boot camp and then I'll be able to code.

Tyler:
Not entirely. I've met plenty of seniors in college or graduates from boot camps that still couldn't do well enough in the interview to become an intern which is heartbreaking. There's more to it. So right up front here's how I recommend you prepare yourself to code during your interview. These are the headlines and they're in priority order — most important idea first.

Tyler:
Number one: Write everyday code every day.

Tyler:
Number two: study theory and opinion.

Tyler:
3. Be prepared to demonstrate skill.

Tyler:
And number four: Optional! Optionally, you can study tricky code.

Tyler:
In a moment I'll explore each of those ideas in greater depth.

Transition Music.

Tyler:
Sometimes you come across something so helpful that you wish you'd heard about it years earlier. And sometimes you have that annoying friend that tells you all about those kinds of things without prompting or cause. And I'd like to be that annoying friend for a moment. It's time for unsolicited endorsements and reviews.

Tyler:
Uh, Wait actually I have a jingle for that:.

SUNG

USER Jingle:
Un-Solicited Endorsements and Reviews!

Tyler:
That's right. It's time for me to tell you about something special to me without anyone asking me to. And today I'm talking about this.

SOUND: Pages being thumbed rapidly.

Tyler:
Yeah that's right. That is the sound of a big, thick, tech book that I'm never going to consult again because it covers an obsolete technology. In this case it's Expect. Which, you probably don't know about. But as the title says: a TCL based toolkit for automating interactive programs. Yeah for a laugh. You can look that up. It was a while ago I used that.

Tyler:
An obsolete hard copy book is one of the saddest things. And a library full of them? Forget about it. The first personal monument to antiquated knowledge that I came across was in my first married ward. I served a proselytizing mission for the Church of Jesus Christ of Latter-day Saints, came home in 2001. And by 2003 I was a young married college student, several years into an engineering degree. And about this time I was asked to help an unemployed programmer in our congregation (or ward) with some cleanup around his house.

Tyler:
I heard something about a bubble that burst a couple of years earlier. And apparently bubbles can make you unemployed when they pop. So when I went down to this guy's basement, at first I was impressed. There were shelves and shelves of books on programming. Then I realized one after another they covered old versions. So much invested in his library and now they weren't resources. They were just trophies or maybe even just boat anchors or millstones depending on how you think about it.

Tyler:
And here's what I've learned: Some books will always bring you pleasure to peruse and reread and some just can't. That's why I don't buy technology books anymore. Or at least not the ones that cover a specific tool or version of a changing language. I rent my technology books with a subscription to Safari Books Online. It's from O'Reilly. And they're that book company that's always publishing new technology books but with covers that look like antique engravings of animals and people in cultural dress. I love their books but I know I'm never going to open a book for Java 6 once Java 8 is out.

Tyler:
Make use of online libraries. That's my suggestion to you. Your school might have some. The ACM provides access to a selection of Safari Books Online with your membership and a student membership is particularly affordable. Even if you're not a student anymore I recommend that you find a budget to pay for that membership because it has a lot of resources. There are other services that provide access to books like books 24×7 but Safari is my favorite largely because it's O'Reilley. And I just really like O'Reilly.

Tyler:
And if you do buy a tech book, like I do sometimes when Manning has an irresistible title, get it in e-book form. Much better for it to take an inconsequential amount of space in your Dropbox account than taunt you, night after night from the bookshelf in your bedroom, or office, or unfinished basement.

Tyler:
So thank you for letting me get that out of my system and listening to this segment of.

SUNG

USER Jingle:
Un-Solicited Endorsements and Reviews.

Tyler:
Ok the first two ideas (write everyday code everyday and study theory and opinion) are the most worth following because they don't just help you get the job they help prepare you to do the job.

Tyler:
The last idea might help you do the job but it mostly just helps you do well in job interviews and at parties. Well coding parties I guess. Or at reviews. Uh, at conferences where there's other people that will nerd out about how to solve some complex coding issue but most of those challenge problems don't really help you do your job better. But if you are in an interview that requires you to solve one you'll be happy that you're prepared.

Tyler:
So let's cover the first idea. Again the first two ideas are the most helpful because they are real preparation that counts on the job. It helps you get the job and it also helps you do the job well. Idea number one. Write everyday code every day.

Tyler:
I know that's kind of cute to have the repetition of everyday code. It was originally "code everyday everyday code." So I tried to take a step back from the cute– off of the cute spectrum. It's still a little cute but hopefully it's memorable because that everyday code is important. It's what makes this first idea different from the last idea. The one that I kind of pooh poohed about doing coding challenges.

Tyler:
I want you to focus on everyday code.

Tyler:
I've heard it attributed to Jerry Seinfeld. I don't know if it really is Jerry Seinfeld that said this or if he said it first or if he ever said it but people say that Jerry Seinfeld says: the way that I became a great comic the way I became a great comedian is I did the thing that is hard and that is core to my profession everyday and that is write.

Tyler:
It's hard to write. And so he wrote every day. He wrote jokes every day. Well you're a coder or you want to be. So you should code every day.

Tyler:
And you should focus on practical applications not on CS– computer science theory– solving red black trees, or implementing a faster sort. That's all good. I think you should do it once as part of the curriculum as directed but probably not the best thing for you to be doing every day. Because when you do everyday code it prepares you in a different way.

Tyler:
So what should you do for that. How do you find it. Because I think one of the reasons why people do coding challenges is that they're easier to find. You've– you go and buy a book or you sign up at a Web site and they deal out to you a challenge every day. And that's nice because. You know what you're supposed to do. And it's easy to get into a habit. But you really do need to get into the rhythms of solving the actual problems that you're going to have on the job because that's going to shine in the interview.

Tyler:
So what problems should you solve. Well you should solve something that you're interested in. It doesn't have to be amazing. It should be solving a need filling a need somewhere using coding skills. So scratch an itch. Fill a need.

Tyler:
Do it for free on your local host. Do it for free on your laptop because just about none of the web technologies are expensive or even pay for. Or there are a lot of free hosted options. So you don't need to pay for any of this. If you want to it's a good idea to set aside a budget– a monthly budget to pay for hosting, or to pay for resources to improve your career. Because it is your career. That is going to pay itself back. But don't get caught up on buying stuff.

Tyler:
Just start coding every day. Everyday code everyday. Right.

Tyler:
The reason why everyday code is going to shine so well in the interview– especially if the person interviewing you is a real practitioner and really has done the job– is that there are these well-worn parts of any technology. Parts of it that in order to get anything done you have to trod that path over and over again. And if you're ignorant of that well-worn path that's going to stand out.

Tyler:
If you don't know the boiler plate. The… the bits of syntax and characters that it takes just to get anything done… Or if you're not familiar with the vexing little quirks in the API that people trip over, over and over again because they weren't quite designed perfectly, or they're designed differently in every language, then that's going to stand out. Because during the interview you're going to… you're going to show that it doesn't just come to you… that the name of that thing is misspelled or it's a method instead of an attribute, et cetera. Right?

Tyler:
So solving practical problems will force you through those paths. And it'll make you better at performing in a coding interview– even better than solving game problems– unless in that interview you're actually given a game problem. In which case, hopefully you're familiar with that particular game problem, or you've just done enough coding and you're familiar enough with it that you genuinely solve the problem. Which would be ideal– is that you actually are good enough at coding to solve that game problem that they gave in the coding interview.

Tyler:
Personally I don't use complicated game-like problems. I use everyday problems in my coding interviews because I think that's more representative of the work you're going to do on the job. And I also find that it still separates the wheat from the chaff pretty effectively.

Tyler:
So that's that, right? Everyday code every day.

Tyler:
Idea Number Two: study theory and opinion.

Tyler:
So in addition to coding every day you really do need to read. And you need to read more than just the minimal docs to solve the problem.

Tyler:
And that's one of the reasons why writing everyday code every day is so powerful: because, it will force you to look up the answers to problems that you run into. Problems that you won't look up if you're just doing toy problems– especially toy problems in a sandbox. Because a lot of times, those sandboxes have bumpers on them that protect you from the mundane everyday problems that pop up when you're trying to use technology to solve problems. So you need to read more than just that bit of documentation. The great thing about everyday code is that it forces you to at least familiarize yourself with the documentation for whatever major technologies you're using so that you can get up and running. But you have to do more than just read documentation for the technology.

Tyler:
You also do need to familiarize yourself with the theory and with the prevailing winds in the industry.

Tyler:
So you need to do it all the time not just for some class not just as assigned in class. You need to have your feelers out to identify things that seem useful and learn about them.

Tyler:
And don't despair if it's hard. Some ideas take time. For example, raise your hand if learning to code has ever made you sick.

Tyler:
I know I can't see your hands but I expect that anybody that's seriously tried to solve problems with code has gotten sick on code. The first time I made myself sick studying computer science was the summer after graduating from high school.

Tyler:
I was lucky. I had a brother that was in the computer science program and he was two years ahead of me. So he identified a text book that would help prepare me for my first semester at school.

Tyler:
So I took that to my garbage job where I was doing account management for a credit card and taking inbound calls with questions about their accounts. And I took that book with me and read it on every break, every lunch. Read it while I was waiting for my ride home. And frankly it was fascinating and painful.

Tyler:
It made me feel slightly nauseous that if I read it long enough. And the ideas would just stick in my head and my mind wouldn't– it would refuse to stop thinking about it, until it would just wear rut in my mind. And make me feel physically ill.

Tyler:
It was Object Oriented Programming. The metaphors were so plain– they seemed to make sense. But turning that into a real understanding of how Object Oriented Object Oriented Programming could be used to solve a problem? That was hard. It was slow. It was painful. But it was so helpful that I had exposed myself to that information before I started my first class.

Tyler:
I found that when I would learn things in class now because there were already these little footholds in my mind it just was much easier to learn. And it wasn't because I had learned all of the content that I ended up studying. It was just that my mind had been exposed to it before and it was prepared to absorb more knowledge in that realm.

Tyler:
I made myself sick in college studying a lot of things and almost none of it, after that, was something that was part of the curriculum. Instead it was just something that I would learn about and it would fascinate me. And I would read up on it.

Tyler:
So I made myself sick studying XML on my own. It was such an alluring idea: self documenting, or self describing, data. It was so promising. And it would be many years. And some of it in XSLT or XML styling- style sheet language tool– transforms… It doesn't matter. If you know it XSLT is you're with me. Your feeling it. It's a purgatory. It was several years in that purgatory before I understood how much more complicated the problem was– how much bigger it was than just coming up with a syntax for describing data.

Tyler:
Nevertheless I made myself sick trying to figure it out and there's a really cool article in the ACM, Communications of the ACM called XML Fever. If you've got a subscription look it up. It's pretty funny.

Tyler:
The next thing that made me sick was UML: universal modeling language. It was so promising. Again a good diagram– It does so much to make an idea accessible. Unfortunately learning the visual syntax of a diagramming convention is one thing. Learning to make a good diagram is vastly more difficult.

Tyler:
It takes time. You need multiple exposures. You need to study it. Try to use it. Study it again– right away, or years later. But with every turning of that crank you learn more. You get closer to telling apart what is sexy from what is powerful. Don't despair if you don't understand it all the first time you read the article, or the first time you're exposed to a concept or a tool.

Tyler:
I had a really great statistics professor named Professor Tolley and he said, you know you guys– And he was just speaking to the to the class because he knew it was a difficult class. He says, if you don't get a good grade in this class don't despair. It doesn't mean that you can't learn statistics. It just means that you couldn't learn sta-, you couldn't learn statistics in the amount of time allotted for this class. Try again. You guys are lucky because if you don't learn it you'll get a bad grade and you can just take it again and that will replace it on your transcript. You can learn this. It's not like when I was going to school. And if you got a bad grade they would ship you over to Vietnam because you had to drop out of college.

Tyler:
And it was meant to be comforting. But it really wasn't at the time. I was pretty obsessed with my grades and the idea of being ok with a bad grade really just wasn't acceptable. But it really is a good point that you shouldn't despair if you don't understand something in a certain timeframe.

Tyler:
You should give yourself a break. You should come back to it. You should keep trying. You're going to make it. It'll get better every time. And these concepts really are hard. They are difficult learning to program is hard. And a lot of people that can do it can't remember how hard it was but it was hard.

Tyler:
I had an intern once that got hit by a car and he survived but he got a head injury. And he was fine for the most part but he had enough brain damage… I don't like that term. It makes it sound like he was… brain damaged. But he had some sort of trauma to his brain that the doctor said, you can't-, you can't go to work anymore. You can't program anymore. You need to not program and you need to take a semester or two off from college because your brain needs to heal and it can't do it while you're you're using it that heavily.

Tyler:
And I thought that was really cool. I mean, sad that he got hurt. But it was an interesting insight that the doctor would proscribe thinking. Because it is hard work. And your brain is like a muscle. It will get stronger if you use it and it will definitely atrophy if you don't. So don't give up. It's work. Learning is work.

Tyler:
To learn more about this you should read Daniel Kahneman's book Thinking, Fast and Slow. He has a fascinating section where he talks about how they could quantify the amount of work that a mental task was by measuring the dilation of pupils. They would ask people to perform math problems. And simple ones were clearly different from complex ones because the pupil would… I don't remember if would dilate or constrict but it would visibly change. And it would change in a way that was well correlated with the difficulty of the problems.

Tyler:
And that's because your brain really does take energy to run. It is hard. So give yourself a break.

Tyler:
I know I said that a lot of times. But I've met so many young people that took one class in high school or they took one class in college and they said, oh it was a lot- It was just so hard I can't figure it out.

Tyler:
Maybe something else is right for you. But don't give up just because one class was hard.

Tyler:
I was lucky because I had read that book before I took my first class. And it was so helpful. Because I had all of that pain of being first exposed to the weirdness of the way that programmers think– I got that in the summer. And I could do it at my own pace. And when I got in class it was just fun. But- and I'm, I'm, I'm a pretty good programmer. Pretty smart guy. It wasn't just easy. It didn't just come to me. It took work. So don't be afraid of work. Don't feel bad if you don't understand the first time. So that's all about study theory and opinion.

Tyler:
So how can you go about finding the theory. Well obviously if you're a student you should go to class. If you're a professional you're already on the job: pay attention to principles that seem to guide decisions at work. Like Big O or principles of optimization.

Tyler:
Pay attention to what comes up: coupling, cohesion. Pay attention to what's being spoken of. And look up some articles on that topic.

Tyler:
You should get some classic textbooks. You should have them and you should at least flip through them and read the headings so that you can know what the- what that text book's view of the body of knowledge was. Because those keywords– that understanding of the shape of the landscape is going to help you understand conversations that are going on. And it'll help you know how to search when something becomes important.

Tyler:
So just knowing keywords is so important. Without keywords you don't know what to google. And that may sound too trite. That may sound like it we're not taking our job seriously because we're going to google the answer. But honestly you do spend a lot of time looking up stuff using search engines or documentation and if you don't know the terms you're still not going to find it.

Tyler:
So get a text- get a classic textbook. You could read a syllabus. Ask a friend. Ask Google.

Tyler:
Lots of books have 'fundamentals' or 'algorithms' in their title. And a lot of times it'll be fundamentals in C++ or fundamentals in JavaScript or algorithms in JavaScript. So look for class-, Look for books at the library. Look for books at reputable book dealers like O'Reilly, and Packt. Look for books that have those in their title.

Tyler:
Computer science or I.T. training is worthwhile. I've had coworkers that didn't have it and did just fine. But some bits of the practice will elude you until you learn the theory. It will show that you don't have that depth. It won't show every day. But it is going to be apparent to those that understand.

Tyler:
And that doesn't mean that if you don't have the degree you can't possibly succeed. But if you don't have the degree you should be trying to make up that difference. You should be paying attention to what principles are brought up by the other senior engineers and go and do your study. Study up on it.

Tyler:
How about for studying opinion trends. You should have a variety of curated feeds- curated sources of articles that you look at. Probably on a daily basis. At least several times a week. OK?

Tyler:
It's not because you have to stay that up to date on the trends, but because you just need to have a habit. It shouldn't be something you do every three weeks or every other week. It should be something that you do routinely and by routinely I mean on any given day you're likely to do it, right? That's why you need to do it that often. It's not because something is- some landslide change is going to happen in the tech industry and if you don't find out about it for 72 hours you're gonna be sunk. That's not why.

Tyler:
So on these feeds you need to at least read the headlines. You need to read those headlines so that you can learn keywords. Read it. Click in. Read the articles.

Tyler:
Be smart about the way you spend your time. Not all of the content is of equal value. Learn how to skim. Learn how to to determine the structure of the- of that article– see if the most important thing is at the top. If it's at the bottom because they're holding back… Just get what you need to out of each article. The more you read the more it'll become apparent how to do that.

Tyler:
So get into a habit of reading those articles and don't let it wear you down. Declare bankruptcy often. It's better to have more input than you can possibly completely consume than to prune your sources of insight just so that you can read them entirely.

Tyler:
There's gonna be some things that you'll want to read every article in that newsletter every time but not likely. It's more likely that you're going to read two articles here, the first half of that article in a different newsletter, and the others you just read all of their headlines– that you can pay attention to how frequently they're mentioning a different technology and what sort of connections are being made between the different technologies.

Tyler:
So sign up for these sources. Sign up for book offers from reputable publishers. Sign up for their newsletters. So I'm thinking like I said Packt, O'Reilly, Smashing Magazine, Manning, Addison Wesley… Get on their mailing list. And you don't have to read the whole thing but at least skim it every time it comes in. It'll take you two seconds a day.

Tyler:
There's also tool vendors that will have good newsletters. I've particularly liked GitPrime's newsletter G-I-T-P-R-I-M-E. Sentry has a good newsletter. There's independent newsletters and conferences like Dev Digest, or no fluff just stuff.

Tyler:
And of course you should really think about getting membership in a professional association like the ACM. The ACM gives you access to curated collections of training material– both courses and books. So that is a goldmine for especially fundamentals and the center of mass for the entire industry. It can be a bit behind on web development itself but it's good for foundational material. And as a side note I myself have found that the ACM is a better value for the money and more relevant than the IEEE because my degree was in computer engineering and it qualified me to be a member of both for some time and I just found that I was always using stuff from the ACM. Not so often from the IEEE.

Tyler:
OK so those are the first two ideas and those help you do the job and they help you be prepared for the interview.

Tyler:
Now let's talk about a couple of things that really just help you be prepared for the interview. The first one is be prepared to demonstrate skill. And this is important.

Tyler:
Recognize that they're not going to just read your resumé or read your course listing and say, oh clearly they know how to do it because they they've taken a class.

Tyler:
No, you need to be prepared to demonstrate skill in the relevant technologies. So read the job description. Use the headline technology from the job description, or technologies, for a few hours within the days before the interview. Preferably the day of or the day before. And don't ask me to just trust you, or even your references, that you did it once and I'm sorry I can't remember anything about it.

Tyler:
Now I've had that happen where they- they'll say, javascript… Yeah, yeah I know javascript. But it's been 18 months since I took that class…

Tyler:
Sorry, you have to demonstrate it in the interview. So be prepared to demonstrate skill in the most important areas, the most important technologies, during the interview and for a web development position that's HTML, CSS and JavaScript. In particular with an emphasis on how to make browsers dance. And to make browsers do what you want them to do. Not just static layout of information, but make an application that runs in the browser. Be prepared to do that.

Tyler:
Finally, the last idea: Optionally you can study tricky code. You can go and do challenge Web sites like Code Wars or hacker rank. But I think that games are less helpful than coding everyday code everyday. I prefer study and practical applications to these sorts of cracking the code interview books where you've got those curated little chestnuts– the difficult little problems.

Tyler:
You should- you should be aware of them. And it's not a waste of time to do them. But I don't think it should be your primary form of preparation.

Tyler:
So, to repeat: you number one need to write everyday code every day.

Tyler:
You need to study theory and opinion and you should be doing that about every day.

Tyler:
You need to be prepared to demonstrate skill by refreshing your skills within 24 hours of your interview.

Tyler:
And finally you can optionally study tricky code in dedicated cracking the interview books or coding games websites. But that's the least important thing in my opinion.

Tyler:
Well that's it! That is how I would recommend that you learn to code. There's a lot more where that came from. But if I limit myself to just how do I encourage intern applicants to learn to code, that's what I tell them.

Tyler:
I'm Tyler Peterson, this is Manager J.S. I hope you enjoy what you're learning. God bless you and I look forward to working with you someday.

Quickly and accurately convert audio to text with Sonix.

Sonix uses cutting-edge artificial intelligence to convert your mp3 files to text.

Thousands of researchers and podcasters use Sonix to automatically transcribe their audio files (*.mp3). Easily convert your mp3 file to text or docx to make your media content more accessible to listeners.

Sonix is the best online audio transcription software in 2019—it’s fast, easy, and affordable.

If you are looking for a great way to convert your mp3 to text, try Sonix today.