That's not (just) gatekeeping. People try to internalize a positive self image, from positive internal and external validation. Skills can also be a source of status or meaning (usefulness to others).
Taking that away compounds with the crisis of meaning we already have to make people feel more alienated than ever.
> "The need to be observed and understood was once satisfied by God. Now we can implement the same functionality with data-mining algorithms."
> "God and the gods were apparitions of observation, judgment and punishment. Other sentiments towards them were secondary."
> "The human organism always worships. First it was the gods, then it was fame (the observation and judgment of others), next it will be the self-aware systems you have built to realize truly omnipresent observation and judgment."
> "The individual desires judgment. Without that desire, the cohesion of groups is impossible, and so is civilization."
> "The human being created civilization not because of a willingness but because of a need to be assimilated into higher orders of structure and meaning."
> "God was a dream of good government."
> "You will soon have your God, and you will make it with your own hands."
I'm guessing you work on some highly technical domain that receives highly structured data and is amenable to TDD.
Not all domains are like that. The majority of bugs I see are business/domain logic bugs. It's akin to having misunderstood or missed some aspect of the question, not causing data loss.
I'm guessing you work on some highly technical domain that receives highly structured data and is amenable to TDD.
I lead a group of teams that build frontend software, so not really. :)
The majority of bugs I see are business/domain logic bugs. It's akin to having misunderstood or missed some aspect of the question, not causing data loss.
Financial loss, reputational harm, degraded UX, etc. They're all significant problems. They're more recoverable than a data loss, but equally bad from an accepted low quality standpoint.
I'm also going to guess that you don't have BAs, PMs, or people responsible for the logic reviewing the code in a PR. Consequently you can't spot those problems in at the PR gate unless the issue is that the dev didn't understand the requirements and wrote code that didn't do what it's supposed to. In which case we're back to the quality and testing problem. By raising questions in standup ("Can I clarify that I understand the AC right?"), pair programming ("Let's check the code against the AC") and communicating properly ("Can you demo the feature to the BA so we can be sure it's correct") you move the problem to the people who can answer, and stop the devs needing to review that someone wrote working code.
I just don't believe PRs are the right point to be finding out that the requirements were wrong or that the dev didn't understand what to build. That needs to happen as early as possible. PR is as late as possible.
It sounds like you work at a company where the responsibilities of engineering are split across at least three separate roles, things move slowly and in a structured way, there's a large amount of coordination work, and a PR is a methodical translation of some step-by-step process. Perhaps you have bi-weekly meetings to review RFCs or similar.
At a much smaller company, you might find that a single person does part of the job of a BA, PM, and engineer, that they can produce a PR much more quickly as a result, and that it's more common for a PR to prompt the first detailed discussion about how something will work. A small team has quicker turnaround time on PRs and design, and can thus position in-depth reviews later in the process because less work will be thrown away in the case of a rejection.
I've held this view as a senior dev in a small company, a senior dev in a big compant, the co-founder CTO of a startup with 5 devs, and I continue to hold it now I'm an EM with many teams in a really big company. It's not about team size. It's about fixing the right problem in the right place. PRs just aren't that. They're useful if you have a problem with people not meeting a good standard, but they're not useful as a gate for whether or not the code works or if it's been architected in a sensible way. You need to know those things earlier (especially in a startup where speed is paramount.)
I disagree in some cases. Code is a means of communication. Sometimes it's more efficient to write code and bring it to your team than to discuss it in the abstract.
An example of this might be adding load shedding. You could spend hours talking through it, or you could say "I'm going to add a load shedder to the blah service as a proof of concept" in standup then take an hour to implement it, and have the team critique it from there.
I agree that whether they're a useful gate is debateble, but they can be a useful means of expressing an idea to be approved or rejected.
In my teams work like that would ideally be done as a proof of concept on a branch that's ultimately throw away. It would never reach a PR. Reality doesn't always work that way, and sometimes those POCs make their way into production, but it should. I certainly wouldn't want the decision to merge it into the main codebase to be done in a PR. That sort of thing needs proper discussion.
If I trust you know what happened, and trust you to know what to do so it doesn’t happen again, why do I need to know? And how will I know (and endorse) your decision if I don’t know what happened?
Why go for a configuration based format over a library though? Something like Streamlit or Dash offers more control and lends itself better to interactive exploration.
A library is for coding in the classical sense. Declaring in YAML is a very light form of coding I would say, much more accessible to non-engineers. A simple dashboard in YAML is so much more readable to a human than some python code that uses a library. This is mainly a audience question.
If there's a use case in the future, we could consider also offering a library. But if you just want to vibe code dashboards in actual code, there's plenty out there already that will give you JS code (predominantly).
When I have seen instances of this, it's usually because there is another variable. Example from wikipedia:
>A common example of Simpson's paradox involves the batting averages of players in professional baseball. It is possible for one player to have a higher batting average than another player each year for a number of years, but to have a lower batting average across all of those years. This phenomenon can occur when there are large differences in the number of at bats between the years.
The per-year values aren't weighted in the combined total average.
In regulated industries and government they aren't going to be allowed to process your appeal with just AI, so there's a cost asymmetry there that favors the "ddos"ers.
reply