A big part of the problem is the perception of what work is.
When someone can see you at your desk hitting keys or standing in front of a white board drawing diagrams there is the perception thaat you're doing something. When you're staring out a window or go for walk during "work" time the perception is that you're goofing off because there is no visible evidence of the mental processes going on.
So the interessting question is how can we change the perception?
I'm not a lawyer and the best advice is to check everything with a lawyer...that said it sounds like the contract would be covered by Cypriot and (if you're in the south) EU law.
I live in Ireland and these sorts of clauses are pretty standard, but I don't know how enforceable they are...there's a lot of nuance. For example, creating a direct competitor will probably put you on shaky ground as it could be argued that you used company trade secrets to gain an advantage.
If you create something completely unrelated it could come down to whether you used any company resources in the process i.e. a company laptop, company email, worked on the project during work hours etc. But even if you create something unrelated and didn't use any company resources that doesn't mean your employer won't try to enforce the clause which could result in a whole bunch of expensive litigation which you probably don't want to have to deal with.
What I have seen work is discussing any side projects (including open source) you're going to work on with your employer first and get written confirmation that they're waiving their right to enforce this clause. They may have legitimate concerns about what you're doing (is it competing with their business, will it be a distraction from your work etc) that you may have to address. This may not work in every case, but usually does.
Ultimately you need a paper trail to ensure you can prove the project wasn't something your employer was paying you for, but as I said if you anticipate your employer enforcing this clause you probably want to think hard about whether you want to have that fight.
First of all, you are not alone. When I read your post it really resonated with me. I've been developing software professionally for 25+ years and have had 3 bouts of burnout and have gone through the same fear, uncertainty and doubt you seem to be going through. It can get better and there are a few things you can do to help (at least these helped me):
1) Take a break, even 1-2 weeks can make a huge difference. You need to rest and recover so you can get persepective. It's really easy when your in the thick of things to loose sight of how bad things are or see a way out. If you can get away from that for a week or 2 you can start to think clearly again and figure out what you want (and do not want) to do next.
2) Stop working crazy hours. There are times when we need to work really hard to get something delivered, but if you're doing those hours all the time you're going to be exhausted which means you're getting less done in the regular hours and have nothing left to give when it's really needed.
3) Don't sweat about side projects. I have several hard drives full of half-finished or abandoned side projects that will never see the light of day. It used to bother me that I couldn't get them done, but now I treat them as hobbies which should be fun. If it stops being fun I stop working on it.
4) Believe in your abilities. It sounds corny but if you're shipping software then by you're doing the job. Sure we all have things we wish we could do better, but accept that you have skilla and then figure out where you want to go next. As an aside, hacking together snippets of code found on the web is how most software gets built...it's our indeustry's worst kept secret :)
5) Learn from smart people. This one is harder to do but if you can find some really smart people to work with you will learn more than from any other source. This doesn't have to mean changing jobs (although that really helps) it could mean contributing to an open source project you really like.
Complexity kills projects and the will to work on them. It can be caused by either over or under-engineering. With the first you end up with extraneous layers of abstraction and badly applied design patterns that make it hard to understand or reason about the code...in the second you end up with a big ball of mud that's impossible to understand or tease apart.
In both cases the code gets harder and harder to change to the point that no one really knows how it works or wants to risk touching it.
The issue here isn't so much over or under-engineering, but rather "Are we building the right thing?" or "Are we building the thing right?"
In a startup you don't know if you're building the right thing so trying to build it right is premature optimization. Since you have limited resources you really have to focus on ensuring that you're building the right thing...if you aren't it doesn't matter how well designed or built it is no one is going to use it.
Once you've validated you're building the right thing you can start focusing on building it right, but by they you probably know where the pain points are and where you need to spend the effort.
The trick with this though is that everyone needs to be aligned on that approach and be honest about the fact that corners may be being cut to get something working fast. Where I've seen this go badly is where a crappy initial version was built to get to market fast, but then no time was made available to address the defencies in the initial release.
When someone can see you at your desk hitting keys or standing in front of a white board drawing diagrams there is the perception thaat you're doing something. When you're staring out a window or go for walk during "work" time the perception is that you're goofing off because there is no visible evidence of the mental processes going on.
So the interessting question is how can we change the perception?