4 ms·

If you're using the technology a lot, the developers should already be diving into the codebase and improving it. No software is perfect and sometimes the best

by TheDong 12y ago

If you're using the technology a lot, the developers should already be diving into the codebase and improving it. No software is perfect and sometimes the best way to fix your code is to actually fix whatever dependency is causing the problem and push it upstream. I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter.

girvo 12y ago
> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter. In my experience, developers often do everything possible to avoid working on dependencies (in a way that can be contributed upstream). While it may be the case that developers in SF or other big developer hubs do so, where I live most developers are content to either hack a fix into it, or work around it in their app code instead. Luckily, it makes getting a job easier for myself as I do have a number of open source contributions I can point to, which a lot of other devs around here lack. I had to explain to a recruiter what GitHub was, once.
deathanatos 12y ago
> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter. I don't think this was the intention of the link — I think it's a good faith request for engineering time. It's asking for two days per month in situations where there are presently no days per month. If someone in management is focused exclusively on what the next feature that's being implemented is—what things cause a developer pain isn't ever going to get captured by that. Probably at least half of the time, by the time I work out a bug in a third-party (or even first-party) library, I already have a hack or workaround. The cheapest thing, in the extreme short-term, is for me to just go with the workaround, and let every future developer experience the same pain. Of course this is a bad decision, but I suspect this is part of what is motivating the author of our manifesto. Of course, the downside to not sending things upstream (and contributing to FOSS in general) is that developers end up solving the same stuff over and over again. I can, off the top of my head, think of a couple problems I've solved myself multiple time, across multiple employers. Wasted time. edit: to be clear, I see your point, I think: the spirit here is what we're after, not rigid adherence to 2 days / month, and it fair to say that perhaps the link should speak to that, lest someone read it too literally. Also, keep in mind that it takes a good bit of work: if you patch a third-party dep, you need to somehow deploy/integrate that patch into your process in the meantime; you need whatever approvals internally you need to upstream the change; you need to ensure the patch is reasonable (e.g., not a hack) to upstream; you need to actually send to upstream and deal with any feedback from upstream (and in some cases, hope the upstream is even still alive). It can be several months later that upstream finally accepts the patch and cuts a release, and then you need to upgrade to that release.
gcb0 12y ago
heh. developers in a fortune 500 company will work around issues/misunderstandings in code from the same company... let alone some 20 open source projects they were told to use by some architect
LoSboccacc 12y ago
my first thought exactly. however I mostly find that many devs simply put workarounds out of the library (and suffer great pains when update time comes) or fix the library and never push the changes upstream consider that many fixes, even when proper, may not be ready for submission, and many companies are penny pinching devs already and can hardly justify prettying up a fix for submission and prefer to establish a culture of 'fix it in the least amount of time'. two days are a reasonable amount of time to get existing fixes in the codebase, clean them up to the library owner's guidelines, document them, the issue they solve, build a test case and deliver it upstream. two days are not enough for coding a workaround, and barely the minimum to prepare a patch properly. that I think was the intent. as you say devs need to fix up things anyway, and two day a month to push upstream goes a long way to reduce work further the line (and I'm purposely ignoring the 'do good' argument)

by TheDong 12y ago

girvo 12y ago

> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter. In my experience, developers often do everything possible to avoid working on dependencies (in a way that can be contributed upstream). While it may be the case that developers in SF or other big developer hubs do so, where I live most developers are content to either hack a fix into it, or work around it in their app code instead. Luckily, it makes getting a job easier for myself as I do have a number of open source contributions I can point to, which a lot of other devs around here lack. I had to explain to a recruiter what GitHub was, once.

deathanatos 12y ago

> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter. I don't think this was the intention of the link — I think it's a good faith request for engineering time. It's asking for two days per month in situations where there are presently no days per month. If someone in management is focused exclusively on what the next feature that's being implemented is—what things cause a developer pain isn't ever going to get captured by that. Probably at least half of the time, by the time I work out a bug in a third-party (or even first-party) library, I already have a hack or workaround. The cheapest thing, in the extreme short-term, is for me to just go with the workaround, and let every future developer experience the same pain. Of course this is a bad decision, but I suspect this is part of what is motivating the author of our manifesto. Of course, the downside to not sending things upstream (and contributing to FOSS in general) is that developers end up solving the same stuff over and over again. I can, off the top of my head, think of a couple problems I've solved myself multiple time, across multiple employers. Wasted time. edit: to be clear, I see your point, I think: the spirit here is what we're after, not rigid adherence to 2 days / month, and it fair to say that perhaps the link should speak to that, lest someone read it too literally. Also, keep in mind that it takes a good bit of work: if you patch a third-party dep, you need to somehow deploy/integrate that patch into your process in the meantime; you need whatever approvals internally you need to upstream the change; you need to ensure the patch is reasonable (e.g., not a hack) to upstream; you need to actually send to upstream and deal with any feedback from upstream (and in some cases, hope the upstream is even still alive). It can be several months later that upstream finally accepts the patch and cuts a release, and then you need to upgrade to that release.

gcb0 12y ago

heh. developers in a fortune 500 company will work around issues/misunderstandings in code from the same company... let alone some 20 open source projects they were told to use by some architect

LoSboccacc 12y ago

my first thought exactly. however I mostly find that many devs simply put workarounds out of the library (and suffer great pains when update time comes) or fix the library and never push the changes upstream consider that many fixes, even when proper, may not be ready for submission, and many companies are penny pinching devs already and can hardly justify prettying up a fix for submission and prefer to establish a culture of 'fix it in the least amount of time'. two days are a reasonable amount of time to get existing fixes in the codebase, clean them up to the library owner's guidelines, document them, the issue they solve, build a test case and deliver it upstream. two days are not enough for coding a workaround, and barely the minimum to prepare a patch properly. that I think was the intent. as you say devs need to fix up things anyway, and two day a month to push upstream goes a long way to reduce work further the line (and I'm purposely ignoring the 'do good' argument)