E17: Reading: Finish Your Projects

09/30/2024, duration: 17:58

Video

Transcript

Welcome to Debugging Dan, where I share weekly my journey, balancing life, a full-time job and side project. I'm Dan, your host. Let's dive in!

Today, we're doing something different than episodes that I've done before. We're going to do a read-along, let's call it that. So, recently I saw this article being retweeted again by Aaron Francis. It's called Finish Your Projects. I have read this article like two years ago, something like that. And I got reminded it because somebody mentioned it and Aaron retweeted it. And I figured this is a topic that resonates with me. Let's take this as a topic for my podcast. I've already recorded an episode about the topic myself. So, episode four is about completing projects. And that's really related to this. But this is more focused on how to get past that last part of the project, the menial task. And if you're looking via YouTube or you're watching via YouTube, you can read along with what I share on my screen. And if you're listening along on the podcast, the article is linked in the description of this episode. So, you can look it up yourself. So, let's get started.

Your article is called Finish Your Projects. And the sub-tag is Don't Let Fear or That Last 10% Hold Your Back. And it's written by Aaron Francis. At that time, he was a developer educator at PlanetScale. But I know that since then, he has moved on. He had been let go at PlanetScale. And now, for the past few months, he started his own company doing content creation. And you can also hire him to do content creation. So, this is the article URL in the show notes. I created the printout of this and annotated it. And I'll go mostly to the annotations that I made, the important parts of the article. And you can also read it yourself, of course.

So, it's called Finish Your Projects. And I feel the same way like Aaron. So, he mentioned starting a new project is a rush. And indeed, starting a new project is cool. Indeed, you start. You have the ID. You can get code implemented quickly. Or if you're not doing code, something else. But starting is easy. You have this blank slate that you start with and continue and you move along. And at some point, you continue. And it works. But it works on your computer. And it's not ready for publication yet. You've ignored error messages that are returned. But you continue along anyway because you feel this is just the first part that I'm building. And it doesn't really matter that error messages don't get shown. So, I'm just continuing. Just going along, implementing what I need.

And at some point, you hit a wall. Either this thing that you wanted to implement is done. Or it's getting more difficult to do the last part of the feature that you're implementing. And it starts to feel more like grinding. And it starts to get more difficult and you start to lose your interest. And then you decide, well, maybe I'm just going to let this go and start a new project. At least that's a cycle that I often go through. I feel like, well, this is good enough. It's good enough for me. I can skip the skip. I wanted to make this, to publish this. But let's not do that. And let's continue on to the next thing. You have a new idea. And then the entire cycle starts over again.

And Aaron also mentions this in his article. And he also states, you're probably in the majority of people that do it like this. So, you shouldn't feel ashamed. It's a normal cycle. And this article also goes into how to break that cycle. And instead of getting the rush of starting a new project, you might also get the rush of completing a project. And that's something that's good. So, in this article, Aaron goes into, he explains, finishing a project is different from solving a problem. What role fear might play in getting stuff done. And what's also a benefit from actually completing the project. So, what makes it difficult there. And in his opinion, there are two things that are difficult. It requires finishing the work. And that's more related to the menial tasks. The grind, getting all the error messages correct. Getting all the stuff done. And all the things around it that are not directly related to the problem that you've solved, that you got the rush from.

But getting it ready, getting it done, getting it hosted somewhere, writing a landing page. But it also requires courage. And that one interested me. So, the part about completing the work, that's pretty self-explanatory. You get into, when you do the new part, you started with the blank slate. And at some point, you need to do the boring stuff, like validation. And that's not really related anymore to the thing that you were building or the problem that you were solving. And so, that gets boring. And one thing for me that helps in order to get that boring stuff out of the way as fast as possible is I created my own boilerplate. And all these stuff, I've solved once in my boilerplate, so I can pretty easily reuse it. I have a way of working. And I can pretty easily apply that to any project that I have that I created in that boilerplate.

So, the upside of that is, you know, I've already figured it out. You have a way of working. You have a way of doing that. So, you don't need to reinvent the wheel every time. The downside is that sometimes it's nice to reinvent the wheel every time, especially in the JavaScript community. You're mostly, there are a lot of NPM packages for doing the same thing. So, frameworks, validation. So, at some point, you were using Joy, for example, as a validation package. And you want to try out Zod for validation. But if you're doing everything the same way, then you can just easily exchange one for the other. Then you do have a different way of working. And then it gets more mechanical and more repeating. Because you do need to re-implement all that stuff. Again, not only the validation, but also handling the error and the exceptions thrown from the validations. Because those might be different. You need to format the validation differently. Because the errors are thrown differently.

So, for me, I try to do the stuff that's very repeating. I try to put that in the boilerplate. I always use the same CSS libraries, validation, frameworks, and stuff like that. So, that's it's more, less of a grind. Because I'm in a comfortable place. I can easily do those things. Because I've done them a couple of times. And for me, that really helps. So, Aaron nooms it unpleasant work. But by doing it like this, for me, it becomes less unpleasant.

And the tip that Aaron gives is he breaks it down in three different points. He sets aside a block of time. So, for example, a Bumgador 20-25 minutes. And at the beginning of that block, you decide what to go work on. And then you focus only on that thing. So, you close your slack. You close your rest. You just everything. You can't get disturbed for those 20-25 minutes. And by really focusing on it, you're probably able to get a lot of work done. And leave part of that boring remedial task behind you. It's just about doing things. And you just need to work through it. That's also what Aaron mentions. Just go.

And what his tip is, he puts a specific song on repeat by Suf Janssen, in the case of Aaron, because he shares that occasionally. And that helps him get in the zone. And for me, I do something different. I have a playlist on Spotify with soundtracks for games. I'll put the link in the description or in the show notes. And for me, because I keep doing the focus work with that music on my earphones, then the music kind of drones out. But I have it in the background. And it helps me keeping focused, getting focused, and really getting stuff done. So, for me, that's music. And that specific playlist is very helpful. Normally, I listen to more kind of a rock or pop music. But doing focused work behind a computer, that game soundtracks or those game soundtracks really help me get in the zone, help me getting stuff done.

So, that's about the working part. But there's also the fear of finishing. You build the stuff and it's kind of done. So, you did the work part, but then you get, what's the word for it? You lose confidence. So, do other people even want this project? Is it good enough? And you get scared and you decide not to release it and to continue with something else because it's not good enough. And I think that's stuff that you tell yourself and you should get into the process of trusting yourself more. You, when you put stuff out there, you get feedback back, you get feedback back, you ignore the negative feedback because those are just trolls on the internet. And you take the positive feedback and you use that to enforce yourself to think, hey, I did something good. Someone benefited from what I built. The stuff that I built really helps and it really works.

And it's also, it's kind of a crown on your work. So, you did a lot of, you put a lot of effort in completing the project and it's only fair to yourself that you also publish the project and have other people enjoy the stuff that you worked on. Else, it will be just another project gathering dust without being completed, without being published, so it's also something that you can do for yourself, knowing that I've completed it and I've published it so the work wasn't for nothing. And of course, don't get me wrong, it's also okay to not do that, to just keep the project on the shelf. You should not guilt yourself into completing the project. But this may be a narrative that you can tell yourself to really get done and really get it implemented.

So, and what Aaron also mentioned, he says that every time you don't release a project, you're telling yourself that you're the kind of person who doesn't ship. If you tell yourself enough, you'll start to believe it. And once you believe that, that's very hard to unwind. But the other part is also true. So if you keep shipping and you show yourself that you're the kind of person who ships, you start to believe that and it becomes easier to ship once you have the project completed. So, the fear is there, but there are ways to mitigate the fear, to work with it and have faith in yourself, trusting yourself that what you build is good enough. You can't really trust in yourself and you should believe in yourself because you're doing things that you enjoy, things that you like. So why shouldn't other people benefit from that?

And Aaron also has a different article. He mentions how publishing your work increases your luck. And it's been a while since I read that article, but it's also a good one. And he mentions there that by publishing stuff and having other people see it, there's a benefit. And he, if I can quote him for every vocal critic, for every vocal critic, there are 10 times as many people quietly following along and admiring not only your work but your bravery to put it out publicly. Let that be an encouragement. So often on the internet, you only hear the negative sentiments and the people that just follow along, enjoy reading what you're doing. They might hit the like button. They might not even give any feedback, but they do read what you create or what you write. And those people, you don't hear anything from them, but know and realize that they're there and that they are enjoying what you're creating or building.

And I've mostly mentioned it in the context of side projects, but this also relates to blog posts that you're writing and other stuff that you're creating. Often there, there's also a blank slate. You start writing something there. It's also difficult to get to the last point and publish the blog or a book that you're writing or something else. So this applies to a whole range of fields and activities that you're doing, not only to software programming, of course.

And one thing I highlighted in the article is also that Aaron mentions finishing takes work. So there's just work related, but also finishing takes courage. So you need to overcome that fear and the fear itself becomes a reward. And then Aaron goes into the last chapter of the blog post. He mentioned, he calls it the joy of finishing. So there's a lot of joy in beginning a project, having that blank slate, solving your ID, working on it and you should take pride in what you've accomplished. You've finished something. You're a person who finishes things. And he even goes as far and he says that while finishing is a skill and as all skills, you can own it. And as I mentioned earlier, tell yourself the narrative with each release, you are the kind of person that ships. And every time you ship, you know that you should realize that, okay, I've built something, I've built an update or I created something new and I was able to do the work, but I was also able to ship it. And you should also be proud of yourself if you ship it, that's also what you can tell yourself, what you should be proud of every day if you ship something.

And if at some point it doesn't work as you'd like, so you don't get over that threshold of fear for shipping. And that's also okay. That's what something that I have had to learn that it's also okay to fill some time, maybe it could be that the idea that you had wasn't good enough and that you find that out while you're working on it. It could also be that you ship and then it turns out there's no real interest in it, or you're not able to connect to the right people or to the market for your project. And that's the risk of creating a side project of shipping. But you should first and foremost, be proud of yourself that you were able to already take the step of getting there. There are a lot of people that don't even start and you should be proud of yourself that you even got to starting the project and you've got it to completion and you got it out there available for other people to use, to view, to read, whatever it is.

Um, that's the topic for today. If you liked this format of me reading something and giving my opinion, let me know if I encounter any new or interesting articles, I'll do it again. Bye.

Thanks for tuning in to Debugging Dan. If you enjoyed this episode, please subscribe and leave a review. Stay curious and see you next week.