> "I just searched for 'tooltip' in the entire code base, examined stuff for possible candidates, and inserted debugging print statements to follow the execution,"
Humans are great at talking about problems for extended periods of time, ad nauseam, and less good at just getting starting on the solution.
There are at least 6 or 7 bugs and tiny missing features in the software I own at work that would improve the dev and support experience, but I always feel guilty stopping work on my main tasks to tackle them.
This is exactly why I’m anti-agile/scrum. You have to get buy in from your manager, team, and product owner for every bit of your productivity, and taking on work that is not explicitly scoped without consulting the broader group is considered being a bit of a cowboy.
Well, I am a bit of a cowboy. But I’m fortunate enough to have a management chain who trusts me to prioritize and incorporate small fixes and features as part of regular development. Admittedly it’s easier when your customers are internal devs, because you know exactly what they want after fielding their stream of questions, support requests, and “would be cool if”s.
Per scrum, only the product owners get to prioritize the backlog, and only dev team should selecting tasks. No manager or team buy in.
And if it's an internal tool, then those devs are your product owners.
The first principle of agile is people over process. A lot of people like to blame agile for processes that their own teams just made up instead of taking accountability.
My teams have quarterly "do whatever you want" sprints where bugs like this are targeted.
Doesn't really explain it. Usually projects are cliques where your contributions will be ignored unless you know somebody on the inside. The only thing the article says is "In the next few hours, they heard from Emilio Cobos Álvarez, who refined Zhu's approach and helped get the commit into the code base." What's the story there?
Agreed, they have a pretty nice setup for a "big" company. I've been contributing code to Mozilla for the last few years despite not working there and I got started on https://codetribute.mozilla.org/
The most annoying parts would be familiarizing yourself with mercurial/phabricator and getting commit access for certain projects.
I've had great experiences contributing small bug fixes like this to various large-ish projects. In any organization that has a process for reviewing GitHub PRs, there should be minimal friction.
If you want to add a new feature with hundreds of lines of code, sure, that's going to be a more involved process.
While I understand the sentiment, I think we might not necessarily need more people in the world, but enable more people who already came to life to live up to their potential.
Too much human potential is wasted in under developed regions.
> Too much human potential is wasted in under developed regions.
Too much human potential is wasted in highly developed regions as well, but it's not a question of access to resources, it's a question of living in a dysfunctional society driven by a lot of things that aren't "hey, how do we make the world better?"
Was always the case. Adding more monkeys with typewriters will get you Shakespeare sooner which is why I’m excited for the future of entertainment & software.
I kinda dislike this sensationalism regarding XY years old bugs. Every large old projects have such old bugs and it's quite normal that if it's so low impact, it doesn't get prioritized.
This bug isn't just old, it was a bug that probably every Firefox user has experienced and learned to work around. Just because it was "low impact" didn't mean it wasn't personally experienced.
Readit News
This guy gets it
Yup, he gets it.
The best debugger there is, and there ever will be. All hail: the printf!
There are at least 6 or 7 bugs and tiny missing features in the software I own at work that would improve the dev and support experience, but I always feel guilty stopping work on my main tasks to tackle them.
Well, I am a bit of a cowboy. But I’m fortunate enough to have a management chain who trusts me to prioritize and incorporate small fixes and features as part of regular development. Admittedly it’s easier when your customers are internal devs, because you know exactly what they want after fielding their stream of questions, support requests, and “would be cool if”s.
And if it's an internal tool, then those devs are your product owners.
The first principle of agile is people over process. A lot of people like to blame agile for processes that their own teams just made up instead of taking accountability.
My teams have quarterly "do whatever you want" sprints where bugs like this are targeted.
The most annoying parts would be familiarizing yourself with mercurial/phabricator and getting commit access for certain projects.
If you want to add a new feature with hundreds of lines of code, sure, that's going to be a more involved process.
also, here's the original submission of the bugzilla ticket: https://news.ycombinator.com/item?id=37827995
I liked the Ars Technica story in addition to the bugzilla ticket b/c of the information about the actual bug fixer themself.
https://bugzilla.mozilla.org/show_bug.cgi?id=148624
Too much human potential is wasted in highly developed regions as well, but it's not a question of access to resources, it's a question of living in a dysfunctional society driven by a lot of things that aren't "hey, how do we make the world better?"