I believe projects complexity increase exponentially as it grow in size, anybody noticed that too?

I do. For me there is a directly opposite force to coding that I call "programming inertia". When I code for clients I'm aware of this problem and try to keep solutions as simple as possible (KISS), and well structured/documented to be friendly with clients/partners. But when I get into personal projects these are long-term developments that really push my limits, and the inertia feels really really strong. I actively experiment with techniques to avoid it, for example by taking ideas from experiences on low level languages like Assembly oriented to micro-controllers, and very high level languages like Javascript in a resource careless way.

In general I have shaped and keep improving my workflow having these aspects in mind:

Code visualization. There is an amount of the whole algorithm that you can visualize at once. As the code grows you will start forgetting parts, and then you will have to read it again. If you can't catch the algorithm while reading, you will have to study the code to find how it flows. This effort will make your mind drop other parts of the algorithm. Structure and documentation can help you to pick up those parts again, but then documentation also contributes to the inertia. Comments are part of your code as everything else, in the end these are algorithms written in natural language or as diagrams, which are simply translations of the algorithm. For that reason minimizing code as well as documentation reduces inertia. The code must be self explanatory. When it's not, comments are required but only to the minimum. Then if comments are not enough when studying the code, these must be enhanced with the missing information to pick up the algorithm quickly next time.

Typing vs. thinking. The easy part of programming is typing. You can write hundreds of lines per day, even more with code tools, but solving a difficult problem that requires a single line a of code might take several days. So you have to transform problem solving into typing, and solve the difficult problems when the inertia is low. Practice is what gives you a catalog of tools that you can plug into the code to solve a given issue, that's the way you convert thinking into typing. It also helps you foresee those difficult problems that you must prioritize, to avoid being hit the inertia shockwaves.

Procrastination by coding. This could be offensive to many programmers, but it seems that most languages have these programming features that only distract from actually hammering the problem. And there are these protocols/patterns that become problems in themselves. Even at some point programmers adopt practices in their workflows that have nothing to do with solving tasks, because decorating the code is fun, but all that is procrastinating with the art of coding. There is a minimal set of programming features that will allow you to create good software and is common between languages, but language creators add extra features to do things in different and interesting ways, because they need to attract more users. All of this only contributes to the programming inertia. Actually most language features focus on easing the typing and reading, but thinking and studying is still required, and so those are adding nothing really useful. The programmer must be smart enough to avoid these language traps, and keep with the minimal common language, that will also help him/her to quickly move from one programming language to another.

For me thinking on problems is the fun, having to learn new things to solve problems is fun, and how hard all of this is doesn't matter. But the programming inertia caused by these aspects and personal or external issues is what kills the fun. I think being a programmer is a way of living, probably a good reason to consider it an art. You have to apply problem solving to everything else before you can actually program.

I'll add that one thing that greatly helps visualization is to keep a separate code journal. For me this is a spiral bound notebook that I use each day I code, to lay out what I'm working on, what I completed, ideas I have for an upcoming problem, ideas I have for a problem I just defeated, diagrams and anything else that comes to my mind --- but not code. Code does not go into the journal unless it's pseudo-code. The journal is for freehand notes, thoughts and helps keep you centered and focused on a level outside of your code-brain. If i lose focus on something I can easily consult my journal to regain focus, and I don't have to commit so much to memory. It allows me to juggle what really needs to be kept in memory and what can be "off-loaded" for later consultation. The short time I spend on keeping notes like this is well worth the time I would lose if I didn't do it.

Commenting notes in the code is different than keeping a project journal and the two practices should compliment each other if possible.

That's why it's important to keep your code base as simple as possible. Do the most simple thing that works. There are way too many cycles wasted on YAGNI over-engineered cruft and pointless abstraction layers.

Programming is hard because the distance from start to doing something is large.

Consider something like sports or sketching where you can grasp the rules quickly and go.

And the more complex the project the larger the distance to the payoff is. Even if you use the iterative design strategies.

This distance leeches motivation which you need to get through the routine parts which tend to be boring but amount to a lot of the code in a project.

I believe projects complexity increase exponentially as it grow in size, anybody noticed that too?

I mean, a project with a single file and a 100 lines of codes is very easy

to work with, while 100k lines of code may be too much for a single person to handle, while 10k lines of code is not so bad.

Just my though.

It increases of course but maybe it increases just in linear,

on the other side this is a human possibilities that make

it exponential dead - for example you could walk 1 km with ease 10 km is managable 50 km is hard - And it is not strictly matter of lines of code but some more abstract knowledge you need to go through (and of course the amount of the

knowledge may by one of the most important factors that

kills (fatigues) me :/ So it is somewhat good answer I think

Programming is hard because the distance from start to doing something is large.

Consider something like sports or sketching where you can grasp the rules quickly and go.

And the more complex the project the larger the distance to the payoff is. Even if you use the iterative design strategies.

This distance leeches motivation which you need to get through the routine parts which tend to be boring but amount to a lot of the code in a project.

ye this is quite good answer I think - this distance is one of the most important factors; but maybe there are yet some that do matter

I think programming is hard for you, because you spend/waste your whole time asking overly broad meta-questions, that wont help anyone much, and you never look at/show/ask about any real programming problems you have.

I think programming is hard for you, because you spend/waste your whole time asking overly broad meta-questions, that wont help anyone much, and you never look at/show/ask about any real programming problems you have.

This is because i cannot focus recent weeks as i said so I am taking a lounge - I find such general meta-questions could be good for me, [If it isnt helping you it is just not for you] - it seem that it already helped me a bit (to clean my head)