Update

project.md

@@ -10,7 +10,7 @@ Firstly a word of warning: stuff about how to plan projects, lead them, get peop
 
 Also let it be said that everyone has to find his own way of doing projects, it's just like with learning for example: everyone has his own ways, what works for one may not work for another. The advice here will come firstly from the author's ([drummyfish](drummyfish.md)) personal experience and secondly from general [LRS](lrs.md) principles. Also even though we'll mostly be talking about programming projects, a project can be anything really, what we say applies also to making a [music](music.md) CD or writing a [book](book.md). Here we go:
 
-- **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.
+- **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. Make it tool-agnostic -- your programming project mustn't be a project for your programming IDE, your book shouldn't be directly written in LaTeX (rather write it Markdown which will enable you to compile to LaTeX as one of many target formats), your song mustn't be a project for your DAW 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 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.