This is the art of being an effective person, let alone doing good engineering, and personally I find building and using this craftsman's intuition to be the gr

This is the art of being an effective person, let alone doing good engineering, and personally I find building and using this craftsman's intuition to be the great joy of working in software. Contrary to many of the comments here, I would never just go for a "boring framework" because it is tried and true, or just use what I already know. That sounds like a great way to grind yourself into burnout. Instead I would start jamming on a whiteboard or in a notebook. Think about the problem you are tackling: what are the inputs, what are the outputs, what are the key functions, and what data structures and algorithms might be important? How about the team? Is it just you, or are you working with other people? What are your experiences, interests and passions? What's the timeline? Spend some time exploring libraries, reading paper and blog posts to inform yourself of the space. Maybe read some open source libraries. Don't go nuts, but scan around to soak up some good ideas and build a mental model of the space. This all helps put some parameters around the situation and give you some confidence that you are making informed decisions. Now you can think about the MVP, key interfaces, etc, and you might find that you can do some quick and dirty components for 80% of the project while really focusing on the heart of the challenge in that last 20%. Often times if you define good interfaces you can swap early hacks and experiments out for something fancier (faster, more scalable, etc) later on, so then you don't need to worry as much about making optimal decisions. For example, you might use some distributed key value store or message bus in the end system, but to get the ball rolling you can just spin up a Redis instance during development, or even just write a couple functions that fake it in-memory or using JSON on disk for starters. Now you can think about what you want to learn in this project. What's going to be fun and interesting about it? Do you want to dig into some new algorithms, a different language, a machine learning model? I like to use my curiosity as a major motivation to differentiate from other solutions and push through what could otherwise be boring aspects of the project. Say you need a service that just manages logins and sends back some tokens. That can be done in a million ways, and it is likely to get swapped out down the line anyways as you scale or whatever. So make it interesting, pick a new library or language and go nuts. This of course needs to be balanced with making sure you can accomplish the task in a reasonable amount of time, but this kind of learning is empowering and it will make you a more capable engineer. Now 20 years into my career I can program in 10+ languages on embedded micro-controllers or virtual cloud clusters, and picking up a new language or framework isn't daunting at all. Have fun doing it, and you'll get better faster than everyone who is picking the boring framework in their same old language to solve it the way that the blogs are telling them to and then frantically searching stackoverflow because half way into the project they discover that their square problem doesn't perfectly fit into the framework's glorious round, ahem, hole. That's not engineering or craftsmanship. That's nervous fanboy frenzy that is the opposite of empowering. Everyone has to find their own explore vs exploit trade-off, and we need people whose experience is narrow and deep as well as others who have learned far and wide. Choose what kind of person you want to be and make it happen.