Learn why some people are able to have such high output
Side projects are important in our line of work. They sharpen our skills and sometimes they can even take off and lead our career in a new direction. But seeing people create these amazing projects over a weekend can be demotivating as a junior developer. "How can they do that when I'm five days deep into a todo app? What do they have that I'm missing?"
The answer might be a disappointment to some, but often it is because they have 10+ years more experience than you do. But don't let this demotivate you! You don't lack intelligence, you just have more experience.
If you want more advice on side projects and dealing with the influence of others, then listen to this episode where Stephan Meijer chats about how he switched from an architecture career into tech, side projects, and how to be true to yourself and your goals.
Homework
Take 10 minutes to think about how the advice that you've given to somebody recently may have influenced the direction that they're going in their life.
Take 10 minutes to think about how the advice that other people have given you has influenced your own direction and consider whether you're happy with that direction
Guests
Transcript
Kent C. Dodds (00:00):
Hello friends, this is your friend Kent C Dodds, and I'm joined by my friend, Stephan Meijer. Say hi, Stephan.
Stephan Meijer (00:08):
Hi all.
Kent C. Dodds (00:10):
I'm pretty sure I said your last name wrong, even though I practiced it. I have a history of doing this on podcasts and I try, I really do. It's not like I'm negligent. Anyway, so statement you and I have known each other - oh, and I forgot to mention, for this season, I'm asking everybody to say hi, and then their name, and we see how many people get that. And you just said, Hey, all. I asked you to say, Hey Stephan but that's okay. So anyway, Stephan and I have known each other for, I don't think it was Testing Playground, I think you were involved in the Testing Library project a little bit in comments, in issues and stuff. You may even have contributed to the repo now, before testing playground was a thing. Do you remember?
Stephan Meijer (01:01):
Oh, no, I really don't remember. I do remember, indeed, we first at our, yeah, talk, I think about Testing Playground. I remember your tweets and it was like something, "I need this rebel for Testing Library. Can someone build it?"
Kent C. Dodds (01:21):
Yeah, that's right. That's how that started.
Stephan Meijer (01:22):
And then I hacked together in a day or two Testing Playground, the first version, and this is how it came to jet. And eventually Testing Playgrounds was invited into the Testing Library org. So, I think that's how things came together.
Kent C. Dodds (01:34):
Yeah. And my goodness, I was blown away. You have this really great ability to build a very useful small project or product, and you have several of these. And before we get too far into that, where I'm introducing you, I'd love for you to introduce yourself to us and I'll fill in any of the holes that you skip, if I want to dig into some of that stuff. So why don't you give us an intro to yourself, Stephan?
Stephan Meijer (02:05):
Okay. Hi, I am Stephan. I'm a dad of two boys and a husband to my wife. I'm now into IT for, I think 10 years. And before that I did something totally different. I worked for an architect. I made cut drawings. I worked on the ground infrastructure, it's pipes, and cables, and stuff like that. And from that profession, I just saw the need for really applied applications, and collaboration platforms, and stuff like that. So, I eventually decided to quit my job and start working in that area. And yet that software led to some open source projects and that led to here.
Kent C. Dodds (02:52):
Yeah. Yeah. Let's talk about some of those open source projects. You've got several of these. Is it fair to call them relatively small? It's not like you're building a Twitter or a Google calendar or something. They're pretty relatively small, but they're very useful, each in their own way. Can you tell us about what some of these projects are and where your ideas came for some of these?
Stephan Meijer (03:16):
Yeah, sure. So, my day job is a collaboration platform between companies. That's a really business to business application and that's dedicated into the project and the living environment. So the road constructions, big buildings and all management stuff there around it. And I got that idea at my previous employer. We really just saw the need for one collaboration platform around a Dutch law. So I decided, okay, if there is a need, let's build it. And that's when the same assessing playgrounds, I really just in a week or so, I hacked together a platform and I offered it to the customers and I said, "Okay, we can use this to solve your problems". And they were happy with it. And so we used it and it started growing and growing and growing. And now we are almost 10 years further and they still use it. The platform has evolved and it's really big now, but yeah, that's my day job. And in these things like Testing Playgrounds, I just see the need in this case from your tweet and think, "Okay, that's a nice evening project". And then then hack away, two evenings or two days. And we have something that works and sometimes that leads to nothing and I just throw it away again and other times someone on Twitter says, "Oh, this is awesome". Yeah, we have it on my product.
And that's same for updrafts. It's a tailwind studio. I just saw a need. I played a lot with [inaudible 00:04:50] and I think, okay, it's awesome. If this was deciding, it would be, have a faster response or time of debt in this class, and you are not seeing what you're doing. So I just yeah, played with [inaudible 00:05:02] and I thought, okay, can we make some drag and drop interface? Like [inaudible 00:05:08] for tailwinds? Just some proof of concept kind of thing. And yeah, it worked. So I thought, okay, awesome. Let's channel some preview video and people really found it awesome, so I think, "Okay, yeah, let's publish it to the internet". And yeah, that's how my projects go, just playing through evenings and then something happens or not.
Kent C. Dodds (05:33):
Yeah, on Updrafts that one's a paid product, right?
Stephan Meijer (05:36):
Yeah, correct. It does have a really generous free version. So, I do see most of the users just stay in the free and they don't want to pay, but yeah. Yes. It's a paid product.
Kent C. Dodds (05:49):
That's awesome. Yeah. So, what I find interesting, in the way that you're talking about these, is first of all, you're able get these things done really quickly and you have a blog post where you kind of talk about that and I'd love to dive into that. But another thing that you seem to do is, and you mentioned this when you were talking about Testing Library or Testing Playground, is after an evening or two, you had something that worked, but the version that people interact with at testing-playground.com right now is not the version that worked after the first two days of working on it. And there's a lot going on there. So can you talk a little bit about, how do you decide when a project like that is done? Like what is an MVP and how do you decide what features are you like? "Ah, I don't need to work on that right now. We'll, we'll wait until later to see if it's going to be a thing" or whatever.
Stephan Meijer (06:47):
Yeah, so for testing playgrounds, the MVP was really first how to make Testing Library work in the browser because it's a common line thing. I usually see it a part of the terminal, not in my browser. So I was like, "Okay, how do I hook this up in a browser? And can I make an interface that's one element and that shows me the metric created?" Once I got depth, I think, that was pretty much the MVP. And then of course you need to polish up the interface a little bit. And yet the polishing up is usually what takes the most time. So I guess, yeah. In case of testing, break down to make it ugly, as long as it works and show it to people and if they like it, then you can polish it up and spend the time there. For things like Updraft, it's of course, bigger than Testing Playground. It has a lot more side dependencies. You need to have the page, you need to have a login system, you must save stuff to the database. The first Testing Playground version could not save stuff to the database. It was only later that we made things store it in the URL and after that we decided, okay, it would also be awesome if we made short URLs and save things in Github guests.
So if I go look to address the first MVP yeah, we could drag and drop stuff together. That part works with the styling, with classes, but things like an altercation system around it or saving your projects to the database, that's all mode requires for MVP. So what I do in that first two days is that I convince myself, "Okay, this is working" is really focus on that business perspective. Like, "Okay, what do I need?" I need that drag and drop interface for Tailwind. I don't need the outcome authentication system because I know I can build it. I don't need to store it to the database because I know that's possible. So really focused on the client's site and the drag and drop behavior and starting Tailwind, and that's it.
Kent C. Dodds (08:55):
Yeah, that makes a lot of sense. So when you're building something new, you don't work on the stuff that you know will work first, because then you're just spinning your wheels on stuff that are solved problems. You focus on, "What's the part of this that is an unsolved problem that I don't already know how to do?" Make sure that can work because alternatively, you can work on all of the authentication stuff, which you already know how to do, I know all the backend saving, and then you get to the part where it's drag and drop Tailwind if for some reason that doesn't work, and so you've wasted all of this time, right?
Stephan Meijer (09:29):
Yeah, exactly. Yeah.
Kent C. Dodds (09:30):
Yeah. I just think that's great. And that probably plays into your productivity a little bit because you don't find yourself spinning your wheels on stuff that you already know how to do, but you focus on the right thing to work on. And you have this blog post that I just loved called "My Career and Lessons Learned in a Nutshell", it's actually not that long, but it is packed with just really useful tips. I'd love for you to talk a little bit about maybe why you wrote the blog posts and some of the key takeaways there.
Stephan Meijer (10:09):
Why I wrote it. Yeah, I'm not really like, I have tens of thousands of followers on the internet, but I am more visible last year in the middle of the COVID crisis than I was before. And that was just because COVID, it sucks, but it created a lot of time for me, especially in the beginning of the year. I wrote about that before in the beginning of the year 2020, I was really motivated. I had a lot of time. So I launched the one project after the other. Testing Playground, Updrafts, and they could be factoring on some open source libraries, such as a [inaudible 00:10:49].
And because all that activity, I got questions on Twitter, but also on Discord, like, okay, how it's possible that you can create so much stuff. I'm busy at home. I have my job, I have my family. I feel like I don't have the free hour at hand. So how are you doing that? And most of those questions came from junior developers from which I just know from experience, they are able to do awesome things, but because they don't have the experience, they are a lot slower. They need more time for stuff. So if they see, I don't know, something like Testing Playground, they see the whole big product, and they think, "Oh, this would take me weeks to build". Well, partially because of my experience and because of the experience also, because of the approach, I'm able to build something like that, the first MVP in two days. And I think that led me to write this blog. I'm hoping that I will make them realize that it's not because they are slow. It's just because I have 10 more years of experience.
Kent C. Dodds (12:00):
Yeah. And I really liked that thought process or that sounds like the main motivator for you was, "Hey, I just want to make sure it's clear for everybody that just because this would take you forever to, or a long time to build, doesn't mean that you're not cut out for this industry or anything". I've been doing this for 10 years and I like that because I think that sometimes, starting in any industry is really difficult, and the last thing that you need somebody else telling you is that you're not cut out for that industry because you're already thinking that to yourself. And you actually mentioned that you didn't even start in tech, that you started in architecture and then you found your way into tech. Can you talk a little bit about like your journey getting into industry in general and kind of why you didn't start in tech and why you made the transition?
Stephan Meijer (13:08):
Yeah. Why I didn't start in tech was because a long time ago, really 15 years, I think around then, it was a time that you end with school, you must go to college or you must really think about, "Okay, what do I want to do with the rest of my life?" And I did have programming already back then as hobby. And of course, a lot of people are around you. So until today, I'm not sure if I really decided "Okay, I want to keep programming as a hobby and I want to do something else for my day job so that you can have your real hobby or that I was just influenced a lot by others, because back then, being a developer, I mean it's really this nerdy type of person, only nerds work in development you really want to be there. So, yeah, I was a really influential person or easily influenced by others. So maybe that's played part, but for a long time, I kept telling myself, okay, I did not go directly to IT because I wanted to keep IT as hobby and I wanted to be an architect. So I started in architecture.
Kent C. Dodds (14:24):
Hm. And I want to drive in a little bit more on the influence that others had on you. I definitely, when I was a teenager, there were plenty of things that I was really into, but I didn't want people to know I was into it because I was worried what other people would think of me. And I'm certain that it had a negative impact on how well I excelled those different areas. Yeah. You mentioned that you felt like people's perception of programming was very, "Only the nerds do that". And do you think that had a pretty significant impact on how you excelled in programming early on?
Stephan Meijer (15:09):
Yeah, I think so, because I was already this insecure type of person, so I did get good grades in school. So they already said like, "Yeah, you the nerd of the class". So then make me the bigger nerd by going through IT direction. I definitely think that played part in my decision to not study IT.
Kent C. Dodds (15:30):
Yeah, absolutely. And when you think about stuff like that, or when I envision people's lives being totally changed by the influence of other people where they don't get to their full potential or sometimes you'll see movies where people are just total jerks to the little kid or something. I just hate that so much because those impacts, especially when it's kids being mean to other kids too, because the mean kids don't even know how negative an impact they're having on the entire life of that individual that they're teasing or whatever. And yeah, I guess it'd be even worse if it were adults. And, that sometimes that is the case. Well, actually there are two sides to this, first I'll set that up. So there's the side of, "I'm the one being picked on", or "I'm the one being given some advice that is influencing my decisions".
And then there's the other side where I'm the one giving advice and I could be influencing other people's decisions, and I'd like to kind of explore both sides of this. So on the side of the one being influenced, how can somebody be self-aware enough to know that they are being influenced and to be able to have the strength to avoid being unfairly influenced, I guess, or just make sure that they are making their own choices. Do you have any strategies for like shielding yourself from the influence of others?
Stephan Meijer (17:16):
I think that's really, really hard, but yeah, I think it's good to, if you get advice from someone, if you ask it or not, really ask yourself if that's the best thing for you to do, and if that's really what makes you happy. Even a while ago, I think it was two or three years ago, someone came up to me with a business idea and they were so enthusiastic about it that I really, it attracted me to it. So, I also became enthusiastic and later on, I thought, "Okay, but that's not what I want. It's a great idea, I really think you should do it, but it's not for me". So, yeah. I stepped back and I stopped doing it. So I think I should also have realized that sooner they were so enthusiastic and that's good, but I can join them for their enthusiasm. I don't need to be part of the position or their boss in life.
Kent C. Dodds (18:19):
Oh, that's a great example. I'm definitely the enthusiastic one. My whole life. I've always been enthusiastic about stuff that I, for some reason, couldn't understand why everybody wasn't as excited about this as I am. That's just the way that I live my life, I guess. And I've learned to just be okay with people not being as excited about things as I am, but yeah, I won't go too deep into that, but I think that's, that's a great strategy too, when there's a new opportunity or a change, like you're going to make a change in what you're doing, if it's just like somebody is asking you for, help moving or something like that, that's one thing. But what we're talking about big, lifetime impacts, impactful decisions, taking a step back and thinking about, "Is this the direction that I want my life to go? What direction will my life go if I go with whatever they're suggesting?"
Stephan Meijer (19:29):
Yeah, and if it will make you the better happier person.
Kent C. Dodds (19:33):
Yeah, absolutely. In fact, I'm having a conversation with a friend just over email. So it's succinct, it's going on right now. And she was just telling me, "I'm not sure what, whether what I'm doing right now is what I want to continue doing in the future. I'm happy I came into this and I'm happy with what I've been doing, but I am not sure that this is what I want to continue doing for the foreseeable future". And I think that's very self-aware and I think that it's good to reevaluate. And one thing that I've done is write down my mission statement. And I just kind of reevaluate that mission statement every few years and see if, if I'm still happy with the mission statement, make sure that my actions are in correlation with that mission statement and you make changes and adjustments as you go.
Stephan Meijer (20:27):
Yeah, exactly. And sometimes that's really, really scary. There's also, in my last job, I worked there for five years and then you have this contract and you really know, okay, I'm solid here. I just get the paycheck at the end of the month. I don't have to worry about my job or my bills or anything. But after five years it became so boring for me. I was really done there and then there's decision to, okay, I go quit my job. I go do something else. It's frequently scary. But when I did it, it was so fulfilling. It was really like, okay, I should have done this a year ago. So yeah, definitely.
Kent C. Dodds (21:06):
Yeah. I think that's great. So self-awareness, really good for shielding yourself from the influence of others, but it's not always bad to be influenced by others. We ask the experienced questions and for advice, because they have experience. So, if you're on, on the other end of this and somebody is asking you questions, how do you make sure that you frame your response in a way that doesn't misguide or misdirect them so that they make a decision that's not going to work with their life goals?
Stephan Meijer (21:44):
Yeah. It depends a little bit, if you know someone really good, or if it's someone you don't know of course, but if you're not sure, then I think you must be just explicit about explaining that it's like how I should do with, it doesn't mean it's also the best assumption for you, but this is how I would approach it and ask them what they think about it. Not bring feelings or uncertain stuff as effects when it's not fact.
Kent C. Dodds (22:12):
Yeah. That's actually a really good thought. The first question before anything else is just, how well do I know this person? And that should frame the way that you respond. And I like the idea of kind of framing it in a way of, this is what I would do. Even with people that I know well, I think that would be a good way to frame things, as well, is just to say, "Hey, I know you, and I feel like you would do well in this way, but this is just kind of what I would do if I were in your position, given what I know about you". But it doesn't matter how well you know somebody. At some point you don't know everything about them and they need to make their own decision. And so, yeah, I guess we just need to really be thoughtful about the influence that we have on other people, especially when they really respect us. Maybe we don't know them very well, but they feel like they know us very well. Or even if they don't know us very well, they respect our opinion. And maybe even just tell them, "Hey, just make sure that you check this with what you really want to do", and give them that advice. That would probably be really good advice to give.
Stephan Meijer (23:32):
Yeah, definitely. I think we can already recognize also in the programming because I'm sure we all had a situation that we'd read a blog from someone that we really look up to and they recommend like, okay, do it this way. We all directly stopped the effects of our code and think, okay, that's the best way to go. And one or two years later, we think, why did I do that? I now have more experience, and I see they did not approach it the right away, I want to have it differently. Yeah, exactly the same stuff, you also have fixed life-changing decisions.
Kent C. Dodds (24:03):
Absolutely. And, even with blog posts like that, it's very easy, especially for somebody with a limited experience to see that and not catch the nuance. And so they'll apply it in a different way than was intended by the blog post. So maybe it was a good idea, but even though, despite that, it was misapplied or misunderstood or something, and so as a advice giver, you have to be aware that of the additional context and the nuance that people may not be picking up and try to counteract that. Do you have strategies for that? Like when, if you're writing a technical blog post, I mean, I'm asking for a friend like ideas on how to make sure that people notice some of the nuance and apply things without missing some of that nuance.
Stephan Meijer (25:03):
Yeah. That's the hard thing about technical blogs, but in my blogs, you really often notice that in my final words that I explicitly mention at the bottom, I really often notice like, okay, there are multiple ways to do this. I've handled them all in my article. None of this is the best, do whatever you want, whatever works for you or your team. And I sometimes also will say programming isn't black and white, there are different things to do stuff, and they all have their own reason and functionality. So yeah, I think it's just be explicit.
Kent C. Dodds (25:38):
Yeah. It's kind of interesting when you said that, it made me think so programming isn't just about a one or a zero, there's numbers in between. It's more like quantum computing. Yeah, that's interesting. There's various combinations and really in technology there's none. And this applies to life just as well that it's every single person's situation is a very unique combination of different variables. And I mean, maybe in programming, this is where we get commoditized solutions for different problems. Eventually we solve this problem. We move on to the next, but I don't think that we have something like that for life because our lives are too varied. We have just such a wide variety of decisions and okay, so maybe we've solved, the breathing problem, everybody needs to breathe, like those very low level, but once you're making life-changing decisions or life directing decisions, that's where it's just too high of a level of abstraction to come up with a solution that's like, "Oh, everybody should do this" because everybody's life experience is different and their goals are different, their desires are. And so advice should be kind of couched in that. So based on my goals, here's what I would do. Based on how well I know you and what your goals are, and sometimes, actually when I give advice, I'll say, "I believe that this is what you want. And here's how I would get that", that can be useful, too. But ultimately it comes down to, as an individual, take a step back from all the advice that you've received and think, okay, so what direction do I think this is going to take my life, and am I happy with that direction?
Stephan Meijer (27:31):
Yeah, exactly. Yeah.
Kent C. Dodds (27:33):
Cool. Well, we just have a minute or two left. Is there anything that we didn't cover that you'd like to?
Stephan Meijer (27:41):
No, I think we said it all, right in the time.
Kent C. Dodds (27:45):
Great. Cool. Well, we do have homework for folks and we'd like for you to be a little introspective. So take a moment, and we want you to take 10 minutes, maybe five minutes for both sides of this. So 10 minutes to think about how advice that you've given to somebody recently may have influenced another person's life, the direction that they're going in their lives. So maybe somebody in a Discord chat or on Twitter asked you whether they should take a job or something. That's a question that comes up a lot in our Discord, in the KCD discord. And it's very easy to give people life directing advice, and they're asking and it's okay for them to be asking, but think about how the advice that you gave them might influence them and how you might do that in a way that helps them take ownership, I guess. So, yeah. That's the first part. And then on the flip side, how the advice that other people have given you have influenced your own direction and consider whether you're happy with that direction. You have anything to add to that, Stephan?
Stephan Meijer (29:07):
I could not have said it better. Yeah. So yeah, for everyone just believe in yourself and don't make decisions that you're not fully supporting.
Kent C. Dodds (29:19):
Absolutely. Great. This was an awesome conversation. Thank you so much. Before we wrap up, what is the best place for people to connect with you and keep up with what you're doing with all the corporate? Oh, actually before we do that, one project, I don't think you mentioned, I may have misheard it or something, but you didn't mention Red.rake, and you want to give a quick pitch on that? That's another paid one that I think is pretty cool.
Stephan Meijer (29:44):
Yeah. It's the other way around. It's a regular rhythm. It's a big one for form handling. That way, when you host your website on Netlify or on Vercel, and you have your static pages, you can just connect your forum to my end point at regular thread, and I will take care of every form data that you submit to it.
Kent C. Dodds (30:07):
It's cool. Yeah. I think it was a great idea. Another one of those relatively small things that are just really useful, so very cool. Okay. So yeah, now what's the best way for people to keep up with what you're working on, and find out the next cool thing you built.
Stephan Meijer (30:20):
Just follow me on Twitter. That's @meijer_s and I'm sure you'll post it somewhere in the description here.
Kent C. Dodds (30:26):
Yep. Okay. Awesome. Hey, thanks again. And we'll see everybody later. Goodbye!
Stephan Meijer (30:32):
Thank you. Bye-bye.