Niching down

I listened to an episode of HTML All The Things this morning about niching down side projects and "the eternal loop of never-ending features." I'd link the episode, but I haven't added that feature yet.

Reduce projects to a single idea

The episode really reflected something I've thought about a lot lately, which is just simplifying everything, but they put it in terms of niching down. Reduce apps to a single idea. Most importantly, they talked about mapping out an MVP (Minimum Viable Product) and what features make-up the MVP and what should be put on a wishlist.

It's something I was ready to here, particularly with where I'm at with The List NC right now. I've had a difficult time deciding what events to include and I think niching down and explicitly defining what it is that the website offers is something I need to do. I've thought about this in terms of writing a mission statement, but i think defining exactly what the application is for will be more effective.

This idea of niching down also applies to the functionality of the application. I could add endless features trying to satisfy everyone, but the gains will be minimal outside of the core functionality. The List, as it exists right now, is pretty clean. I don't think there's much to add from a user perspective, though the backend could be improved. For the moment though, it's an important thing to acknowledge just as a reminder that I don't need to worry about improving the application. Content is where my focus needs to be.

I have the goal of shipping this blog in the next week or so and defining what exactly my goal with building this is, as opposed to using something like Pika, is something that I need to work out, so that I can focus on getting the MVP finished and get it live.

Project-based learning

Similarly, I've thought a lot about reducing my studies and skill-building to single ideas over longer periods of time. Rather than trying to learn tons of different things. Focus on one thing and one learning resource and go as deep as possible. The idea I had this week was to focus just give myself a year-long timeline to go as deep as possible on a single resource. For example, right now, I want to read Node.js Design Patterns. If I can get through that book, take a lot of notes, play with the code, practice with side projects, and absorb everything I possibly can from that book, I'll be a badass with Node.js and Javascript at the end of it. If I get through it in less than a year, I can move on to the next thing.

I think an important component of this strategy for learning is to view learning through the lens of projects. Rather than "becoming great at writing Javascript", define a project that will provide desired outcomes. Reading a coding book is a project. Completing a Leetcode course can be a project. Write a book about web scraping with Node.js could be a side project. And then focus on one project at a time.

Don't invest where gains are minimal

I journaled about this a little bit yesterday regarding spending and going out to eat, but it follows the same logic as is described above. Don't invest in features that are not essential to user experience. Don't invest in shit that isn't essential to your own life satisfaction.

And know how to tell the difference.