S1E3: Why you should focus on fundamentals first with Chris Lee

Updated on | Sign up for learn to code tips


In today’s episode of the Learn to Code With Me podcast, I talk with Chris Lee. Chris is one of the founders of Launch School, an online program that helps people become software developers.

Chris took a traditional path to programming. He studied information systems and computer science in college. He worked at IBM for five years before transitioning to a tech startup, then moved on to Launch School. Chris talks about establishing a long-term approach to programming instead of getting distracted by the ever-changing landscape of software development.

We get to hear from Chris about learning from fundamentals, and how taking your time and working towards mastery now will provide greater benefits down the road. Chris highlights the importance of understanding core principles and developing logical thinking habits. He also advises programmers to build projects that showcase a full range of skills in order to appeal to ideal employers.

Laurence:
Hey everyone, thanks so much for tuning in to the Learn to Code With Me podcast. I'm your host, Laurence Bradford. In today's episode, I talk with Chris Lee. Chris Lee is one of the founders of Launch School, and online program that helps people become software developers. Before starting Launch School, Chris worked at IBM, at a startup in San Francisco, and at other tech companies. We talk about a lot of things in our interview today, especially about the importance of fundamentals. Chris himself is a huge fan of Ruby on Rails, and that's what he teaches in his program, Launch School.

Chris was kind enough to put together some resources for Learn to Code With Me podcast listeners. You can check it out by going to launchschool.com/ltcwm. Again, the URL is launchschool.com/ltcwm. For people who are serious about transitioning careers into software development, this episode is for you. I hope you enjoy the show.

Hey guys, I'm here today with Chris Lee. Chris, how are you today?

Chris:
Doing great, how are you?

Laurence:
I'm doing awesome, thanks so much for talking.

Chris:
Yeah, it's great to be here.

Laurence:
So, quickly, could you introduce yourself to the audience?

Chris:
Sure. My name is Chris Lee. I am an instructor at Launch School, which is an online program that trains people to become professional developers.
Laurence:
Very cool. Also, how did you get started in tech?

Chris:
I started in a very traditional way I suppose. I went to college, I majored in Information Systems and minored in Computer Science, and I was recruited out of college to work for IBM in Austin, Texas. This is way back in 2002. It's hard for me to believe it's been that long, but time flies when you're having fun. I went into the websphere development team over at IBM and worked on large Enterprise Java applications. So that's how I got started. I think it's probably a very traditional path, I suppose. Go to college and go work for a company.

Laurence:
Now you're not on a traditional path, at least I don't really think so. How did you transition from working full-time at a huge company like IBM to what you're doing now?

Chris:
When I was at IBM I was working on massive software projects where our development team would span hundreds of people scattered across the world. If you add in layers of management, QA, operations, it probably was over 1,000 people working on a software product. The software product had many pieces so you could even say it was a family of software products.

To me, at the time, that seemed like how professionals worked, how professional software development was supposed to be, it just took that much manpower and machinery to build quality software applications. But that's not true, that wasn't the end of the story. As we saw the rise of Facebook, which was built on PHP and, later on, we saw the rise of Ruby on Rails, which powered Basecamp and its family of products, and now GitHub and many other applications. We saw that that's not how really impactful applications are built.

So, my attention started to go towards that direction, which led me to leave IBM eventually and start freelancing and building my own startup, and eventually I was at a startup in San Francisco where I was a team lead, or engineering manager and I'm doing a lot of hiring. So it was through the process of trying to hire senior developers, I realized that the war on talent, especially in San Francisco, is real. That there is an extreme dearth of high-quality software developers. You didn't have to have a computer science degree from college necessarily to do web application development. So that's what gave rise to the idea behind, what eventually became Launch School.

Laurence:
Interesting, so when you worked at IBM, were you already living in San Francisco?

Chris:
I was in Austin, Texas when I was working for IBM.

Laurence:
Okay, got it. So then you eventually migrated up and left.

Chris:
Yeah, I quit IBM in 2007 I believe, after five years.

Laurence:
That's a pretty long time to work somewhere, I think it is. While you're at IBM you were doing Java but then I know you now do Ruby on Rails because that's what you guys instruct in Launch School. When did you start learning Ruby on Rails?

Chris:
2007. When I left IBM I basically made a decision to move away from Java and to start working in the Ruby ecosystem, the Rails ecosystem. To me, that was such a clear contrast of 'here you have hundreds of people working on a software product' and coming out of college, that's all I knew. I thought this is how professional software is built.

On the other hand you have people like David Hansson, the creator of Rails, building really great applications and one or two people were doing it. So that was such a glaring contrast to me and I just had to go see what it was about. How could you do that? Right here we have a team of, my development team was 15 people and we have three sister development teams all working in parallel and we had two QA teams that supported the development teams. And we had product people and layers of management. Obviously these software products are different, so I can't compare them together, but from a personal standpoint, I was more drawn to working on products like Basecamp, like GitHub rather than working on a small cog on this massive software product.

Laurence:
Wow, so you already had such a good foundation by having a CS degree and then you did work at IBM for five years, so I'm sure picking up Ruby on Rails was not really a challenge for you.

Chris:
Right, it wasn't a challenge from the standpoint of technical difficulty because, you always hear this, learning your second language is much easier than learning your first. Learning your first language is always the most difficult. Once you learn one, especially if they're at the same level of abstraction, which these application development languages are for the most part, Java, Ruby, Python, JavaScript. So, learning Ruby wasn't very
difficult.

What was interesting about Rails is all the assumptions that David Hansson made. I'll give you an example. I worked on, and Java developers will know this, a Struts application. So Struts was Rails before Rails. However, in the world of Struts, which is a web development framework in Java, we had to configure everything. We had a two-week plan just to set up the project. A two-week plan just to get the project set up. When you go look at a Rails project from that perspective, Rails just says don't worry about all that configuration, we're going to just make some assumptions here. We're going to, if you've ever heard of the phrase convention over configuration. Those assumptions made by Rails really hit at the heart of Enterprise Java development.

To me, it almost seemed like the framework was a reaction against these large Java applications. So it made a lot of sense to me right away. Now, if you don't have that experience of working on large Java applications or .net applications, maybe you're just going to Rails and learning the conventions of Rails without feeling the initial pain, and I think that's a little bit confusing and maybe you're not 100% sure why these conventions are in place. But they're in place because we used to do it differently and it took a long time. So now we have Rails. We can type 'Rails new app' and not worry about the configuration part.

Laurence:
So I feel like I'm sort of steering away from what I wanted to ask you but I'm really curious to know. So first, someone just starting out, they don't have any programming experience, or maybe they've dabbled in Codecademy a bit, but nothing substantial. Do you think that Rails, or Ruby on Rails, is something good for beginners to start with?

Chris:
I think Rails is a productivity tool for experienced developers. I think it's great for people who already are professional web developers looking for a productivity boost. It's absolutely not good at all for beginners to learn because there's way too many abstractions and conventions that hide the individual components of how the underlying mechanism works.

Programming is really about debugging. It's about figuring how things work. It's not about building a blog in five minutes. Anyone can do that. What happens if you have a bug and you need to fix it, or you have a new feature and you need to build it? That's not laid out in a tutorial. That's when your knowledge and understanding of the fundamental concepts underneath these conventions, that's when they're challenged. And if you
don't have that knowledge and you only know Rails, then you're not able to figure things out and debug at the appropriate level.

Another reason why it's not good to learn Rails first is that things change very quickly at that level. So Rails 5 is coming out and Rails 6 will come out soon after that. If your understanding is only at that level, then you feel like the world of web development is churning so fast. There's so many new things coming at you. But really the underlying technologies have been around for 20 years and the core of those technologies haven't changed for 20 years.

For example, at Launch School, we always say, “Learn things that don't change, or master things that don't change.” I think that's very important in web development. To have that focus on fundamentals. So a language, SQL, HTTP, and if you understand those things, learning Rails will just naturally fall in place. So, I guess the answer is no.

Laurence:
Could you relist those things you just said before? I think you said HTTP, MySQL. What was it again?

Chris:
Ruby, HTTP, SQL, and those are the major components, and some front-end as well, like HTML, CSS, and JavaScript. So, if you understand those four things very well, understanding Rails will just sort of naturally fall in place. Whereas, if you don't understand those things, you're always sort of learning how Rails does it without understanding the problem.

So I like to call Rails, and all frameworks, not just Rails, all frameworks, as solutions. Bundles of solutions. So somebody has experienced a problem, and they create a solution. They call that a library or framework. And if you go and learn that library and framework as the first thing, then you're essentially learning somebody's solution, their opinion if you will, on how to solve that problem. But you don't understand that problem, you don't understand the underlying problem that the solution solves. You're just kind of typing along with their solution. So that's not a good place to be, in my opinion.

Now, this is the caveat here - if you just want to build something real quick as a prototype, and I think this is what draws a lot of people in to Rails, is that you can be seemingly very productive very quickly. So you can do that if you want to, but if you ever want to be a professional developer, I don't think that's the, I wouldn't want to say 'right path,' but that's not the optimal path. I know it's tempting to kind of go and spin up a blog in Rails and try to learn Rails in a couple weeks and go from there. It's okay, but if you do that, just be aware that it's okay to not understand anything, because that's expected. You have to learn first principles.

Laurence:
Okay, I get what you're saying. I know this is so hard to answer, but I just want to hear your thoughts on this, because I know people are going to be thinking it. How do I know when I'm ready to start learning a framework? How do you know when you know these things that don't change? Ruby, some front-end like HTML and CSS, how do you know when you're at a point where you maybe should start learning a framework?

Chris:
I think that's a great question, and that's really difficult to know for certain, because each of these individual components has so much depth, that you can spend years just focusing on it. For example, Git. You can read books and books on Git alone, or Ruby. You can't master Ruby in a week or a month and then move forward to the next topic, like HTTP and SQL itself is a job role. You can become a database administrator or an SQL expert. And that's a really great question.

This is, I think one of the major advantages of using a structured program like ours, which is it guides you through the trade-offs of how much you should learn and when you should move forward. Learning on your own, you're going to have to, that's also possible, but you're always going to have to sort of play that trade-off. Like, if I read this one book on SQL, is that okay? Or am I still missing something? There's always sort of that. And I think that's where structured learning curriculum comes into play.

Laurence:
I know it's something that is really difficult to answer, like when you're ready to move on to learning a framework or something. With the Launch School program, how much time do you guys spend before even getting to Rails? With the fundamentals?

Chris:
In my opinion, it's all about fundamentals, so Rails is way in the back in what we call the advanced phase of our programs. If you look at our program, it's divided into sort of four major phases. The first one is the preparatory phase, which is completely free. We have three courses there that are no cost and you can go in there and basically get your feet wet in terms of starting to learn how to program. Even in that stage there's a lot depth, and we ask a lot of you to learn the syntax of a language and learn how to solve simple problems. And then the second phase is what we call the programming back-end phase, which goes even more in depth. Then we have a front-end phase which talks about the front end. And then we have the advanced phase which then we talk about Rails. I would say, if you're absolutely new, I would say a good 4-6 months before you even touch Rails.

Laurence:
I think that's good, and I guess it also depends on how many hours you're learning a week. Because someone could be learning 40 hours a week and another person could be learning five hours a week, depending on the situation. The Launch School program is really for people who want full-time jobs as software engineers or software developers, correct?

Chris:
Yes.

Laurence:
So then, what about for someone who maybe isn't sure yet that they want a full-time job? They're just kind of exploring, maybe they want to freelance or maybe they want to do more, not so much in these larger applications or full-scale applications, they want to just do WordPress sites or something like that?

Chris:
What we usually say is that our program is not for people who are hesitant. It's such a tough program. Our program is at the intersection of three attributes. One is really in depth, two is online, and the third is asynchronous, which means that we take a mastery-based approach as opposed to a time-based approach. So you're not sitting here saying it's a 2-month program, or a 3-month program, or a semester or something like that. You go as fast or as slow as you want, as long as you master each topic as you move forward. And these three forces are sort of going against each other. So it requires a lot of individual effort, especially being very difficult and being online.

If you're hesitant, if you say “well I might want to freelance,” and “I don't know if I want a job,” then it's really hard to sit there and debug a problem for 2-3 hours. I may not even want to do this. Why would I want to sit here and bang my head against this problem? That's really where the decision, or the commitment comes into play. And also our program is probably going to be overkill if you just want to freelance or just want to build prototypes or smaller applications, as you say. It's probably a little bit overkill.

Laurence:
I'm curious why, after the prep, you do the programming back-end and then front-end. What do you teach in the programming and back-end section?

Chris:
Yeah, the programming and back-end section is a lot of repetition, a lot of exercises, and of course, we help you construct a progressively clear mental model of how the programming language works. For example, in Ruby, we have to compartmentalize the language each step of the way as you move forward. As you move forward, you have to have a consistent mental model of how that language works. We can't talk about the entire language all in one go. And this is true of any language, it's not just Ruby. It's about how you approach learning your first language. You have to do it in small steps, but each step of the way has to be consistent.
So that's what we do in the programming and back-end.

Now, when you go on learning your second language, it's going to be a different experience, I think. You don't need to learn how to think like a programmer anymore. And that's a really hard hurdle for beginners to overcome. You're not only learning the syntax of a language, and you're not only learning the mental model of how the language works, you're also learning how to think systematically, and think logically. And I've said this many times in our program, I see people who are lawyers, who have philosophy degrees, and who are trained musicians. In particular, these three fields, they do really well as programmers because they're naturally, they train to be very logical and detail-oriented. It's not that if you don't have that background you're not cut out to be a programmer, it's that you have to work to develop that temperament to have that fanatical attention to detail. You think about what lawyers do all day, they parse words from large legal documents. That's what they do, and that's what programmers need to do as well, if you want to learn to that level of proficiency.

Laurence:
Yeah, that's so interesting. One of the other people I've interviewed for the show, he did go to a coding bootcamp, and now he's a software engineer at a really good tech company, but he did music his whole life. He studied music in college and worked in the music industry - I don't know for how long, but a pretty long time. I'm not musical myself, but I could definitely see how reading music and doing different things with music, even audio editing and sound engineering, how it could be related, and with attention to detail, how it could help you learn how to program.

Chris:
Right. So, in the beginning stages, it's really, if you already have that background it helps, but if you don't you have to develop that and that takes a while to develop. I don't think it's something you can just knock out in a week, for example. This is why everyone is different, this is why we take a mastery-based approach as opposed to a time-based approach. If you think about someone who comes from practicing law or a trained musician vs. someone who has never done that in their background, they're not going to be able to go through the same curriculum in the same amount of time. What I always say is, however long it takes you, just spend that time. If it takes Bob over there one month and it takes you three, so be it. As long as you reached the same level of mastery and understanding at the end of the sequence, that's what we're going for.

Laurence:
Definitely, we're all on our own path. Just because it takes one person two months, I think it's perfectly fine. There's people in my Facebook group Newbie Coder Warehouse. Some people will get jobs very soon after learning, within three months or something. And there's others who it will maybe take them a few years. I think you can't really compare yourself to other people because you don't really know what their background is, or maybe what their life is like. Maybe the other person has a family and all these other responsibilities and the other person can easily dedicate over 40 hours a week to learning.

Chris:
Employers are also really bad at hiring, so sometimes they'll just go for the person with the degree, regardless of their programming ability. In our industry, hiring itself is an imprecise science. When you're trying to aim for that bar, which itself is imprecise, it's very difficult sometimes.

Laurence:
Since we're talking about employment now, is there anything you suggest to people who go through a program like Launch School or something else that's more intensive and they're really dedicated to becoming a software engineer? They know they want do that, they're not uncertain, that's what they want to do. Do you have any advice you could give? Whether it be about applying to jobs or what kind of jobs to look for or interviewing itself?

Chris:
The most important thing and the most important advice I would probably give is to make sure that you're very strong on fundamentals. In job postings, I see people make this mistake a lot, which is they see a job posting and they see React or Rails or Angular or whatever the hot technology of today is, and they go and buy a crash course on that technology with the hopes of coming back and applying for that job. However, what's left unsaid in that job posting is that you have to be really strong in the fundamentals. They just don't list all the fundamentals that you have to know in every single job posting. It does you no good if you did a quick two-day course on React but your JavaScript skills aren't there, for example. Or if you did a quick course on Rails but your Ruby skills, you can't solve a simple exercise with pure Ruby. So I think that's really important.

The opposite, you can actually be very strong on fundamentals and not know the framework, and that's okay. There's a lot of people who get jobs who don't know the framework but they've proven themselves smart and fast learners and a lot of times employers will take a chance because they think that you can learn on the job very quickly. I would say that the thing is, when you look at job postings, don't just look at what's listed and go, "Oh, if I just learn that," because there's a lot of things left unsaid.

Laurence:
That's a really good tip. I definitely agree. Even with some job postings, say it lists CSS preprocessors like Sass or LESS. Maybe they use LESS or something and the person says "I don't know LESS, I know Sass." Moving from one to another is not difficult at all as long as you know how they work and you have those fundamentals down.

Chris:
Exactly, but the opposite's not true. Like if you read a tutorial on Sass but you don't know CSS very well. That wouldn't be good.

Laurence:
Definitely, because it's like putting the cart before the horse, does that make sense? Does that work there? I tell people that often as well, with the JavaScript libraries. If you don't have a solid understanding of JavaScript it's kind of useless to learn Angular or React or Ember or what have you. I feel like once you know one, transitioning to another is not that difficult. And as you explained already this same thing goes with languages.

Chris:
Yeah, I'll mention another thing, which is there's a lot of jobs out there. There are companies who will hire you if you know a little bit of Angular, but when people say “I want to be a programmer or a developer,” I don't think they're imagining $12 per hour jobs at your neighborhood real estate firm. They're imagining something that pays $80, 90 100k depending on where you live. With three weeks of vacation, with full benefits for you and your family. They're envisioning those types of jobs. In programming, there are so many different types of jobs that anybody can call themselves a programmer.

It's kind of like being a writer. Anybody can be writer, but when people say “I want to be a writer,” what they're envisioning is writing a bestseller and being a great American novelist, or something like that. I think with programming it's a similar thing. There are jobs out there that you will be able to get with very little knowledge. At Launch School, what we're trying to do is trying to produce people who can be competitive for some of these top jobs.

Laurence:
Definitely, your program is not for people who want to make extra money designing local restaurant websites using WordPress or something. Not that that's a bad thing at all. It's just, for someone who wants that kind of full-time job that you described, with the paid vacation, the benefits, the nice salary, the flexibility. I feel like a lot of software jobs nowadays, just with the ease of working remotely, are becoming more flexible, but I guess that could depend.

Chris:
The more leverage you have, the more you can demand in terms of your work experience.

Laurence:
I love that. So true.

Chris:
The better you get, everyone wants the flexible life and the high pay, but are you willing to put in the work to reach that level? I think a lot of employers will say, “Sure, we would love to have you, but prove to me that you can be productive on your own, when I'm not looking at you.”

Laurence:
Definitely. I think that could even be said for a range of industries. I think if you have really good skills and have a proven track record, you don't just say “Here's my skills on my resume,” if you have the actual experience to back you up they're going to be more flexible as far as your work environment goes.

Chris:
Right, senior developers get recruited and the interview experience for senior developers is very different from junior level roles. Junior level roles, they're always trying to prove the boundaries of your knowledge. For senior developers it's a conversation about what you've done and it's a lot more pleasant and casual. Not always the case, but a lot.

Laurence:
Yeah, and I think that a lot of people that are seniors or even mid-level, if you have a LinkedIn that's put together, I think that's the main one, recruiters will find you. In fact, there's people who get bombarded to the point of annoyance from recruiters looking to hire them or looking to interview them.

Chris:
This is why I think the easiest way to actually reach everyone's goals, I know everyone has different goals, but ultimately everybody wants the flexibility of being a programmer. You can work anywhere, you can work for various clients, you can work for a variety of industries. All these things are much easier if you're really good at programming. It's just harder if you're not very good at programming. Or, if you're average at programming, then you must be really good at something else to sell that combination. It's just easier if you're really good at the technical side of it. Then you can present yourself as an expert in web development, but “I'm interested in working for this hospital, or something like that, and I want to work from home.” That conversation is much easier.

Laurence:
I guess now we're talking about senior developers and I know most of the people listening to this are definitely not at that place yet. They're just looking for their first job. I'm actually curious to hear your thoughts on this as well. For students, like students who would be in Launch School, someone who wants that full-time job. Maybe they want to work at a top tech company or a smaller sized start-up, something like that. Do you suggest, before they start trying to get those full-time jobs, doing any kind of freelancing or side work or building projects? What are your thoughts on that?

Chris:
I don't believe that freelancing is mandatory. I would say that as long as you have an opportunity to build a strong track record, freelancing may or may not be a good way to demonstrate that. You're at the whim of the client. A lot of times clients, especially if it's a startup, they may not want you to share the code. So, open source may be a better way in that you can show what you're trying to produce, which is code. This is why building applications in themselves is not necessarily going to give you a great portfolio because it's hard to see the code unless you're the designer. It's hard to see behind the scenes the decisions you made, the trade-offs you made, and how you architected the code and your design choices. I would say if the goal is, let's say not to make money, but to put yourself in a position to apply for a good job, try to work on projects where the code is visible.

Laurence:
That could be your own projects, as you mentioned, open source, or maybe you do find a client, or even a volunteer thing where you can have it be on your GitHub or something.

Chris:
Yeah, possibly. Like I said, freelancing, you're sort of at the whim of your client, including volunteering, and the work may technically be interesting but important for them. You might fall into this trap of freelancing for six months but producing the same type of applications ten different times. I don't know if that's impressive, just building the same level of complexity ten times. What you usually want to do is build something that showcases what you're capable of. It might be a couple sort of crud web applications, to show that you can do that too.

I think that's a hard question, because what I always like to say is, have a target in mind so that you're not coding with some ambiguous goal. If you say, “I want to target thoughtbot,” which is a top consultancy, I think a good way to do that is to take a look at their open source projects and perhaps contribute to it. Having a target in mind is always a little bit better in that it gives you a direction to go. If I just build this blog, is it going to be impressive to people? To some it may, like your neighborhood real estate firm may be impressed. But a top consultancy may not be.

Laurence:
I really like that advice about thinking about where you want to work, I assume that's what you mean right, by target in mind? The company you want to work for? Then, kind of putting yourself in their shoes and seeing what would really impress them. I feel like a lot of companies probably have some kinds of open source stuff?

Chris:
They all do, or if not open source, then just be proactive in fixing things that are broken, for example on their website. I have people emailing me all the time about typos and little things on the Launch School website. There's a small handful of people who do it so consistently, that if they wanted to get paid to do I would probably just agree. Because they produce high quality work. Every suggestion is right, I agree with it.
Not only do they provide the suggestion, they provide a fix, like the attachment saying, "Here's the CSS or JavaScript that's going to fix this issue I brought up." How could you say no to someone like that if they were to ask for money? You'd say, "Sure, I'll hire you." Having a target is always good, because then you can focus on impressing that particular employer. It's kind of like dating. You don't want to try to impress everybody, you want to impress one person.

Laurence:
That's a good tip. We're running low on time here. I just want to ask this final question. If a person has no technical experience whatsoever, but they want a job in tech, specifically as a software engineer, what is one thing they could do today to take a step in the right direction?

Chris:
I would say, don't learn frameworks. Learn from fundamentals and take your time. You asked for one thing but I think, I would say focus on fundamentals. Pick a language. Your first language doesn't matter as much as you think. Ruby, JavaScript, Python, even Java, you can't really go wrong if you go deeply. Don't get tempted or sidetracked by a new thing coming up. Stop reading tech blogs. Don't read about the newest Meteor version or the newest React library. Just focus on the fundamentals.

If your goal is to build the skills necessary for a 20-year career, you don't want to focus on what's hot today. You want to focus on the fundamentals. It's so easy nowadays to get sidetracked into a sexy blog post or something new that is going to be a shortcut. All these frameworks, all these 'learn programming in 21 days' or two months type of thing, are all shortcuts. Don't take a shortcut because you have a 20-year career that you're thinking of. Having a long term mindset I think eases the anxiety a lot because all of a sudden, spending a year or two years is okay, you have such a long career in front of you. If you say, "I'm going to give myself three months to become a programmer," you will have to take shortcuts, there's no way around it. And shortcuts, why do they call it a shortcut? Well, you get something, but there's a cost. If you don't get something it's a dead end. If there's no cost it's just the right way to learn.

My number one advice to people would be to learn from fundamentals. Pick a language, solve simple things with that language, and then slowly move on up. Learn SQL, learn HTTP, and don't get distracted.

Laurence:
Yeah, I love that advice. Focusing on one thing. I think that's applicable in so many ways in life because it's so easy to get distracted by the new shiny objects and so on. Thank you so much, Chris. We know where people can find you online already, at launchschool.com.

Chris:
Click on the link in the Show Notes.

Laurence:
Okay, thanks so much.

I hope you enjoyed our conversation as much as I did. Again, you can head over to launchschool.com/ltcwm to see the goodies that Chris is putting together for you. To learn more about this episode, as well as some of the resources mentioned, head over to the Show Notes page at learntocodewith.me/3.
In our conversation today, we spoke a lot of about getting the skills needed to get a job as a software developer. And in my opinion, one of the best ways to get the attention of hiring managers and recruiters is LinkedIn. I believe in LinkedIn so much that I created a 5-day LinkedIn crash course. You can get it at learntocodewith.me/linkedinbook. Inside this crash course, you'll learn the basics of getting your LinkedIn profile setup, how to write a standout headline, a great summary, an action-oriented experience section, and you'll also learn about what technical recruiters and hiring managers look for on your LinkedIn profile.
Again, the URL is learntocodewith.me/linkedinbook. Thanks so much for tuning in today, I really appreciate it. I'll see you next time.

Key takeaways:

  • Master things that don’t change, like the underlying technologies have been around for 20 years. When you understand the core principles, you can learn anything.
  • When learning, a structured program is beneficial in that it shows you when it’s time to move forward to the next concept. Mastery, rather than time spent, should be the goal.
  • Programming is about learning how to think systematically and logically. You have to develop a fanatical attention to detail. Learning a language isn’t enough, you need to grasp the mental model of how the language works.
  • Don’t start by learning the frameworks. Learn from fundamentals and take your time. Don’t get tempted or sidetracked by the new, shiny thing.
  • If your goal is to build the skills necessary for a 20-year career, you don’t want to focus just on what’s hot today.
  • The more you know, the more leverage you have, and the more you can demand in your work experience.
  • Target the job you want, and then build something that shows what you’re capable of with that job in mind.
  • Having a long term mindset eases anxiety. Spending a year or two learning has value when you have a long career in front of you.

Links and mentions from the episode:

Thanks for listening!

Thanks so much for tuning in! Remember, you can listen to the Learn to Code With Me podcast on the following platforms:

  1. The LTCWM website (https://learntocodewith.me/podcast/)
  2. iTunes
  3. SoundCloud
  4. Stitcher

If you have a few extra minutes, please rate and review the show in iTunes. Ratings and reviews are extremely helpful when it comes to the ranking of the show. I would really, really appreciate it!