I have collected several "What The F*" from projects that I have worked on and some side stuff that I've tried over the years. If I have to be honest, some of the WTFs I may have made personally from poor practice and experience. Sometimes the fault was hidden in the lack of deep understanding of the libraries and the frameworks.
Last few years I created several personal projects. The good (and in this case and the bad from another point of view) thing about actually being the owner of the final product, the creative of your work, especially if you are using it on a daily basis, is that bugs and imperfections come back to you fast and you have to fix them if you want to continue using your own tools.
If you are using a database that supports transactions - USE THEM.
Transactions are mostly concerning back-end systems. There is a lot of science on it - Isolation Levels, Transaction Distribution (between systems that are even not located on one physical device and so on. I personally haven't gone too deep, but enough to get work done. The use of WebSQL (SQL in the browser) is not so widespread because it is discontinued by the World Wide Web Consortium. But, the native mobile platforms provide some kind of databases - relational, object or noSQL. Probably not all have transactions as feature but when they do - transactions will speed up the applications. I used it with my last application - Breathe In - and it made saving of 100 sensors (this is my page size) and data (1-4 records each) of the sensors lightening fast.
Never select all records from a table without filter(where) or limit and offset parameters.
Never select all records from a table without limit parameter if your not absolutely, ABSOLUTELY sure that these records will never get a lot. Back-end systems and even front-end platforms may handle 1000 or more records but, if the stuff scales up - the memory footprint will become ugly eventually.
Try separation of concerns and loose (code) coupling.
This is something that is above concrete developer stuff - programming tools (IDEs), programming languages, companies, object or functional orientated, front end or back end etc. Making one software component do only one simple thing sounds easy, but when getting your hands dirty with business / client logic, the shit just gets real.
Another thing that is linked to separation of concerns is code decoupling. This means that the dependencies between the software components are as minimal as they can. Modern languages and frameworks use dependency injection mechanism - with initial or centralized configurations or code annotations and so on, to help alleviate this problem.
Try design patterns but not too many.
Design patterns are the methodologies with which often the separation of concerns and code decoupling is implemented when using object oriented language. They are good for code minimization but only when applied to the correct places. If applied without actual need, just because you want to use them, this could lead to increase of the code length and complexity.
Minimize code and code duplication
One colleague of mine has a saying - less code is always better. Unfortunately, the machines need to be instructed, tested and verified to do what we want them and they are doing what we put in the code and often not what we actually want. Absolutely no coding options are available for more basic stuff. There are enterprise tools with more advanced features but they are mostly expensive. There are libraries and platforms that automate things - visual programming with drag and drop of components, code generators (like the one I am creating), blogging platforms that can offer no-coding solutions and so on, but all of them have same disadvantages as well as advantages.
Standardization
Standardization is something that has a lot of benefits for the whole software industry - being able to integrate software and/or hardware components from different producers is something super cool. Unfortunately for more advanced stuff, most corporations try to push their own ways and integration is hard.
Another thing in terms of code standardization is that - tools could potentially handle (generate or automate) some hidden for the end programmer logic and make extending the software easier. But, if you need something more advanced you better find good documentation. On many Java Platforms, Frameworks and building tools - there are code/directory structures that they enforce and follow. Same as WordPress template files. The shit gets stinky when you don't know the standard and the documentation is scarce or incomplete.