This is a great question and I'm having real difficulty putting together a good list that's generally applicable, but not so general that's it's useless in practice. I'll give it a try (from the perspective of defining what matters):

1. There usually are just a few critical pieces to any project. You should try to start with those and get them locked down first. These can be critical because they are either technically unproven or just plain difficult. Once you know the hard stuff is handled then you can fill in the easy stuff from there on out. (You'll also feel less inclined to fancy-up the easy stuff, in my experience. That's another source of trouble).

2. Use quality tools, become an expert with them, and hold on to them as long as you can. What does quality mean? To me: reliability, stability, and efficiency of both my time and the machine's time. Knowing how to do something because you've done it before, seen the problems and worked through them, and come out the other side, is _huge_. Rarely rarely rarely, a new technology comes along that overwhelms the advantages that hard won experience provides, but it's super rare. This is a whole topic in itself, but in my 20 years the list of situations in which something new clearly brings enough benefits to switch are surprisingly rare. Off the top of my head (and just to make everyone mad in one easy sequence): moving to Java from C/C++, Hibernate ORM instead of endless hand crafted SQL, S3 instead of a probably-about-to-be-full attached volume, Heroku instead of running my own machine, Unity instead of my bad custom game engine, and most recently Flutter instead of native Android/iOS (although this one is still early days).

3. Be honest about what you're actually spending your time on, and optimize for that. A lot of the fancy programming languages of recent years have been spending huge amounts of time optimizing what, for me, weren't big usages of my time. I realize this is vague, but an example for me might be Scala. The stuff that they were improving looked fancy in examples, but it didn't make a material difference to me (as a Java programmer) in what I actually spend time on. It also came with a bunch of downsides, which is itself worth an entire post.

4. Don't be afraid of simple looking code. It might be slightly embarrassing to check in, but it's probably going to be clear how it works to you any other other person who needs to read it in the next few years. The urge to appear smart in the way your code looks can be deadly.

5. Be specific about the upsides you expect when examining a new technology. Are you looking to work faster, are you looking for performance in a specific category, etc. Failure to properly define your criteria leads to adopting things that are a bad fit for your situation (helllooooooo microservices) or at least provide minimal benefit in return for the _huge_ expense of throwing out experience in another technology.

I'm pretty sure there's lots more examples, but that's all I got at the moment. I will add more if I think of it. I guess this should all be a big blog post at some point as well, if it's something people find interesting.