Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AG
AggressivelyPassive @ agressivelyPassive @feddit.de
Posts
16
Comments
1,465
Joined
2 yr. ago

  • That won't change a thing, unfortunately.

    My employer currently works with a bunch of agencies and I've been involved with some of them. I can deliver the best product ever with the best process and lightning fast deployment - if the client doesn't get its shit together, you won't deliver on time/in budget.

    Anecdote I'm currently part of: an agency bought a new app, we're 98% done, we could go live on Tuesday. But there's one agency/department/guy (I seriously don't know) who has to confirm that the data of our staging system reached their system and was processed correctly. This agency however doesn't react. At all. And because it's something like 5mm outside of the jurisdiction of the agency that is our direct client, there's nothing we can do. So the system is just sitting there waiting.

    I could go on and on. Dataport is a good idea, but if all their clients are overworked, understaffed or straight up incompetent, there's not much they could do.

  • You never worked with bureaucracy, did you?

    From a technical standpoint, you are absolutely correct, but reality and bureaucracy don't always match.

    I've had instances, where we had glaring holes in our security, but were not allowed to fix them, because the datacenter (operated by a public agency) only does deployment in a fixed schedule.

    I've had officials of some sort who wrote in the contract, that each and every change has to be on the staging environment for at least one week for testing and signoff.

    It's absurd and stupid, but realistically, you often can't change it.

  • I can see the appeal of a fully self-driving Apple car. Something like a sleek little electric car, that takes the burden of actually driving away from you.

    And looking back, 10 years ago (when this apparently started) self-driving cars seemed to be just around the corner and a huge market. So I can kind of see the idea behind it.

  • No, it's not. And you know that.

    Seriously, ask yourself, how often did the need arise to look into old commits and if it did, wasn't the underlying issue caused by the processes around it? I've been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back. And I spend maybe 10min per year on that on average, if at all.

    I honestly don't see a use case that would justify the overhead. It's always just "but what if X, then you'd save hours!" But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.

  • Uuuh, am I no true Scotsman?

    Counter argument: why do you keep fucking up so bad you need these tools? Only users who are bad at programming need these. Makes about as much sense as your accusation.

    You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools. I literally never used pre-commit hooks or bisect in any semi-professional context. And I don't know a single project that uses them. And before you counter with another "well u stoopid then" comment: the projects I've been working on were with pretty reputable companies and handled literally billions of Euros every year. I can honestly say, that pretty much everyone living in Germany had his/her data pushed through code that I wrote.

  • As someone who works with government agencies as a software developer: they are absolutely awful.

    You'll get no specification at all, those you do get will change at least three times and every stupid little decision needs at least 20 people from different states, cities or agencies to agree.

    Yes, the bug is pretty bad, but I'm also very sure that what you're describing is not the whole story.

  • I'd still argue, that the overhead is not worth it most of the time.

    Linux is one of the largest single pieces of software in existence, of course it has different needs than the standard business crap the vast majority of us develop.

    To keep your analogy: not every room is an operating room, you might have some theoretical advantages from keeping your kitchen as clean as an OR, but it's probably not worth the hassle.

  • Question is: will humanity remember it even exists?

    Think about something like a roman empire speedrun. A series of smaller wars (not even nuclear), economic downfall, a few crop failures, refugee crises, political turmoil. Will anyone remember the vault after 50 years? Will anyone stumble upon it? Will raiders sell the surviving tech for food?

  • And I bet you it reduces reliability, because all those fancy electronics are absolutely crucial for it to work at all and brittle as a sand castle. So you'll end up with a white brick if the wifi module craps out or a capacitor gets too warm.

  • Years of experience don't really matter here, that's just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don't know that.

    Anyway, what you're saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won't help for either.

    Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn't matter, but you'll find people screaming at each other about it. See Emacs vs. Vi. Same crap.