Update

project.md

@@ -13,7 +13,7 @@ Also let it be said that everyone has to find his own way of doing projects, it'
 - **As always, keep everything [free](free_software.md), [LRS](lrs.md), well designed, non-commercial etcetc.** Minimize [dependencies](dependency.md); dependencies of your project are for example the [programming language](programming_language.md) you use, libraries for formats that you use, assets of third parties you use, minimum hardware demands of a computer that can handle the project etc. Just a reminder. Also think with your brain.
 - **Prefer one man projects to many men projects**: Firstly LRS projects should be simple enough to be manageable by a single man, which has many advantages, for example ensuring a coherent artistic vision without any compromise, legal simplicity (e.g. with relicensing), ensuring that the project can REALLY be controlled by a single man (true [freedom](free_software.md)), and also very importantly the cost of collaboration. Multiple people on a project -- even just two -- introduce many inconveniences, issues and [friction](friction.md), e.g. that of communication (every thought has to be explained, put into words for others and they still may not completely get it, communication tools will have to be set up and maintained, ...), resolving editing conflicts (multiple people working on the same thing at once), making decisions (voting? discussions?), disagreements, arguments, "codes of conducts" and similar bullcrap. LRS does value collaboration, but mainly loose collaboration, i.e. making bigger things out of smaller things that are made by single people. But more people projects are cool, e.g. wikis or maybe projects by very close people who are already used to working together efficiently.
 - **Do NOT be too ambitious, especially with first projects.** This is EXTREMELY important and you have to realize that even if you think something will be easy, it won't be so, a project will always be at least 20 times harder than you estimate (even if you already have experience in estimating project difficulty). Making a game is not just about programming it (which itself means debugging, refactoring, writing tests, debugging tests, organizing repos, designing APIs, studying libraries, ...), you'll also have to document it, play test it (many, many times over), debug it, optimize it, package it, make a website for it and a billion other things. If you decide to make a game like GTA (or even just Pokemon clone or something) but you haven't made at least 10 games already, YOU WILL FAIL, it will be a disaster and completely wasted time. Unless you've done like 10 projects already, choose dead simple things like Tetris clone or something (see [exercises](exercises.md) for beginner project tips). Remember, the goal of your first project isn't the thing in question but rather learning about making a project and finishing it.
-- **[FINISH](finished.md) THE FUCKING PROJECT.** Unfinished project will just have wasted your time, it will leave you disgusted, broken, depressed and defeated, it will be of no use to anyone, you'll just feel like [shit](shit.md). For this it is important to choose something simple -- if you finish the thing, you'll be happy regardless of how simple it really was, you'll be eager to make more things, people will be able to use your project, they'll be thanking you for it which will further make you more happy and so on. Even if it's a freaking minesweeper, you've made your own game now, it brings happiness to people, you can take a look at it every time you'll feeling down and be a bit happier.
+- **[FINISH](finished.md) THE FUCKING PROJECT.** Unfinished project will just have wasted your time, it will leave you disgusted, broken, depressed and defeated, it will be of no use to anyone, you'll just feel like [shit](shit.md). For this it is important to choose something simple -- if you finish the thing, you'll be happy regardless of how simple it really was, you'll be eager to make more things, people will be able to use your project, they'll be thanking you for it which will further make you more happy and so on. Even if it's a freaking minesweeper, you've made your own game now, it brings happiness to people, you can take a look at it every time you'll be feeling down and be a bit happier. On the other hand however if your project still ends up failing don't become too depressed and try to take the best of it -- it's not the end of the world, you have acquired some experience and you may still try to reuse parts of the failed project elsewhere, just try to extract maximum good.
 - **Take long breaks**, enjoy the fact this is not a "[job](work.md)" -- when you've become fed up with your project, take a pause. If you have other projects, you may hop onto another one (but if you're simply overall tired, just take a full vacation, go play games or whatever). In a week, month or a year you'll start to feel the urge to get back to it and when you do, it's a sign you'll be enjoying doing it again, it's very likely you'll then get a period of """[productivity](productivity_cult.md)""" (better said just enjoyment) and inspiration. Also when you get stuck or stand before an important decision taking a break is very much advised, you need a fresh mind and even if you make a decision, take a few more days to see if you still think it's good after some time.
 - **Have multiple projects in progress**. This is cool for several reasons, for example it prevents a burn out of a single project -- if one projects becomes boring, shows to lead nowhere or you simply get tired of it for a while, you switch to a different one. Even if it fails completely and you delete it, you still have many other "children", it won't be a disaster. Sometimes you have a period when you want to program, so there's a programming project waiting for you, other times you feel like you wanna do music, and there is the project that needs some music, just ready for you. So this also stimulates you in different ways. And sometimes you get surprised if some small project turns into something unexpected maybe. It's just good to have this diversity in your art.
 - **Do everything yourself and keep switching tasks**. This is similar to the other point about having multiple projects, just within a single project. Be your own programmer, graphic designer, musician, tester, writer and so on -- at least as much as possible. This not only helps you become a cool generalist, an independent, non-capitalist living being, but also prevents burn out from doing the same activity over and over.