I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
I feel you. The Javascript lib part is especially tiring if there's more than one person involved
"Yes, I know, but this is a better approach"
"I've worked with this module before, it's very easy to integrate" [every so often, it ain't]
"Trust me, this will work 100%"[well, if you say 100% ...]
A way to counter it, especially with your own projects, is to satisfice. Set yourself a level of 'done' for a project which you can live with - and then leave it be. I mean:
Use full path for README.md <- that's issue #71
Decrease font size <- that's issue #60
Add credits <- that's issue #46
Please don't get me wrong with the following statement - but do you really need this stuff? Does it offer any additional benefit for the user? Is the time you spend doing it going to save opportunity cost for somebody else ( dev, user, admin, tester, ... )?
If not, scrap it for good and focus on enhancements that add value to your product.
It's a big shot, and adaption to it takes time, but try and give the Getting Things Done approach a try. The book and the methods presented are definitely worth reading imo.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Yes some of the issues are really minor and maybe I'm not sure how to do them or whether to do them.
So I focus my time on what makes notable difference to my enjoyment of using the tool or fixing something that annoys me every time I use it. I can be more deliberate about that.
My manager actually recommended I schedule a time to groom my own issues, like we have agile grooming at work. Then I can close issues that no longer matter or I can prioritize which ones to do first. GitHub lets you pin 4 issues in a project, so I like that for focus.
I like your comment on thinking how a task benefits another user. If something has few stars, then few people are really affected by the quality of project or how many things are done. So I should choose which projects and tasks make sense.
Thanks I'll have a look at Getting Things Done.
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 feel you. The Javascript lib part is especially tiring if there's more than one person involved
A way to counter it, especially with your own projects, is to satisfice. Set yourself a level of 'done' for a project which you can live with - and then leave it be. I mean:
Please don't get me wrong with the following statement - but do you really need this stuff? Does it offer any additional benefit for the user? Is the time you spend doing it going to save opportunity cost for somebody else ( dev, user, admin, tester, ... )?
If not, scrap it for good and focus on enhancements that add value to your product.
It's a big shot, and adaption to it takes time, but try and give the Getting Things Done approach a try. The book and the methods presented are definitely worth reading imo.
Thanks for your comment.
Yes some of the issues are really minor and maybe I'm not sure how to do them or whether to do them.
So I focus my time on what makes notable difference to my enjoyment of using the tool or fixing something that annoys me every time I use it. I can be more deliberate about that.
My manager actually recommended I schedule a time to groom my own issues, like we have agile grooming at work. Then I can close issues that no longer matter or I can prioritize which ones to do first. GitHub lets you pin 4 issues in a project, so I like that for focus.
I like your comment on thinking how a task benefits another user. If something has few stars, then few people are really affected by the quality of project or how many things are done. So I should choose which projects and tasks make sense.
Thanks I'll have a look at Getting Things Done.