Earlier quoted context omitted.
The weakest point in any computer system is the bag of meat operating the thing.
Can we stop calling humans "bags of meat"?
I've tried, but have been unable to do so. I think it's a limitation of my meatness.
15 years later, Microsoft morged my diagram
211–220 of 427 posts
Re: 15 years later, Microsoft morged my diagram
#212When I read the title, I thought "morg" was one of those goofy tech words that I had missed but whose meaning was still pretty clear in context (like a portmanteau of "Microsoft" and "borged," the latter of which I've never heard as a verb but still works). I guess it's a goofy tech word now.
At least it wasn't mogged, or morbed...
Re: 15 years later, Microsoft morged my diagram
#213Earlier quoted context omitted.
[flagged]
I'll try to respond to your comment in good faith, even though I find it to have a rather aggressive, ad-homimen tone: > If this pattern is so pervasive, and so many people care enough to attempt to explain it to you, yet you remain unconvinced, I’m not sure how you reach the conclusion that you are right, and correct, and that it’s such a shame that the world does not conform to how you believe that things should be…
Not the original commenter but this felt worth adding to: you mention 'cargo culting', yet there are already two comments raising the core benefit, which is keeping main 'stable and working' while develop stays 'rough and ready'.
A less rigid development branch allows feature branches to be smaller and easier to merge, and keeps developers working against more recent code.
A more locked-down, PR-only main branch enables proper testing before merging, and ensures that the feature and release branches stemming from it start in a cleaner state.
I've worked with both approaches and I'm firmly in the camp of keeping main stable, with a looser shared branch for the team to iterate on.
Re: 15 years later, Microsoft morged my diagram
#214Microsoft employee (VP of something or other, for whatever Microsoft uses "VP" to mean) doing damage control on Bluesky: https://bsky.app/profile/scott.hanselman.com/post/3mez4yxty2... > looks like a vendor, and we have a group now doing a post-mortem trying to figure out how it happened. It'll be removed ASAFP > Understood. Not trying to sweep under rugs, but I also want to point out that everything is moving very f…
LOL, calling Scott Hanselman a 'VP of something' is funny. Been listening to his stuff for years, even when I despised MS. Always seems genuinely nice. Probably one of the main reasons I these days have a more positive image of Microsoft.
Re: 15 years later, Microsoft morged my diagram
#215LinkedIn is also a great example of this stuff at the moment. Every day I see posts where someone clearly took a slide or a diagram from somewhere, then had ChatGPT "make it better" and write text for them to post along with it. Words get mangled, charts no longer make sense, but these people clearly aren't reading anything they're posting. It's not like LinkedIn was great before, but the business-influencer incentiv…
Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin.
https://www.marginalia.nu/junk/linked/games.jpeg
https://www.marginalia.nu/junk/linked/json.png
https://www.marginalia.nu/junk/linked/syntax.png
(and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a couple of days)
Re: 15 years later, Microsoft morged my diagram
#216Is this not a good example of how generative AI does copyright laundering? Suppose the image was AI generated and it did a bad copy of the source image that was in the training data, which seems likely with such a widely disseminated image. When using generative AI to produce anything else, how do you know it's not just doing a bad quality copy-paste of someone else's work? Are you going to scour the internet for the…
> What if code generation is copy-pasting GPL-licensed code in to your proprietary codebase?
This is obviously a big, unanswered, issue. It's pretty clear to me that we are collectively incentivised to pollute the well, and that it happens for long-enough for everything to become "compromised". That's essentially abandoning opensource and IP licensing at large, taking us to an unchartered era where intellectual works become the protected property of nobody.
I see chatbots having less an impact on our societies than the above, and interestingly it has little to do with technology.
Re: 15 years later, Microsoft morged my diagram
#217LinkedIn is also a great example of this stuff at the moment. Every day I see posts where someone clearly took a slide or a diagram from somewhere, then had ChatGPT "make it better" and write text for them to post along with it. Words get mangled, charts no longer make sense, but these people clearly aren't reading anything they're posting. It's not like LinkedIn was great before, but the business-influencer incentiv…
Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…
Those are so funny that I was forgetting to breathe as I was laughing so hard, man that's excellent haha. Thanks for sharing them, even if we are cooked as a society...
Re: 15 years later, Microsoft morged my diagram
#218Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…
You’re right. I think what you’re describing is “trunk based development” and it’s much better. Maybe I’m overly cynical but I think git-flow was popular largely because of the catchy name and catchy diagram. When you point out that it has some redundant or counter-productive parts, people push back: “it’s a successful model! It’s standard! What makes you think you can do better?” There’s a nice write-up of the trunk…
Correct. If you can always either fix it forwards or roll back, which you should be able to unless you're building software that needs to go out in releases with versions tracked separately that need to keep getting fixes, trunk-based development simplifies everyone's lives greatly.
I've never seen an organisation that insists on release branches and complicated git merge flows to release their web-based software gain any actual benefit from it that isn't dwarfed by the amount of tooling you need to put around it to make it workable to the dev team, and even then, people will routinely screw it up and need to reach out to the 5% of the team that actually understands the system so they can go back to doing work.
Re: 15 years later, Microsoft morged my diagram
#219Earlier quoted context omitted.
I'll try to respond to your comment in good faith, even though I find it to have a rather aggressive, ad-homimen tone: > If this pattern is so pervasive, and so many people care enough to attempt to explain it to you, yet you remain unconvinced, I’m not sure how you reach the conclusion that you are right, and correct, and that it’s such a shame that the world does not conform to how you believe that things should be…
Not the original commenter but this felt worth adding to: you mention 'cargo culting', yet there are already two comments raising the core benefit, which is keeping main 'stable and working' while develop stays 'rough and ready'. A less rigid development branch allows feature branches to be smaller and easier to merge, and keeps developers working against more recent code. A more locked-down, PR-only main branch enab…
Right, I get what you're saying, but in git-flow, the master branch isn't just "stable", it's "literally the last release we made". Which you can also get from the tags (i.e. checking out master or checking out the highest numbered release version tag will give you exactly the same commit). So I'm not sure I see the functional difference. Either you have "develop is messy, master is stable", or you have "master is messy, latest release tag is stable". I mean, sure, there's a bit of mental work involved in "which of these tags has the highest number". But surely that's less than the work involved in maintaining two long-running branches instead of one? I'm not really arguing for one way of working (or level of stability at integration) or another, I'm arguing that the one that git-flow supports can be implemented in a functionally equivalent, but simpler way, with naming that is more consistent with usage elsewhere.
Re: 15 years later, Microsoft morged my diagram
#220Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…
It can be beneficial if there is no mechanism that ensures that develop is always in a working state, but there is one that ensures that master is. The immediate benefit is that a new feature branch can always be started off master from a known-good state. Of course, there are ways to enforce a known-good state on master without a dedicated develop branch, but it can be easier when having the two branches. (I just di…
Prod deployments usually have a tag associated