I have also started several side projects and never finished any of them. The problem for me was that when I solved the most important problems, I lost interest in it. This year I'm trying something new and I hope to overcome this barrier. So I can imagine your situation. I wish you to choose a project that you will enjoy and find fulfilling and see it through to the end.
Depending on the type of project, sometimes 70% of the time is programming and 30% is consulting with the team. Other times I do 60% design and 40% programming. It's project by project. For me, most projects are greenfield development. Some of them don't even come to fruition after weeks of designing and are lost. The main thing is to do your job the best you can.
I have been programming for over 20 years. I've developed everything from small in-house applications to systems in critical infrastructure... But the working mood and work deployment depends mainly on the setup of the internal company policy :)
Try looking for positions as a developer in industry or look around for companies that have contracts for industry. Such as power plants, heating plants, any other manufacturing plants...
I wish you good luck.
It's true, the beer in Prague is excellent. Overall, I like the beer culture in the Czech Republic. The language is easy to learn, especially if you are from Slovakia like me :)
I would like to say hello to Prague.
I think the difference between a long function and many short functions that are not reusable is not big. A long function can be cluttered if it is really too long, and also many small helper functions can bring confusion to the code. The advantage of short functions can be their testing, or the division of work in the team. Anyway, if too long functions or too many one-call functions start to appear in the code, the code architecture should be reconsidered.
A major difference between a long function and multiple short helper functions is that when you look at the local variables in scope in the long function you do not easily know which of them are used by which parts of the function. You see a variable used on lines 756-762 but the function continues to line 900 and perhaps it's used again further down?
Some languages have block scopes that can make this better; my position is against long functions in languages that lack block scopes or written by programmers that do not avail themselves of block scope.
I really struggle to see why anyone is not attracted to that form of abstraction: if local variable foo is computed in 10 lines using local variables bar, baz, and qux, and those 3 are not used for anything else, then clearly matters are improved in a 100-line function by replacing those 10 lines with
foo = computeFoo(bar, bax, qux)
Authors of long functions are not embracing appropriate modularity, but that seems inexplicable, since modularity is the basis of the software revolution.
Personally, I encounter long functions (as you described, around 100 lines) mainly in older codebases that were written over 20 years ago. In many cases, I get them for rework when developing new software, particularly in industries where the adage is 'if it works, don't change it.' This phenomenon could be attributed to the fact that, at that time, OOP was just emerging, and developers were not yet accustomed to it. I strive to write code that is concise and highly readable. It's important that the function's purpose and usage are immediately evident at first glance, rather than relying on copious comments.
Invest in yourself, especially in your education when you are young and able to devote yourself fully to education. All the money you invest in education will pay off by opening up new possibilities and paths in life, better employment and earning opportunities.
