This person obviously has their own way of doing things that works for them and that’s great. Some of his views are patently absurd though. This is mostly commenting on his reasons against using a forge and not a comment that he should do something differently.

Trust

100% fair and I think this is the main take-away from the blog post. If you don’t trust something, don’t use it. Full stop, the post could have ended there and been fine. But then it goes on to say:

You get a workflow imposed on you

You mean like forcing people to use email to submit pull requests to your self-hosted git repos? It doesn’t matter what you are doing, if you are working on an open source project you are going to have workflow limitations. This is arguing a fallacy.

In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system.

Nothing is forcing you to use these features so just don’t use them. Plenty of teams use 3rd party tools but host their code in a forge site. Having options available to you automatically is not the same thing as being forced to use them. If it was, JIRA wouldn’t exist because everyone would use github/gitlab/whatever’s built-in issue tracking and project management.

The majority of the post comes across as someone who just doesn’t like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don’t exist.

Trust is 100% the main reason not to use a forge site and all the other things cited are superfluous and/or very subjective.

Yeah we aren’t anywhere close to the point of states breaking out of the union. Some people will call for it, maybe even a lot. But as soon as they realize what is required that shit will stop immediately. California would quite literally need to go to war with the union to gain that independence regardless of what they voted. So not only would they need to actually vote for it but then they’d have to be willing to go to war and kill and die for that separation and their independence.

As strong as people feel, we aren’t even close to that point. Not to mention it would fail; none of the states currently have any hope of competing against the US military machine. Give us a couple hundred more years to really really deteriorate and siphon all value from the people and land and we may be there.

It’s hard to truly internalize this but no matter what you think about something and/or how wrong you think someone else is, we are walking through life with imperfect imaginings of what other people think and feel. Trying to make sense of people is even harder than making sense of a person. And we are quite literally incapable of truly knowing what goes on in someone else’s head.

Definitely ask these questions but don’t drive yourself crazy if people don’t make sense. The behaviors and actions we witness in others are only the emergent characteristics of a lot of brain activity that we aren’t privy to.

This post is a journey, not a destination.

That people are inherently good. This not being the case is reinforced near daily by people’s behaviors.

People in this thread are throwing around the term “smarter” a lot and I think we should avoid that. How quick you pick things up might be an indicator for being smart but it is only one aspect. The following are generalizations and there are always exceptions so keep that in mind.

What you will find in life is a lot of the people like you describe have generally shallow knowledge of a subject but are capable of ramping up quickly and filling out that deeper knowledge as needed. Meanwhile, the folks who tend to take longer and study more retain more of the knowledge and are more capable at using it without supplemental data or analysis.

It is the difference between knowing an answer and knowing enough to quickly find the answer.

It feels disingenuous to approach this topic with the view that the eggs are the problem and people need to just eat fewer eggs.

The problem is the food cost increases and the eggs are just one example. It’s called nuance and we’ve lost our ability to understand it. Stop trying to blame consumers for this when it is driven by profits.

This is the reason.

I agree with everything you said but I think one thing that is often overlooked is how the boomers are virtually all lead poisoned. Gen-X and some Millennials as well but the Boomers took the brunt of it. They grew up with lead gas poisoning the air, lead pipes (well, a bigger percentage anyways) poisoning the water, lead tools poisoning the workers, lead bullets poisoning game, and so forth. Lead poisoning does some fucked up stuff to people’s cognitive abilities. The lead problem still exists but the scale of the problem back when the boomers were growing up was on a whole different level.

Exposure to lead can result in a variety of effects upon cognitive functions including deficits in general intellectual functioning, ability to sustain attention on tasks, organization of thinking and behavior, speech articulation, language comprehension and production, learning and memory efficiency, fine motor skills, high activity level, reduced problem solving flexibility and poor behavioral self-control.

https://www.mwph.org/health-services/lead-treatment/poisoning-effects

Also not saying they have an excuse, just saying I think lead poisoning of > 1 sequential generation affected a lot of decisions. Most probably small but all of them adding up to set the stage for our current situation.

I think the 3 points are decent guidance in general but I feel you probably should have included some examples of when it doesn’t make sense to follow them. Like everything in life, the actual realization of something is more complicated and we should provide guidance that speaks to nuances that might affect design/implementation decisions. It’s something I think we lost (or the loss accelerated) within the last 15-20 years. Now everything is “you have to do this or you’re terrible at programming” and the nuances are lost as the entire thing is framed in a way to try to grab attention/views. I don’t mean to imply you’re doing that here, just a general observation that articles and videos on programming rarely include more nuanced things.

Anyways, I agree with the overall content of the post but felt I’d provide some counter examples for each point. Admittedly they may not be the best but calling out something like them I think would be worth doing so readers have a wider view of the topic and can make more informed decisions.

Point 1: This is great general advice; be consistent with your names. However, it’s simply not feasible in certain situations. Are you building a data access library? You’re going to need dynamically named things. Maybe your system has thousands of tables (yes it happens, the real world is messy). I would much rather work on a system that uses dynamic names which enforces naming consistency than deal with some switch statement covering hundreds/thousands of things. Not only would the code be cleaner and easier to deal with that way but it would have the added benefit of running everything through the same naming logic and therefore helping with name consistencies.

Point 2: Name consistency is important (see end of above) but don’t force it when it doesn’t make sense. If you have two distinct systems/services that each operate in different domains but share some underlying data source. Maybe the enrollment service calls something an enrollment but the billing system calls it a line item. The freedom to name things appropriately for how they’re used is important and should be another tool in your belt. It also helps business users/managers/etc… and programmers have a shared understanding of domain terminology/requirements/etc…

Point 3: I’d agree for the most part and this is generally great advice. Sometimes it makes sense to go hierarchical. For example human readable configs can benefit from hierarchical structures since we like to process information by grouping things. I’d rather just have a json or yaml section called DataSources than have to repeat the “datasources.datasource1.name”, “datasources.datasource2.name” and so forth for every single datasource defined in the config.

I think the points you made are great. We should use them when appropriate though and knowing when it’s appropriate or not is something we should try to teach along with the rules themselves.