Mark Tellez Interview - Host of Devmentorlive on YouTube

If you're like me, you spend part of your day surfing the Internet looking for project inspiration, “how to” articles, or just seeing who's doing what. The other day I was making the rounds on YouTube and I came across a channel called Devmentorlive. The host of the channel has a variety of code-a-long projects as well as shorter, topic specific videos. I clicked on a video and started watching. What made this different was that it was a recorded live session whereby he asked the viewers what they wanted to make. There was no pre-made project. He tossed out a couple of ideas, a consensus among the viewers was reached, and it was off to the races. Now I know what you're thinking, “Man, there are other YouTubers that live stream”. Yes, and I don't disagree. Typically though, they have a project already in mind, and, in most cases completed. They're reading off of one screen and retyping the code on another. And that's fine. I have no problem with that. It's a much different beast though to ask, “What do you want to make?” and start hammering it out live. In any even event, this caught my attention.

As the video progressed, the host took time to answer questions coming through the live chat feed. What I really enjoyed about this was that he kept the questions on topic. For instance, this particular code-a-long was about React. It wasn't about Angular. It wasn't about using MongoDB. It wasn't about using Redux. It was about setting up the skeleton of the project using React, react-router-dom and react-router. As the project continues (e.g., a multi-part video series), then the floor will be open to questions regarding the specific tasks at hand.

From what I know, the host has about 25 years of professional coding experience. This shows in his answers: to the point with solid explanations. Refreshing in my opinion. I was curious to know more about this developer located in Mexico City, Mexico and decided to reach out to him for a brief interview.

Q: How about telling me a bit about your background. For instance, when you started coding professionally, the kinds of projects you've worked on and so forth.

Mark: I have been doing this since 1997 professionally. I started out just building websites using HTML, CSS and Javascript. Well, we didn't have a lot of CSS back then, it was mostly inline stuff. I did this mostly for local companies. I remember the first project I got that paid more than $5K was for this guy who was selling water filtration systems. I think he got suckered into a multi-level marketing kind of thing (laughter), and his garage was filled with these things. His wife was like “you have to sell these”. He had no idea how to do it and was afraid to go door-to-door. He came to me as said I need a website with a shopping cart. I was like, well it's really not easy to get a merchant account to do the on-line billing. Billing back then was really difficult. There was no Paypal or anything. He said that's fine as long as we can show the water system and we can have people put it in their cart. Then an email gets sent to me saying this person is ready to get closed on the deal. So I helped him set that up. I built the shopping cart out of cookies because there was no server stuff then. I just kind of went on doing that stuff for a while, like being my own guy setting up sites for companies. Doing lots of computer repair. Then eventually I got hired by a company called Teach dot com. They were based out of Redmond, WA. I moved up there and worked for them about a year. Then I got a job at Intel back in San Diego. I went down there are started working on the backend like ASP, VisualBasic, some SQL stuff and other things. And since then just been doing this for basically my entire adult life. I know C++, C, Pearl, Python, Ruby...a whole string of languages but one that I've always really enjoyed is Javascript. I'm one of those guys that can write Haskell and C++. The Haskell and C++ guys go like this (covers his nose) when I mention Javascript. But I like dynamic languages. I think if you have good coding habits, dynamic languages give you a lot of flexibility that you don't have in a static language. Plus it's in every browser on every computer. If you're trying to make money using it, it's a perfect way to go.

Q: What is your vision for Devmentorlive and how do you differentiate yourself from other YouTube channels?

Mark: I provide ReactJs and JavaScript mentorships, whereas most of these channels earn through ads and the occasional courses they sell. I have a course that I'm working on now, too. I pride myself coming from practical experience. I mean, I didn't go to university. Didn't finish high school. Everything I've ever learned was because I had a practical need to learn it. And in the early days it was mostly from books, because you know YouTube didn't exist then. The point is, instead of going to the React documentation where they list everything by feature, such as useState, useEffect, useReducer, etc., but it doesn't really tell you how or why you would use any of those things. It just says this is what it is, and this is what it does. So it kind of reads like a dictionary. The way I teach it is that I don't say here's useEffect, useState, etc. I say what do you want to build? OK, you want to build a shopping cart, so we start building that. Of course you've got to use some state to do that. Then we run into where we need side-effects. Then it's time to break out with the useEffect. I don't ever teach something without there being a reason behind it. I don't have videos that are like, “everything you ever wanted to know about useState”. It's like let's build Tetris. And in the process of building Tetris you'll learn about component state, application state, global state, etc. Here's the reason why I chose functional programming over object oriented programming and things like that. I think that's the big differentiation. Also I'm one of the few guys you can actually book time with. So if you follow Brad Traversy, who is a friend of mine, there's no way you can get an appointment with him because he has a million subscribers and he just doesn't have time to do mentorship. And, he doesn't like teaching that way anyway. He's the kind of guy where I want to put together a video and just give it out to the world and go to sleep. Whereas I'm much more people oriented. So I like spending actual time with people and getting to know them. Getting to know what their goals are. Getting to know what their needs are. And then trying to craft something that fits what they want. I guess it's because I straddle the fence between programmer, photographer, marketer, sales. I can speak to people. I can speak to computers. Not a lot of developers can do that. Most of them are very computer oriented.

Q: Most of the readers of my blog are Junior developers. They're either trying to get their foot in the door, or they just got their first job. Based on your experience and generally speaking, what are most junior developers lacking in terms of skills?

Mark: The ability to think through problems and conceptualize them. And how to interact in a business environment. Coders think they get paid to write code, but they don't. They get paid to solve business problems for people who write their paychecks. So a junior developer is likely to spin their wheels trying to solve some technical problem that they probably could have just side stepped, but they're too stubborn and they just want to solve the problem. And it's generally better to stop thinking about the technical problems and start thinking about practical solutions. So if you're banging your head against the wall, employers don't really enjoy it when you hit them with 30 hours of work and don't show any actual progress. They would much rather you come at a problem from a different angle. So what I try to teach is..like I'm about to start a Tetris series this afternoon. It's not going to be watch me build Tetris. It's going to be me talking about, well these are the pieces in Tetris. They have x properties and you've got to be able to flip them, rotate them, etc. So what is the conceptual problem here? Well it's a geometry problem. So you've got to be able to figure out what's the size of a block. What kind of blocks do you put together to make the pieces? So we're going to spend two hours on it before we actually have a piece moving left and right on the screen. We're going to make it so that it's basically an algorithmic way of designing the pieces. So that you can scale it to make a bunch of custom pieces as well.

Q: I see a lot of junior developers posting on-line how much time they're spending on HackerRank or LeetCode preparing for interviews. In particular, the dreaded whiteboard whereby they'll be asked to traverse a doubly linked list or something of that nature. In your opinion, is it more advantageous for junior developers to spend time building projects or should they be focusing their time on test questions in preparation for interviews?

Mark: It depends on the type of job they're going for. If they're going for a front-end job, then they shouldn't be building projects anyways because projects take a front-end, back-end, an API, network traffic, optimization, databases, etc. If you're applying for a front-end job my advice to people is build yourself a portfolio. Don't build yourself a Facebook or Twitter clone. Your Twitter clone is all skin deep anyway. It doesn't really do anything. It doesn't have any real customers. It doesn't actually service anybody. It provides nothing. Hiring managers and recruiters don't want to dig through a garbage clone that doesn't actually do anything and try to figure out what features are there and what features are not there. It also shows that you don't understand what business is about; for instance, providing real solutions for people. I tell people this. Write a blog post, and in that blog post build something. Like on YouTube there's a slider that serves up four videos. If you click the right arrow it slides over and there are four more videos. Build that. Build it at 100%. In fact, build it at 120%. Never go 100%. 100% is what is expected of you. That's not how you stand out in a crowd. So take that component and build it all the way through. Make it tactical as Hell. Make it beautiful. Make it seem like it could be sitting on YouTube or Facebook. And then write a blog post describing exactly how you built it and what problems you ran into and how you solved it. How did you plan the project? Why did you pick the components that you picked? All of that gives a hiring manager much better insight as to what you can do and how your brain works, and what you can do for the business. Also, it proves that you didn't follow some tutorial, “here's how you build...”

Q: In one of your videos I watched, you mentioned a dislike for Typescript in the context of using it with React. I know many YouTube instructors gush over Typescript as though it were the second coming. Could you talk a little bit about your position on Typescript?

Mark: My automatic dislike comes from the fact that it's a Microsoft product. So I use some Microsoft products. For instance, Github. Although I was on Github since 2008. I was number 47 or something. Github wasn't from Microsoft which is one of the reasons why I liked it, and they haven't destroyed it yet so I still use it. I'm a VIM guy. I've been using VIM a long time and I used Emacs before that. I really like what VIM allows me to do as far as like navigation, automation and doing stuff really fast. Visual Studio Code allows me to do all that stuff plus a lot more. It's a very well put together editor, and it's not built by your standard Redmond, WA team. It's its own thing. Like it's not Visual Studio. I worked with Visual Studio forever in the 2000s when I was doing .Net development and it's a terrible, terrible IDE. Visual Studio Code was built by independent contractors for Microsoft. And almost all of them had a design background. So that's why it's a damn good piece of software. So I use it. I'm not the kind of guy that hates Microsoft so much that i'll spite myself and not use a tool that's really good just because it has the Microsoft name on it. But Typescript...so I have history. I've been doing this for a long time and I remember in the early 2000s when we had the browser wars and Microsoft was doing some really shady shit so that Internet Explorer stayed at a 97% user base. It was really difficult to work with. Microsoft first had JScript then they had VBScript. And then they had another version of Javascript called Vfour or something. And it made it so that you had to write code...well it's like the developers for phones these days. You got to write code for an Android. Write code for an iPhone. Why are you going to keep all these code bases? It doesn't make any sense from a technical perspective. So we had the same problems with the browser wars. You had to write for Netscape. You had to write for Internet Explorer. You had to write for whatever people were using on Linux at the time and your code base ballooned and there wasn't a lot of code sharing between them because you had write them in slightly different languages and stuff. So I remember those tactics. What really happened is Microsoft has a policy of first embrace and extend...this is like literally in the Microsoft handbook. They speak about it at board meetings. Embrace and extend which means if you find something that a whole bunch of users use, embrace it. Try to be the wolf in sheep's clothing and tell the users how awesome everything is and you can keep what you already have, it's amazing and we love it too. We're right there with you. We're on team “You”. And then they do something called extend which means now we're going to make it so that it's no longer compatible with the thing that you originally liked and the thing that you originally loved. We're going to change just enough of it, that if we can corral you off we can lock the gate and not let you back in. Now you're ours. And Typescript is exactly the same damn thing. They said, OK what is the most popular language in the world? Javascript. Who has the most developers in the world? Javascript. OK, so that's obviously the largest customer segment, so that's the next thing we're going to attack. So how do we do it? We're going to embrace and extend it. We're going to say look we created this thing called Typescript and it fixes all the things wrong with Javascript, which it doesn't. And, it's compatible with Javascript. Which it's not. It's the same thing as Javascript, only better. Which it's not. And so what they did is they got all the young bucks that are like “everything that is new is better than the stuff that is old and we're going to jump from technology to technology because I'm interested in what's trendy, not interested in what works”. And so they got those guys. And now they think that Typescript is the second coming, but really what it is is it's like going to the bowling alley and they put bumpers on the gutters. It's a way of enforcing you to write three times the amount of code that you should have to write, so that you have safety in your code. Javascript is a dynamic language. Dynamic languages don't have safety built in. They have power built in. Safety comes from your programming habits. So it's the difference from being a craftsman and being a somebody who just throws shit at the wall and waits for stuff to stick. If you like throwing shit at the wall, Typescript is probably great for you because it's going to have all these things where you have to write extra code to define interfaces and define types and objects, classes, etc. All things that don't exist in Javascript for a reason. Javascript is not an object oriented programming language. So that's why I don't like Typescript. I also don't like writing more code than I have to. I hate dependencies, because dependencies can create security problems. They allow you to have your sever taken over because you installed some bad NPM package that's now going to start executing shit. It also means it's like rather than learn how to do something, I'm just going to copy someone else's code so I never learn how that thing works. So I never have to learn how encrypting user passwords works and why it's important and how to do it properly. So I don't like it for a lot of reasons. I like having really small codebases. Typescript is the opposite of that. It balloons the amount of code you have to write. Also it makes things more complicated. If you're a new Javascript programmer why would you want to go straight for the complicated?

Q: You had mentioned in the same video something along the lines of, “you know you're in a dev shop with a lot of junior developers when you see mongoDB used for everything”. Tell me a little more about that.

Mark: Again, I'm not a religious guy. MongoDB is not the worst thing in the world and it's not the wrong solution for all things, but it's definitely not the right solution for all things.

So what is MongoDB good at? It's good at things like logs. It's great for logs. Logs are not relational data. And it can be used across many many servers for scaleability and it doesn't matter because you don't have to see all the logs at the same time. You can have millions of records which is perfectly fine. Chat messages, another great place for MongoDB. Because you're not talking about relational data. You can have thousands of messages going back and forth and it scales really nice. But, MongoDB is just a flat file database that has some bells and whistles. Flat file databases were invented in the 1960s. And then people realized that the problem is you code this database for a while...and you change the schema on the fly. Then you get a bug in your code and it starts writing weird data to the database that's not in the right format. Then you fix the bug and now you can't read any of the data because the data was written to the database in the schema that the bug was in. Or change the way the code works over time and slowly the schema gets written differently each version of your software. And before you know it you can't read the old data anymore because you don't have the code that reads that data. So then you have this giant bloat where you've got to write code that works with all these different versions of schemas. It's the same collection, but it's constantly slightly changing. So basically you're getting back this giant JSON hash, but the keys are not consistent. The groupings and the relationships are not consistent. Then you've got to have five or six different mongoose models just to deal with all these different changes. So you'll have a person model, then V1, V2, V3, etc. That doesn't tell you anything about the schema. It just says the schema changed, but not how. So in the 1970s someone said, Ah we can make a relational database with schemas and that solves our problem for flat file databases. Fast forward to the 2010s and junior developers who don't know their history and say “OMG this MongoDB is the coolest shit in the world”. And you're like no, this was already invented in the 60s. And it works great for some things and utterly fails at others. That's why we have PostgreSQL. So if you're going to be writing relational data, don't store it in MongoDB. Store it in Firebase or PostgreSQL or MySQL. Or even Microsoft SQL if you like torture and pain. Junior developers say, “well all the Javascript tutorials out there say to use MongoDB and so it must be good”, so everything becomes a MongoDB.

Q: A common question I hear from junior devs is “what should I have for portfolio projects?” As a senior developer can you offer some suggestions?

Let's go with what doesn't work, because it's easier to figure out what works when you first get rid of what doesn't work first. There are two groups of developers. There are developers that have no professional projects. They have never really built something that got deployed to the wild and was actually used by people (e.g., bootcamp grads). They say well I don't have anything to put into my portfolio. No, it's not true. Let's go with front-end developers. Back-end developers would be building different things to show in their portfolio. So you're a front-end developer. Build a really nice login form. Maybe it doesn't have a backend, but it simulates that it does. And it works well when you're on a mobile device and running at 2G bandwidth Make it with a really nice UI that shows off that you understand the nature of the asynchronous web, the nature of UX design, how to create something users can users can use and actually understand it without having an instruction manual. Another project. Anyone can create a drop down. It's built in to HTML. But what if you made a drop down that has checkboxes next to the items so you can check them off? Or maybe each item has child items and if you check some of the child items, but not all of the child items. Normally checkboxes have two states: on or off. So what if you have a parent that has a checkbox and you have children that have a checkboxes, and you only selected two out of the three children? How would you display the parent checkbox? My answer is that you will fill it half way to show that some of the things have been checked, but not all of the things. So now you've created a checkbox with a third state which is indeterminate. It's not off, it's not on. It's somewhere in the middle. And put a filter in the top of that drop down so that if there's a thousand records you don't have to scroll through a thousand records. You can start typing a Joe and all the Joe's show up in the dropdown and you can check the Joe's that matter. So that's a nice interface. How about a list of cards. And when you hover over the card the card flips around to show you more data than you can readily see right away. So you're not forcing the user to make another click. You're making it really easy to show more data than you have real estate for. And not just in a functional way (e.g., I can now show twice as much data in the same space), but also in a damn cool way because they see the card flip around and the colors change and so forth. Like flipping over a baseball card. So a person who has no professional projects, that's what I would say to do. Build stuff to show you can solve business and user needs. Do it in a nice UX friendly compatible way that catches peoples attention. If you're someone who has worked for large companies like Microsoft, don't just put a link to Microsoft. You didn't build that. That was the efforts of millions of developers over many years. Link directly to the thing in the site that you built, if it's readily accessible. Usually it's not though. If that's the case, rebuild it and put it in your blog post.

Think like the three guys in a garage who want to build something fantastic. Think like the guy that wants to make money today, not in six months. Craft your engineering mindset around that.

Q: Another unique service you offer is 1:1 tutoring. Can you tell me more about this?

The first time I get together with somebody I find out what are your goals. In four months where do you want to be? What do you want to have built? What do you want to have done? What kind of money do you want to be making? Where do you want to work? Everyone is different. And then from there we talk about where are you at skill wise and where do you want to be skill wise? I'm pretty good and being able to figure out really quick just by having them write some code. Then we pick a project if they don't already have one in mind. If they don't have one, I ask what do you do when you're not programming? Do you play guitar? Play frisbee golf? Do you hunt? Do you fish? Let's make an app that will help you do what you already like to do, because you'll wake up in the morning already excited about that thing. It's already aligned with all of the things you're interested in. If you just try to build a Twitter clone, you'll get bored in a couple of days and you won't want to touch it again. So we go down that path. We work for an hour. Some people do two hours,but most people do one hour. It's all they can absorb. You're taking an expert and your trying to shove all that expert knowledge into a newbies head. They can only consume about 10% of it. We also record the session so they can go back and watch it three times if that's what it takes for them to get 80% of the knowledge. I do the coding. They watch and I talk them through everything that I do. The reason for this is as a junior programmer you can spend 30 years banging your head against the wall to try to get to where I've gotten. You've got to make all those mistakes along the way; all of that pain and torture. Or, you can do what we did for thousands of years which is the apprenticeship model. If you're going to work for a brick maker or a brick layer, you don't lay a brick for five years. You mix the mortar. You clean up the horse shit. You cary the tools. You cary the stuff up and down the mountain. You bring the water to the guy who is actually doing the brick laying. The rest of the time you're not doing that stuff, you just watch the master brick layer lay bricks. So before you ever lay your first brick, you know a hundred things about laying bricks. So when you lay your first brick,it's right, it's correct. It's architecturally sound.

Until you've learned how the master does it, you have no business trying to improve or improvise it anyway. So that's the way I work with my students. I show them how to build stuff. And I talk to them the whole way. I ask them questions. I'm making sure they're understanding what I'm doing. I find out if I need to go slower or faster. I explain what I'm doing in detail, because then they don't have to read the 50 books that I've read on functional procedural systems coding. Because I can say you'll only need 2% from this style, and 3% from this style, and 10% from this book, and 2% from that book. And I can just boil all that down and put it straight into your head. Then after they've been working with me for like two months, I start letting them write small pieces of code. I still write all the new stuff I'm trying to show them, but then what I want to see is can you replicate the things that I've shown you twenty times now. And can you do it fairly easily? Then the session ends and I say OK here's your homework. I want you to do this, this, and this. This is the part you have to bang your own head against the wall a while. Which also usually makes them appreciate coming back to me a lot more because they were working for ten hours and got nothing done. They work with me in twenty minutes and they got done more than they would have gotten done in five days. So this does two things. It helps me build my brand and my sense of authority. It also shows them the value that they're getting out of their $80 an hour by working with me. But also it lets them do that time when they're banging their head against the wall. That time is important too, even though nobody really wants to do it. Then I say during the time in-between our sessions I need you to get a notepad and write down all the problems that you had. All the roadblocks. And if you run into something and figure a way to solve it, make sure to put that in there too. I want to hear about it. The next session we're going to start with your notes. We'll start answering the questions to things you need answered. Talk about the roadblocks you ran into and how you tried to solve them. Also, let's hear about the victories you had so I can give you some praise. This is a hard industry. First off, you have to have aptitude. Some people call me a gate keeper because I'm like look, you can't do this if you're not intelligent. You can't do this if you don't have a puzzle solving mind. Hard work and education will not make you a programmer. You're either a good programmer who doesn't know how to program or you're a good programmer who knows how to program. Or you have no business being a programmer. So, some people I actually turn away during the mentorship interview or even after four or five sessions. I talk with them and I say look you're not actually getting this. It's not going in your head. You're not able to recreate what we've learned together. And in-between sessions I can tell that you're out smoking pot and drinking with your friends and playing video games. I can tell that you're not coding and in this industry you want to stand out from the rest people if you want to get a job. You have to be able to show that you have the aptitude, the drive and the will to do it, and interest. About 10% of the people who come through my door at some point we have that discussion. I'm not interested in wasting their money or wasting or any more of their parents money. Or having them be very unhappy.