Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
If I think of a new feature to add, I create an issue
If the functionality feels incomplete, I create an issue
If I finish a feature but feel like it could use more improvement, I create an issue
Any time I think about anything remotely related to the functionality, usability, quality, maintainability, documentation, etc. I create an issue
Projects with issues outstanding need work. Projects with no issues are in 'maintenance mode' for now.
Each issue is an idea, a piece of creativity, a monkey off my back, and a task that -- if I do a lot of things right -- other Devs may even pick up to work on.
Most importantly, an issue marks a milestone; the scope of which is more or less frozen.
Scope creep will inevitably kill motivation. That's why companies who treat Scrum as a moving target or as a method to 'extract' more 'work' burn out their Devs faster than they can hire new ones. That's why 'side projects' -- for the majority of Devs -- usually become 'side burdens'.
Endlessly working toward an infinitely unachievable goal is literally the definition of Hell. Why would you ever literally put yourself through Hell? For a side project?
How about no...
Units of work should -- as often as possible -- have a finite 'done' moment. When you learn to revel in the joy of being 'done' as often as possible. Then -- and only then -- will side projects cease to feel like 'work'.
And not unironically, that's when you'll magically start to finish them.
If you made it this far, thanks for coming to my Ted Talk.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I use a very simple strategy
If I think of a new feature to add, I create an issue
If the functionality feels incomplete, I create an issue
If I finish a feature but feel like it could use more improvement, I create an issue
Any time I think about anything remotely related to the functionality, usability, quality, maintainability, documentation, etc. I create an issue
Projects with issues outstanding need work. Projects with no issues are in 'maintenance mode' for now.
Each issue is an idea, a piece of creativity, a monkey off my back, and a task that -- if I do a lot of things right -- other Devs may even pick up to work on.
Most importantly, an issue marks a milestone; the scope of which is more or less frozen.
Scope creep will inevitably kill motivation. That's why companies who treat Scrum as a moving target or as a method to 'extract' more 'work' burn out their Devs faster than they can hire new ones. That's why 'side projects' -- for the majority of Devs -- usually become 'side burdens'.
Endlessly working toward an infinitely unachievable goal is literally the definition of Hell. Why would you ever literally put yourself through Hell? For a side project?
How about no...
Units of work should -- as often as possible -- have a finite 'done' moment. When you learn to revel in the joy of being 'done' as often as possible. Then -- and only then -- will side projects cease to feel like 'work'.
And not unironically, that's when you'll magically start to finish them.
If you made it this far, thanks for coming to my Ted Talk.