Terence Eden on the oddly narrow definition of family

I was recently browsing some blogs and came upon Terence Eden’s Blog and a post titled Falsehoods Programmers Believe About Families. I have no doubt that much of the oddly limited definition of family comes from oddly narrow ideas. I think some of it comes from not thinking about the users who use your system.

For example, I’ve seen family tickets which cover two adults and two children. That’d be no good for us growing up. I had three siblings; two of us would be left out under this limited definition.

The thing about people is that we rarely fit into the neatly defined boxes that executives and marketing agencies try to put us in.

The same limitation applies to names. I have a friend who had to invent a surname to make life easier because, without one of those, a lot of computer systems got very confused.

Programmers encounter similar limits for email validation, dates, time zones, leap years, and non-standard addresses. I think this is because programmers have yet to encounter all the many edge cases that make good data validation a truly horrible problem to solve well.

But, yeah, they also misunderstand what makes a family. We need should change the general awareness of what a family is. Starting with how many adults and minors make up any given family unit.

#family #lies #nonStandard #programmers

Rather than considering even just once the needs & massive benefits for creators and maintainers, current open source software infrastructure, support tools, but also developer culture itself is completely biased and optimized purely for the benefit of consumers/users. Choosing a non-standard project structure (in my case a mature Google-style monorepo with almost 200 largely independent, but related projects/libraries/tools) is increasingly actively punishing my work and efforts in a variety of ways, e.g.

- non-supportive UIs for improved browsing/overviews of monorepos
- harmed discovery via search & metadata limitations
- wrong, misleading and downgraded project ranking calculations (npm)
- misleading/broken automated project analysis (GitHub)
- lack of support by documentation tooling (TypeDoc)
- lack of support by package managers (Zig) and/or hosting platforms

All of these (and more) factors are actively hurting, disqualifying & even completely nullifying much of my time & energy spent on these projects, making my dream goal of working on open source fulltime increasingly intangible (because the above factors all have an actively downgrading effect which makes these project seem lower quality/relevance). To some extent this is purely because this work is stored in a project structure which is optimized for maintenance & automation. Technically, we're speaking about _one_ additional level of nesting. An extra subdirectory! Otherwise, not any different than a "normal" repo. Still — BOOM — confusion, inflexibility & punishment ensues! 😫😭

So many external aspects and people do not give a damn that a monorepo setup like this and the custom tooling created to automate the maintainance and cross-linking of all these ~360 packages (incl. example projects) are _the only sane way_ for me as a single person to efficiently manage & release a codebase of this magnitude.

I was aware of some misunderstandings about monorepos on purely social/human level, but never saw it coming that the more I was expanding and deepening this work, the more this structure and scope would hurt the project & my goals, because 3rd party infrastructure is just as weirded out by such a "blasphemy" as some people are...

I'd genuinely like to hear ideas what I could/should do to escape the vicious circle created by the above factors, which is a real motivation killer... I really do wonder how other maintainers (esp. would like to hear from indie devs)
handle projects & codebases of this scale without running into these issues...

Thank you for any insights!

Ps. I really seem to have a feeble for "think different" and going against the grain with these things (or maybe being too early?). The first set of 20+ https://thi.ng libraries for Clojure/ClojureScript were mostly written in a #LiterateProgramming format, often combining source code with diagrams & tables — this too led to many complaints and was partially to blame for not gaining much traction, even though these projects were singular offerings to that language community at the time (and funnily only became more popular _after_ 6-7 years, once I'd already left Clojure behind... go figure!)

#OpenSource #MonoRepo #Maintainance #Infrastructure #Documentation #Tooling #SocialCoding #Expectations #NonStandard

I will #AlsoAlsoAdd...

#TheFormerUnitedKingdom has its own #System of #Measurements including (but not limited to):

• #DoubleDeckerBuses (Height)
• #OlympicSwimmingPools / #FootballPitches (Length)
• #Wales / #Belgium (Geographic Landmass / Area)
• #Heffalumps (Weight)

These are #NonStandard #UnitsOfMeasurement; we can #BlameBrexit if you #Like...

#IT won't #AffectTheOutcome...

🧙⚔️🤖🐺🤖⚔️🧙 | ☕️🍪🍫🦄🍫🍪☕

https://vmst.io/@PSiReN/110566782132271097

Leave it to a #Canadian plumbing manufacturer to use a pipe thread that isn't standard Imperial units/thread (traditional plumbing sizes in Canada) *or* ISO standard metric threads.

18mm diameter, 1mm thread pitch. ISO specifies 1.5, 2.0, or 2.5mm thread pitch...

#standards #plumbing #manufacturer #weird #nonstandard #aargh

@selzero

I will #AlsoAlsoAdd...

#TheFormerUnitedKingdom has its own #System of #Measurements including (but not limited to):

• #DoubleDeckerBuses (Height)
• #OlympicSwimmingPools / #FootballPitches (Length)
• #Wales / #Belgium (Geographic Landmass / Area)
• #Heffalumps (Weight)

These are #NonStandard #UnitsOfMeasurement; we can #BlameBrexit if you #Like...

#IT won't #AffectTheOutcome...

🧙⚔️🤖🐺🤖⚔️🧙 | ☕️🍪🍫🦄🍫🍪☕