3 ms·

You could easily make an argument that the same philosophy will benefit rapidly growing projects for full time devs. The less "arcane" knowledge needed to work

You could easily make an argument that the same philosophy will benefit rapidly growing projects for full time devs. The less "arcane" knowledge needed to work effectively in the code base, the faster new engineers can onboard, the faster old code can have small changes made without breaking something else unexpectedly, and the list goes on.

gwbas1c 7y ago
The problem with assumptions is that no one knows they make them while they make them. It's a case of what's obvious to me isn't obvious to you. It's also a case of things that aren't obvious on day one, but become obvious on day 3, or day 6.
Crinus 7y ago
Sure, FWIW i wasn't trying to make an argument about keeping fulltime devs away. Trying to keep the codebase hackable for non-fulltime devs will also help fulltime devs too and even attract non-fulltime but otherwise dedicated (in their free time) devs. It is a good thing for everyone involved (assuming of course that the project does want others to be involved - there are projects that only release code but development happens behind closed doors). Of course projects generally do not go with a goal of making it hard to have people contribute, it happens organically as the project grows. But i think after a project has realized they are in such a situation, they should make the necessary changes and improvements to get out of that situation.
hrktb 7y ago
Wouldn’t it be inversely proportional to the complexity allowed in the project ? I imagine for instance a situation where for instance the project starts with a clear REST approach where GET requests are purely idempotent with no side effects whatsoever. Then people start adding internal side effects (e.g. tracking, behavior scoring, suggestion building, and so on). It’s harder to explain to a new dev that from some angle these requests are read only and nothing changes, and from another angle they change a lot of things. But it would be counter productive to give up on features because it makes things less simple and brings a learning curve.

gwbas1c 7y ago

The problem with assumptions is that no one knows they make them while they make them. It's a case of what's obvious to me isn't obvious to you. It's also a case of things that aren't obvious on day one, but become obvious on day 3, or day 6.

Crinus 7y ago

Sure, FWIW i wasn't trying to make an argument about keeping fulltime devs away. Trying to keep the codebase hackable for non-fulltime devs will also help fulltime devs too and even attract non-fulltime but otherwise dedicated (in their free time) devs. It is a good thing for everyone involved (assuming of course that the project does want others to be involved - there are projects that only release code but development happens behind closed doors). Of course projects generally do not go with a goal of making it hard to have people contribute, it happens organically as the project grows. But i think after a project has realized they are in such a situation, they should make the necessary changes and improvements to get out of that situation.

hrktb 7y ago

Wouldn’t it be inversely proportional to the complexity allowed in the project ? I imagine for instance a situation where for instance the project starts with a clear REST approach where GET requests are purely idempotent with no side effects whatsoever. Then people start adding internal side effects (e.g. tracking, behavior scoring, suggestion building, and so on). It’s harder to explain to a new dev that from some angle these requests are read only and nothing changes, and from another angle they change a lot of things. But it would be counter productive to give up on features because it makes things less simple and brings a learning curve.