Kyle Simpson
A better developer through collaboration, with Kyle Simpson
Kyle has a simple recipe for developer success: understand the problem before you try to fix it. With Kyle's widely read "You Don't Know JS" book series, learning JavaScript more deeply is something every developer can and should take on as a challenge. Not only is Kyle an author, but also a teacher, speaker, and chronic contributor to the world of open source software. Kyle offers corporate training workshops for JavaScript and is currently working on a new startup to take developer education to the next level.
Your browser doesn't support HTML5 audio
Kyle Simpson
Time Stamped Show Notes
1:10 – Having social interests outside of programming keeps you well-rounded. Kyle enjoys table-tennis both to engage his brain and get exercise.
2:22 – Kyle likes to hang out with people who think very differently to him. He meets every Friday morning with a group of people. The only thing they have in common is they all meet at the same place. They chat about things that get them out of their own echo chambers. This keeps Kyle in touch with what different people feel and the empathy they have. He doesn’t think he’ll get this by spending time with people in the industry who agree with him.
3:59 – Kyle has been a developer for around 20 years after deciding in middle school that’s what he wanted.
4:16 – About 5 years ago Kyle realised that teaching people software development was more fulfilling than working on other people’s code.
9:14 – There’s value in plowing through tasks quickly, as with the agile approach, but someone needs to have the bigger picture in mind. As developer we get myopically focused on things, and paint ourselves into a corner.
10:35 – Kyle doesn’t use a lot of tools, and only adds methods or tools when he needs them. Kyle can’t live without source control like Git, and believes software development is a collaborative task which services like Github contribute to.
11:02 – Kyle uses Git as a process to manage his thinking on what he’s working on.
11:54 – We’re missing out when we believe that something we create needs to be the best version of it before we put it out for other people to see.
12:57 – “Every line of code that I write is the worst possible version of that code, and the only possible way for me to get it to be better is to have other people help me.”
14:50 – If someone’s hoarding their code, and not making it public, it might be because they don’t know how bad their code is, or they don’t know how much they need other people’s help.
15:15 – As an industry there’s too much reliance on tools, applications, patterns/techniques and automation that do all the thinking. People stop knowing what’s happening “under the covers”.
16:54 – Abstraction was designed to make it easier to see all of the parts, not to hide away details so that you never see them again.
18:02 – The resulting symptom is burnout, or Javascript fatigue as we now call it. The stress is that there are so many tools and it’s difficult to learn them all. Kyle believes he would fail a modern-day interview as he doesn’t use many tools. Instead, he focuses on understanding each of the steps.
19:02 – A lot of people don’t have the luxury of understanding things on a step-by-step basis, and use tools to solve their problems without having to think about them. People give up so much understanding to abstractions and tools that they end up eroding their own confidence.
20:08 – We use tools to make us faster at shipping code, where we should instead use tools to help us focus on what is important.
22:10 – Code splitting and tree shaking is exciting.
24:20 – We readily ship entire Javascript frameworks to production, and let the user deal with it, but we don’t think about the people who don’t have free access to bandwidth and even power. Some people have to budget for recharging their cell phones.
25:41 – We should pay a lot more attention to shipping only what’s necessary.
26:49 – Kyle’s excited to see that there are smarter and smarter tools that pinpoint the unnecessary stuff being shipped. Tools like tree shaking and code splitting strip everything down to the bare minimum in a more automated way.
29:00 – Kyle doesn’t try keep up to date with all the new languages and libraries being released. He wishes he did. When he works on his own projects he has the opportunity to learn new things. When he learns something new, he does it properly. That way he gets more out of it.
29:47 – He recently released a library called FPO. It’s a functional programming library for JavaScript but it allows named argument style.
33:00 – Functional programming has had the biggest impact on how Kyle thinks about and writes code. Kyle has published his latest book on functional programming that makes it easier to get started for newcomers – Functional-Light JavaScript.
35:19 – Functional programming makes it possible for someone who is reading the code to not have to re-execute that code in their mind to know what it’s going to do.
36:39 – Researchers have found that developers can spend about 70% of their time just reading code, before even getting to write any code. Kyle believes functional programming is about writing code that people don’t need to read. All they need to do is glance at it and recognise the items.
38:28 – As with all of Kyle’s books, Functional-Light JavaScript is about helping people understand how to use certain principles to make their code more readable, verifiable, and trusted.
38:41 – If you don’t understand a piece of code, you can’t trust it and vice versa.
Quickfire Questions
39:53 – Best advice about programming
“You ain’t gonna need it” (YAGNI). Don’t add things to a project because you think you need it, but be wary of being myopic at the same time.
41:23 – Whatever level of abstraction you play at, be a master of that level, and be competent at the one below.
41:50 – Habits for writing better code
Kyle constantly thinks about how he would write about the code in a book. He also thinks about how he would describe the code when giving a talk. It allows him to eliminate anything that might be confusing to someone trying to understand and read the code.
43:18 – Book
Human JavaScript. Henrik Joreteg is the main author. It covers which patterns of the language will make a team more effective in a pragmatic sense.
44:50 – Inspiring devs
Brian Lonsdorf, the author of Professor Frisby’s Mostly Adequate Guide to Functional Programming. Brian did the tech-editing on Kyle’s latest book.
45:44 – Mattias Johansson and his Fun Fun Function video series. Mattias is Kyle’s spirit animal, and he particularly likes how Mattias breaks down something complex topics into bitesize pieces.
46:20 – Dan Abramov is fantastic at balancing pragmatism. Dan is also instrumental in creating Redux and has done a lot for the community.
47:35 – How to learn code from scratch
Kyle would first question the end goal of writing a programme. Whether it’s to get something done or where it’s something bigger. He thinks it would be amazing to wipe the brain and start from scratch. He thinks the available resources will help him make sure that he doesn’t make the same mistakes or develop the same bad habits.
48:22 – Follow people who believe that understanding what you write before you write it, is important.
48:57 – He would read the You don’t know JS books as well as other free books. He would also use freeCodeCamp, CodeAcademy and Khan Academy. He’d also find a mentor like Brian Lonsdorf to learn from him.
49:23 – Find someone to mentor you.
50:15 – How to work smart
Don’t let yourself be stuck for too long, but don’t assume that you’re lost the first time you don’t understand. It’s okay to be stuck in limbo for 5 – 10 minutes. Embrace the limbo and uncertainty because that’s where you learn. It’s important to have a good place to find the right answer. “Leave a breadcrumb” or clue in your code so that anyone who reads the code won’t get stuck in the same limbo.
Tools, Tips, and Books Mentioned
Contact Kyle
github: github.com/getify
linkedin: linkedin.com/in/getify