Advice from a Senior Silicon Valley Engineer

Advice from a Senior Silicon Valley Engineer

Swizec Teller emigrated from Slovenia 🇸🇮 to Silicon Valley to work with the best engineers on the most challenging problems. Along the way, he hired and continuous to mentor countless juniors. In this episode, you'll learn what Swizec looks for in Junior Developer in 2021 and how you can crack the coding interview by highlighting your potential.


Timestamps

  • Introduction (0:00)
  • What employers look for in Juniors (02:32)
  • What projects will impress employers? (05:01)
  • The difference between front-end engineer and front-end developer (07:28)
  • An introduction to JSON bureaucracy (10:57)
  • How to measure your own ability and skill (14:39)
  • How Google hire Juniors (20:50)
  • What Swizec learned from Richard Hamming (23:11)
  • Swizec's career vision (25:37)
  • An introduction to the Senior Mindset (28:07)
  • What Juniors can expect from seniors (29:09)

Transcript

Alex Booker (00:01):
Hello, coders and welcome to The Scrimba Podcast. On this weekly show, I speak of successful developers about their advice on learning to code and getting your first junior developer job. Do you ever wish that you could pick the brain of a senior engineer about how to succeed as a new developer? Well, that's not always possible sadly, but the beauty of The Scrimba Podcast is that really busy people will spend an hour to answer questions I hope will benefit you the most. Today you'll be learning from Swizec who is a senior engineer with more than 15 years of professional experience. He's from Europe originally, but managed to secure a visa to work in Silicon valley where he's hired and mentored junior developers. Swizec also makes courses about modern technologies like Serverless and GraphQL, and there's even been featured in Business Insider, Huffington Post and several [Detry 00:00:53] magazines.

Swizec (00:54):
I started in Europe and I was like, "Wait, I'm reading about all these people from the U.S. who have these amazing careers and they get paid ridiculous amounts of money. I want to have that kind of career." So that's been my vision to try to solve interesting problems, big problems.

Alex Booker (01:10):
I really feel like this episode could feel a little bit like you are having a one-on-one mentoring session with Swizec. We spoke about what Swizec looks for in junior developers, in today's markets as well as what to expect from senior developers, such as Swizec himself. And then we also touched on some really interesting topics, things that really scratched my head. Like what is the difference between a front-end developer and a front-end engineer? Hmm. I guess we better jump into it.

Swizec (01:39):
I've been programming pretty much for my whole life. Now, current I'm in Silicon Valley in San Francisco working for an exciting health tech startup. I generally have focused my career on working with startups, just because I think it's more fun. A lot of my friends in big tech, when you ask them about their job, they always say, "Yeah, you know, the money is good." That's not the career I want. I never want to be somewhere where the best thing is the money is good. I like to work on exciting, interesting projects. And on the side, I like to focus on teaching what I learned throughout my career. Right now I'm talking a lot about the senior mindset. I've also done teaching on React, React for data visualization. I think I've been focused mostly on JavaScript for the last, oh, this is going to date me like 10 years. Maybe a bit more than 10 years. I started before jQuery was a thing. If that tells you anything. I write books. I code and that's most of what I do.

Alex Booker (02:32):
I suppose, for anybody listening, it would be good to hear your perspective about what you think employers are looking for in a junior front-end developer these days?

Swizec (02:41):
What employers are looking for in a junior front-end developer, I think primarily is a lot of potential. They're looking for somebody who's going to hit the ground running, but nobody's expecting a junior developer to come in and build their new infrastructure in React or re-engineer their entire app. I know a lot of juniors want to do that, but usually you don't have the experience yet. Some do because they've been working on Open Source for a really long time. And that's a really good skill to have. But what they're mostly looking for is somebody who's going to come in. Who's coachable. Who's going to learn very quickly.

Swizec (03:16):
I've been doing a lot of interviewing lately just because the startup I'm at is growing so fast. And one of the most impressive things I've ever seen, this was more of a mid-level developer, but we started a one hour coding challenge. And in the beginning she was struggling with something and I explained it to her. And by the end, I could see that in that hour, she already became a better developer. And that was just, "Oh my God, we got to hire this person." I don't even care how good they are or how good they're not. If they can visibly improve in an hour during an interview, that is somebody you want to hire as a junior engineer.

Alex Booker (03:50):
Hundred percent, because as a junior, you're not really being hired for your experience because while you don't have any yet, like you're just starting out. But instead you want to show your teachability and potential to grow in the role. I made that mistake. I waited a long time thinking I wanted to know everything before I got the job. And even though I was always keen to learn, I think I could have probably got a job by trading on my potential much earlier on.

Swizec (04:13):
I think that's a mistake a lot of people make where they wait too long, or I know a lot of YouTubers say, "Oh, you need to have of a side project and then you're going to get hired." The fact of the matter is that a solo side project, no matter what you come up with is just never going to be as complicated as a real production app that's being banged on by even by five engineers. But when you get to really big companies where they have hundreds of engineers working on the same code base, you're just never going to be exposed to that environment on any side projects. Maybe a huge open source project, like if you come and you say, "Yeah, I'm a junior, but I've been working on the Linux Kernel for the last five years." Yes. That is definitely impressive. And you've probably learned something even more complex than most startups, but you're probably also not actually a junior if you can work on the Linux Kernel.

Alex Booker (05:01):
I've heard a lot lately though when you build a side project or a project to get your foot in the door at a company, some people are saying that like CRUD applications are a dime dozen and they're not that interesting and there's not a lot to talk about. And so instead you should build something that is a bit more unique. And then in the interview, when you're asked to talk about it, you can talk about the unique problem you solved, and that might be more interesting for the interviewer. What's your opinion?

Swizec (05:26):
CRUD apps are a dime a dozen. What's nice about CRUD is that when you squint hard enough and look at pretty much most SaaS startups these days, all of them are basically a CRUD app. There's some magic going on, but mostly you're dealing with emergent complexity and how to work together as a big team. How to evolve the project. So it's more from that perspective, you can show that your side project actually hit the market, had actual users and you responded to those users and improved on the app. That is a lot more interesting than, "Hey, I built this thing." Where I do think side projects are useful, is just getting some of that experience to see how to build things and to see how it works in the real world. But it's more about showing that you can finish something. Showing that you are somebody who takes a problem, figures out how to solve it goes from there.

Swizec (06:17):
That's really impressive to maybe a recruiter, possibly a hiring screen manager, but in these companies where you have a longer process, by the time you get to someone like me, who's just doing a specific part of a... We call it, in person, but it's actually via Zoom because the whole situation. By the time you get to someone like me, I usually don't even really look at your resume or anything because most resumes are honestly very the same. We have a specific challenge. I'm evaluating your specific skill in that challenge. And that's what we want to talk about. I know to some people that sounds really unfair like, "Oh my God, I put so much work into my resume." But think about on the other perspective is I don't want to bias towards people who have an impressive resume rather than people who are just really good at what they do.

Alex Booker (07:05):
You want the best candidate, not the best resume writer necessarily.

Swizec (07:08):
Exactly. And I also personally like to avoid skewing towards various fancy degrees and fancy past employers and so on. So if I can I avoid looking at the resume because I don't want to be, "Oh my God, this person used to work at Google. They must be amazing." Like, you know what thousands of people used to work at Google.

Alex Booker (07:28):
Is there a difference between a front-end developer and a front-end engineer?

Swizec (07:32):
Oh, that's a great one. So I do think there's a difference between developers and engineers in general. A while back, I did some research on salary ranges and the H-1B visa in the U.S. has a requirement of publicly publishing the advertised salary. So you can look at different job titles in the software industry and compare their salaries with a real hard data set. And it turns out that being an engineer is worth about a 20 to $30,000 bump in salary, at least in the U.S. Compared to being a developer. I was really curious, why is that? So I've been researching it for a while and the best answer I have is that a developer is somebody who can take a spec and write code that fits the spec. But an engineer is somebody who can take a problem and solve the problem and just happens to be using code, to solve the problem.

Swizec (08:24):
There's also that really good book from Google Software Engineering at Google, which surprisingly applies to smaller skills companies as well. What they say is that engineering is programming over time. So if you're a programmer slash developer, you can write a piece of code and it works and it does something. But if you're an engineer, you also think about, "Okay, so I have this code. How is this going to evolve over time? How are we going to make sure that this still solves the problem five years from now? How can we evolve it to meet changing demands? How can we write this code in a way that encourages other people on the team to write good code rather than encouraging bad practices?" And that sort of thing. So it's the code is just the tool and you're engineering and entire system, a team figuring out how this is going to work over time. Whereas coding slash developing is more like, here's the thing, solve it. You're going to use code because you're a coder. And when you have a hammer, everything looks like a nail and it doesn't have to live a long time.

Alex Booker (09:22):
It does sound like being an engineer is maybe more challenging and based on your description, it sounds like if you are maybe going down the self-taught path and doing things like CRUD apps as a starting point. You're probably a lot closer to being a developer than you are an engineer. But what I'm also kind of learning from you is that it's not set in stone. You could probably start as a developer, junior developer, most likely. And then over time, learn new ways of thinking and learn different tools aside from code to solve problems. And sort of if you choose to you could graduate to become an engineer one day.

Swizec (09:54):
Yeah, exactly. I think the best way to become an engineer is kind of by necessity. What really got me personally, to move from being a developer to an engineer is just having an app that lives a long time. And that I have to keep maintaining. A lot of side projects are you build it and it's amazing and then you stop working on it. But if it lives, if you can force yourself to making changes, keep poking at it over a year or two years or three years, you're going to automatically think more like an engineer.

Alex Booker (10:23):
I can't help, but shake the feeling that being a developer nowadays is about gluing different tools together. You might be using a CSS library, maybe something like Tailwind. When you think about authentication, people will use something like Passport and Node or Devise with Rails. They might even use a software as a service provider ,like Auth0. Would it be fair to say that the people who were like building React, who are building the database engines, who were building the deep, nitty gritty, secure, authentication code, maybe they sound more like engineers than the people who were like gluing things together?

Swizec (10:57):
A joke I always make, is that a lot of these fancy sounding software engineering jobs, especially at big companies, the vast majority of them boil down to JSON bureaucracy. You're taking a JSON payload from one API, you're passing it through a data pipeline of some sort. It may be a massively distributed, super amazing something, something pipeline, or it could just be a flow of five different functions on a server or even on the front-end. And then you are spitting out a React app or a different JSON payload. So a lot of it is just codifying the bureaucracy of a company, which is engineering, but is usually not the fun kind of engineering. And what you said, where you have these highly focused teams of experts who work on a game engine or on a React framework, or who figure out Tailwind.

Swizec (11:46):
It's engineering but it's almost more academic in nature from what I've seen. And from what I've talked with, these people, it feels a lot more like an academic research project. That's you are engineering over time and that's actually seeing customers. So it's better than academia in that case, but it's a lot more focused on a very specific area. I think Dan Abramov famously has a blog out or an article about everything he doesn't know because he's, "Oh my God, he invented React", which he didn't. He works on React now. I think his Twitter bio for a while was, "I didn't invent React." But you know, everyone looks up to him, "Oh my God, he's Dan. He has all of these great ideas." Turns out that a lot of his work, while super interesting, is also very limited in scope. He's really good at fancy JavaScript tricks he's really good at really deeply understanding, React as an ecosystem, as a library and he's really good at talking to people. Which is amazing because I think he's probably the best person at that on the React team.

Swizec (12:44):
But when it comes to breadth, he has a lot less of it because he's just been focusing on a very tiny sliver of the ecosystem for a long time. Or another good example is, I remember his Twitter handle, developit . He created Preact and I think he works at Google now. He's a really good broad engineer because he's used to work at startups and he used to run his own startups. But lately he's mostly been focusing on really tight JavaScript optimization. So he had a really good thread recently about, when it's better to write ES5 JavaScript code rather than ES6 and compile it, because the transpiler or the compiler, isn't smart enough to use the optimizations that you can do when you are tightly optimizing code yourself.

Swizec (13:27):
That is amazing. There are probably five companies in the whole world who need somebody with that level of expertise in JavaScript optimization. That's more intellectually gratifying and it's more interesting, but it's almost so tight and so deeply focused on a specific area that it's almost has less engineering than most of the engineering jobs that are just JSON bureaucracy.

Alex Booker (13:51):
If you are enjoying this episode of The Scrimba Podcast, please consider sharing it with somebody you think will find it helpful. Either a friend in a DM or just on Twitter and social media in general. I am always looking out for tweets to retweet about The Scrimba Podcast. Really, when you tweet or share the podcast, it shows us that you're enjoying it and we should keep bringing on awesome guests. Word of mouth is a single best way to support a podcast that you like. So of thank you in advance. Next week, I'm talking with Maeling Murphy who is a self-taught developer and part-time Scrimba student who recently got their first developer job. Woo hoo. Seriously, Maeling had a very structured and well thought out plan to getting her first developer job. Which I hope you will learn a lot from. She made a lot of use of social media and a variety of very interesting resources.

Alex Booker (14:39):
One thing that really stood out to me about our chats is how many golden resources she shared that might help you on your journey. So definitely look forward to that. Just make sure you subscribe to The Scrimba Podcast and your favorite podcast app, be that Google Podcasts, Apple Podcasts, or Spotify. You can even subscribe to the RSS feed, if that's your style. Back to the episode with Swizec. How does a new developer kind of measure their own ability? Because I think once you join a team, you might have a reference point. You'll sort of again, idea about why you're struggling compared to other people, maybe why you're thriving, but when you're by yourself and you're looking for that first job, it's hard to know are you an intern, a trainee, a junior? Maybe you've been doing it for a couple of years and you're, maybe just beyond the junior phase, you just haven't really had a job yet. How does someone measure that skill, do you think?

Swizec (15:28):
I've been thinking about this a lot lately. If you are in a sport you're always measured against others and there's a clear hierarchy and you go through that hierarchy and you know how good you are. If you are a musician, there's a relatively straightforward path of what happens when you are a garage band, then you assign a label... And then at least from the outside, the path looks pretty defined. For engineers, maybe it's because I'm very in the industry, the path just looks like a frazzled disjointed tree of different options. That may be just because I know all of the options. But I don't think there is really a good way to measure yourself. There's no absolute skill level. There's nothing that says, "Oh you are absolutely great." I think it depends a lot, first, on what is the vision for your career?

Swizec (16:15):
What is it that you want out of your career? What kind of engineer do you want to be? If you're more of a freelance kind of person, more entrepreneurial, your idea of what's good might be how fast can I build something? How can I give myself a challenge and build it? If you're interested in more of an academic career or more what we said earlier, those really highly focused, specialized people. It's what is the toughest challenge I can solve? How can I find a really good, challenging problem and noodle through it over weeks and months and solve it. If you are interested in a more Dev roll direction it's, "Am I able to really quickly pick a new technology, write a tutorial about it in a way that resonates with others and get it out there and get it actually read by people." So the main problem is that there's no one measuring yardstick.

Swizec (17:03):
There's a lot of them, depending on what it is that you want. One easy way to measure is to start getting involved in Open Source. The fundamental thing that is equal to all of them is, can you solve a problem using code? And you got to just get opinions from other people and they will tell you, "Hey. Yeah, this is great code", Or, "This is not great code." And even on a team, like you said, you kind of get a subjective feel for who's a better engineer, who's a worse engineer. But it depends on the area of expertise.

Swizec (17:32):
And I think a lot of it is very retroactively. It's easier to test. Like if you give a similar project to different people, you don't know exactly why, what makes somebody a better engineer or a worse engineer, but you can definitely see on a team that feeling of, "Hey, if I give it to this person, it gets done on time and doesn't have bugs." And if I give it to that other person, like they're approaching it the same, but it just doesn't work as well. It just has more problems has more issues. It's just, evidently some people are better than others, but it's really hard to say what it is that makes them better or worse.

Alex Booker (18:06):
Is it possible in that scenario, though, the two people you described are just better at different things? Being a successful programmer, isn't only measured by the code that you write. You might be the person that gels everybody together that might be your personality. You might have really good ideas. You might be able to ask very good questions that unveil potential problems with an implementation before you go too far down that path. You might be an advocate for starting small and dreaming big and bring a sort of principle and an attitude to the team that can really help. All kinds of things. Right. And yeah. In that scenario, sorry, is it a case that is to do with expertise or do you think these two people could be doing the same job essentially?

Swizec (18:44):
Yes. There's definitely a lot of expertise. When you look at somebody's code, you can kind of tell, "Oh, you grew up building Java", or, "Oh, you grew up building C++", or, "Hey, you definitely learned on JavaScript", but it may have been old JavaScript. You can see a lot of that. Part of it is experience. Part of it is skill. I think a lot of it is the attitude of those asking questions. A lot of engineers, especially junior engineers can be very eager to just go and start building rather than, "Hey, slow down. First, ask questions. Figure out what it is exactly that you're building." When I'm interviewing people my favorite approach, and this actually translates pretty well to real life is, here is a story, here's a user story, here is a stubbed project, take it away. And I sit there and I see how they approach it.

Swizec (19:32):
And one of the biggest predictors of whether the interview is going to go well or later in the job, if the project is going to go well, is how many questions they ask after they get the user story? You can never capture all of the details in a user story, because if you did capture all of the details in a user story, then you might as well just write the code yourself. That's the point of an engineer or developer is I give you a fuzzy problem or the business gives you a fuzzy problem and you figure out how to define that problem well enough so that the computer who cannot think can actually solve it and work on it. You're going to have a lot more problems later if you're the kind of person who just starts building and then is like, "Oh wait, shit. I planned myself into a corner now we have to figure this out."

Alex Booker (20:14):
I think I'm starting to notice a theme, which is that when you described that impressive candidate at the beginning, what impressed you so much is that they learned, they must have listened carefully and taken your feedback to heart. And now what you're describing is that if you are presented of two juniors with equal coding ability, you have to their sort of soft skills or attitude to differentiate them and the person who kind of dives deep into a problem before taking time to understand the requirements. I suppose, what I'd like to ask you about is sort of the importance of soft skills as a junior developer. But I also wonder like how much of soft skills are teachable?

Swizec (20:50):
That kind of depends on exactly what kind of company you work at, Google, from the outside it looks like their strategy is we're just going to scoop up juniors straight out of university or high school or whatever they find them. We're going to scoop them up and see who survives until the next round or the next leveling. This is a really good quote from F1, the boss of Red Bull, "You get these drivers and the pressure just builds and if they're good, they survive, if they're not, we kick them out." So there's a lot of that, which I think is kind of toxic. I don't like that approach. I like to approach people from the perspective of everyone is coachable, everyone can learn. But it does take exposure over time. It takes getting hit on the nose, getting things wrong and that's okay, that's expected. Especially as a junior developer, it's expected that your first project is not going to go amazingly.

Swizec (21:41):
And it will be weird to take somebody who is fresh and give them a really huge project that basically crushes them under the weight of how complex it is and expect that to go well. That is just really poor management. But it takes that exposure over time. Some people are more coachable than others, but I think that if you think about this, if you like subscribe to a newsletter that keeps reminding you of these things, it keeps reminding you of soft skills. I personally read a lot of books about it as well. And you can see that with time, you do grow. Some people call it growing up, you just get older, wiser, you see more things. But I think it's fundamentally coachable. How fast you can be coached on that, probably depends a little on your mindset and on your upbringing. There's a lot of research on, I think its static mindsets versus growth mindsets, but I think that everyone can be shifted to a growth mindset and everyone can become the person who is coachable, who grows, who learns. It just takes time.

Alex Booker (22:41):
I think it's Christian Horner, the Red Bull guy, and yeah, that's brutal. But I suppose that's the elite of the elite. There's something we like 10 Formula One cars possible. And so you really have to have that cutthroat attitude. I don't think we need to bring that to developers. So I agree with you completely. I just want to touch on something you mentioned a few minutes ago about sort of having a vision for your career. I know you wrote about that and you created a sort of visualization to go with it. Can you tell people a little bit about it? Because I is super relevant to our discussion today.

Swizec (23:11):
I actually got that career vision from this book, Richard Hamming, The Art of Doing Science and Engineering. I'm reading it slowly because it's a very dense academically written book. But Richard Hamming was, I think hired as a professor at some Naval academy back in the early thousands or even in the '90s. And he said that he wanted to create a course for people who are technical, who are going to be future engineers focused more on the soft skills. And one of the things that he taught was that as the technologist, as the engineer, you have to have a vision for where the field is going to go. Yes, you are solving today's problems, but you also have to think about where the whole field is going to be in 20 years and kind of solve towards that. If you want to be a, what he calls, "Great engineer slash great scientist."

Swizec (24:00):
And I think that applies to careers as well. Where if you're very responsive, if just do whatever comes your way, you are going to kind of spin around in circles. The metaphor that Richard Hamming uses is, it's a very dated metaphor because it's a drunk sailor who walks around in circles because they're doing a random walk in random directions because they're drunk. But then if there's a pretty girl, they kind of eventually wobble towards the pretty girl. Now I know that is a... In 2021, that is a very dated metaphor. But the reason Hamming used it is because random walks are a mathematical concept. They're an algorithm, not really a machine learning algorithm, but it's a huge field of study in mathematics. How can you take a random process and control it so that it gets a certain outcome. That's essentially how the difference between a career and a career with vision works.

Swizec (24:51):
If you're just working in your career, you're like that drunk sailor taking random steps, and on average, you're never going to go further than the square root of the number of steps you've taken. You're going to be moving around and you're going to be working a lot, but you're confined to where you started. But if you have a vision, if you have just a tiny bias towards a certain direction, when you make those random decisions, over time, you suddenly start wobbling towards that vision and you're still going to get it wrong. You're still going to misstep. You're still going to miss. You have a direction at least. I think the visualization I made had a 1% or a 2% bias towards a certain direction. And you can see that as the number of steps grows, you very quickly start progressing towards that vision and in a specific direction.

Alex Booker (25:37):
What is your vision Swizec?

Swizec (25:39):
So I've had a kind of evolving vision, which I think is also important. You do have to change your vision as circumstances change. I started in Europe and the beginning of my career was at a web agency, essentially churning out websites and kind of working on some interesting things. But mostly it was very treadmilly. And I was like, "Wait, I'm reading about all these people from the U.S. who have these amazing careers and they get paid ridiculous amounts of money. I want to have that kind of career." So that's been my vision to try to solve interesting problems, big problems. And I basically have three rules for my career.

Swizec (26:16):
I always want to work on problems that are interesting to me. I always want to work with technologies that are interesting to me. I think that's kind of the same role. I always want to work for companies or create companies where the end user and the person who are paying us are aligned. So that our incentives are aligned. Means no crypto scams, no advertising stuff. That sort of thing. I think the third rule was basically to, whenever I stop having fun to go find a bigger, more interesting challenge.

Alex Booker (26:45):
I really want to encourage people to check out the visualization in the show notes, because it's essentially an illustration of how you can feel productive doing a lot of work, but not getting anywhere. But if you have even the smallest degree of focus and idea about where you want to go, you can actually make much more progress than most people. And to your point, I think yes, a vision should be evolving because you're always kind of learning new things, right. And if you don't update your vision or your strategy based on the new data you have, you're not really doing yourself justice in my view. But the most important thing is that you at least have some goal to begin with. Even if it's not perfect, because you can always refine it later.

Swizec (27:20):
Yeah. The other metaphor I use for this are hill climbing algorithms from the machine learning space. You find a hill that is the solution to your problem in machine learning. And you make an algorithm that just biases towards getting higher on whatever metric you found. And then when you get to the top, you notice that there's nowhere to go except down, but you now have a higher vantage point. So you can spot a bigger hill in the distance. You can start going towards that. That's how I adjust my vision. You get to the top of your current hill and you now have a better vantage point, better resources, better vision. You can see you've experienced something and you can spot a new hill in the distance and start moving towards that. It does sometimes mean that you have to go down for a bit before you can go up for a steeper taller hill, but it's a good way to spot things.

Alex Booker (28:07):
So Swizec, you've been working a lot on a project lately called Senior Mindset. Can you tell us a little bit about it?

Swizec (28:13):
Right now It's a series of emails. You can find it on seniormindset.com and the idea is that, or rather it grew out of seeing a lot of people come into our interviews, thinking that their seniors or even having the senior title, but not actually being seniors. When you start digging in you very quickly spot, this is more of a mid-level engineer. It's very easy to get the senior title. You just join a growing company and if you wait around a couple years, you're going to be senior engineer, EA, but you're not really a true senior yet. That takes a different kind of thinking, a different kind of insight. Some battle scars really help, but they're not necessary. And I've been writing this email series and digging around how I could turn it into potentially a book or a course of some sort. But that tries to teach you that mindset over time with a lot of examples, a lot of real world learnings and people are saying that they're really enjoying the reading.

Alex Booker (29:09):
What do you think the juniors should know about senior developers? I guess if what you're describing is what the best seniors look like, maybe by talking about it for new programmers, they can... An interview is a two way street, right. They can look for these qualities and their future teammates and their potential boss.

Swizec (29:23):
I think the quickest way you can see if somebody is more of a mid-level or junior engineer or a senior engineer is to ask them about DRY the Don't repeat yourself principle. And I feel like the more senior the person, the less they care about their code, not being duplicated and writing abstractions, because it's so much easier to fix code that is verbose, but easy to read than code that is super tight and brilliant and hard to debug and understand.

Alex Booker (29:55):
I mean, I spent so long trying to make sure I never duplicated anything. I would have so many, one line functions or two line functions or half a line functions. But then I learned about something called, "The rule of three", which is a good sort of principle to abide by. Which is that, until you've duplicated yourself three times, it's really hard for you to know what a good abstraction looks like. But to be honest, I'm not much into code nowadays. I'm not working as a full-time developer, but I can say at Scrimba I've looked at the code base and things like that. And it's remarkably simple and no unnecessary duplication, but some of the things look a little bit verbose, but it's so isolated. Which makes it so much easier to understand and follow and if something goes wrong, to fix. But yeah, that's a cool question to ask.

Swizec (30:40):
Another good one on is... I don't know if it has a role, but there's a lot of codes that looks similar, but is actually doing different things. Logically speaking or semantically, it's doing different things. And when you try to make an abstraction for all of those, you will very quickly shoot yourself in the foot. And that's also something where a junior or mid-level is going to say, "Oh, this code looks the same, but I better write an abstraction." And then all of the different parts start evolving in different ways and suddenly your beautiful abstraction takes 10 billion variables to switch between different behaviors. And, "Wait, why did we ever put this together? It makes no sense." The more senior you are, the dumber and simpler, your code starts looking, but it's actually, this may sound terrible, but it's like Einstein used to say, "If you can't explain it simply or if you can't write your code simply, you probably don't understand the problem enough yet."

Alex Booker (31:33):
Doesn't another quote. I think it's by Hemingway something like, "I didn't have time to write a short letter. So I wrote a long one instead." Thank you so much for taking the time to join us. I on The Scrimba Podcast.

Swizec (31:44):
Yeah. Thank you for having me.

Alex Booker (31:47):
That was Swizec a senior engineer from Silicon Valley, author and course creator, also the creator of the Senior Mindsets newsletter, which you can find a link to in the show notes. As well as all of Swiss's great stuff. This episode was edited by Jan Osinovic and I am your host, Alex Booker. You can follow me on Twitter @bookercodes, where I share highlights from the podcast and news by Scrimba. Remember to subscribe and I will see you next week.