YAGNI (You Aren't Gonna Need It) principle

Practical part

• use decided architecture
• prioritise work through tickets
• don't go over minimal ticket scope

Theory behind

This principle alone is very helpful for time-management.

Many developers learn to think in a wider scope to cover all possible options. That's good during the architecture phase of the project, or for reviewing tickets in sprint planning, but not during programing. Don't forget, you aren't going to need it.

Do you know that feeling to add some more functionality to what you are currently programming? It is better to solve it somehow differently than by immediate coding. It will also save your time. And it’s worthless to program something that must be redone or will not be used at all. Client or your manager may not be keen to some fancy functionality, primarily if that means delays to project.

You can just forget what you want to add to the program. But it is sometimes hard to let go and to keep things in mind forever is also not a solution. This principle is better applicable when you have a roadmap to follow. In some companies, you can discuss your ideas with other people (architect, team leader, manager, client) and/or put them into some mind-map/todo/ticket software for later use. Please don’t “todo” code directly! Beware of “todo” ocean, in which even you won’t recognize your own “todos” in time. "Todos" in code are distracting and will imply that you haven't finished your work for anyone reading code after you. On any project, look at the roadmap and time this new functionality will consume from it. Maybe you can find time after you finish main work. And if you have time for every special functionality, congrats, you must be the luckiest or fastest developer on Earth.