I was thinking about your last point about why we honor veterans. In the US it’s not really the case that without them we’d be captured or killed. All our conflicts in the last several generations have been us invading or fighting in foreign lands against forces that were not attacking us. All our modern military personnel are willfully employed and well compensated and given lifetime benefits for that.
The US engages in preventive wars, generally. For example, the wars in Korea and Vietnam were ultimately fought to prevent the USSR from becoming more dominant than the USA and ultimately to prevent it from becoming so strong that in an eventual direct confrontation they would be able to cause a lot of destruction in the US. Iran is similar: they seem to want to prevent Iran from getting nukes which could then be used to destroy Israel, which the US considers its protectorate.
But this is a super slippery slope. It’s essentially the same excuse Russia used in Georgia and now Ukraine: they are near neighbors geographically and culturally that must be stopped from joining the enemy alliance in order to prevent the enemy from attacking Russia in turn, which would be much easier should those countries be part of NATO. But where do you stop? Should Cuba be allowed to join Russia military alliance? Should Mexico be allowed to join BRICS? According to US foreign policy, the answer is always no, because of “national security”.
Well, it's much better to be on the invading side though. I've been to a coutry that was on invaded side (Ukraine), and, trust me, you'd always want to be on the invading side. And sometimes all it takes is just one invasion.
But when I said "we honor our veterans" I did not speak of USA, I spoke of any country veterans.
That’s a tough policy to only update prod biweekly! It would be super frustrating if you had a bug crawl out and not be allowed to patch it for 2 weeks. This post really expresses the frustration of working in a bureaucratic environment where developers don’t have full access to change production.
That being said CI/CD is a luxury for coders at lean startups, but there’s still a lot of jobs where you have to work with some DevOps Team to deploy your code to prod. Organizations past a certain size have more hoops to jump through, for reasons.
Of course as a dev it’s ideal to have full access!
You know that making CI/CD doesn’t mean you have to pay boatloads of money to a vendor.
Putting up bash script that pulls repo and deploys it is already CI/CD.
Setting up basic Jenkins installation for a technical person should not be taking longer than 2 hours. For person who already is familiar with Jenkins that would be 30mins.
Once you have paying customers I would say there should be max and minimum 2 devs that can fiddle with prod. Others should pass changes via senior people.
A truly lean team (say, <=5 people and limited project scope) should be able to live off their code forge's free CI/CD minutes, or whatever is included in the basic tier they're running. Just run the suite on a schedule against trunk instead of on every PR.
If not, then that's a good signal they should invest more into their CI/CD setup, and like you said it's not necessarily a huge investment, but it can be a barrier depending on skills.
That's a bit harsh, depending on how a person developed or where they worked they may not have had exposure to other facets beyond basic development. Beyond that, it might as well be magic. They'll have to figure out how to provision a VM, ssh into it & lock all the proverbial doors first. Without going into managing it with IaC tools like Terraform, Ansible, Packer, etc.
> That's a bit harsh, depending on how a person developed or where they worked they may not have had exposure to other facets beyond basic development. Beyond that, it might as well be magic.
...so? You sit your ass down and learn. It might take a bit longer if you never touched shell but it's far easier than anything actual programming deals with, especially currently with set of ready or near ready recipes for every environment.
Yes yes. You’re right. I am saying at some places devs don’t own production- there’s an IT/Ops/non-dev person in the loop. Especially common if you’re a consultant in non-tech industries
> That being said CI/CD is a luxury for coders at lean startups, but there’s still a lot of jobs where you have to work with some DevOps Team to deploy your code to prod. Organizations past a certain size have more hoops to jump through, for reasons.
It takes next to no time to setup some basic one and not all that much time to setup decent one, and returns on investments are huge. There is no startup small enough where that isn't a good return.
I completely agree. I really worded this poorly. I was trying to say it’s great to have CI/CD to production. There are places I’ve worked who don’t have it due to their bureaucracy/regulation/security. Not because we don’t know how it set it up
My org went all in on Teams over 6 years ago. Removed all PBX systems and desk phones. Pulled out Cisco phones from 20 offices. Ported all numbers to MS. By all accounts it was unremarkable to the end users, and when WFH mandates started it was seamless. Definitely a lot less IT support for configuring and troubleshooting a phone system too. There is far less downtime because Teams will ring through to your cell phone if the office internet is down or your laptop is off. That was not possible when the Cisco routers and CallManager in the office were running the DIDs and local extensions
It was, in fact, even with existing Microsoft products (Lync/Skype for Business). It was even possible if you had paid for those features for UCM from Cisco. Teams was simply the cheaper option (although they tried to keep charging my org Lync prices, and we had to threaten to uproot MS products and go to Cisco before they gave us the new pricing).
* using more than one org (needs app restart!) although
screen sharing between 'classic' and 'web' editions works only if sender's and receiver's graphic cards share a hw-accelerated video format blessed by teams. Not, it's not easy to check what edition you are running and you can't change it without poking js variables by hand
* inconsistent read statuses between devices
* 'incoming call not shown at all' bug (but you get a missed call notification)
* can't join two video calls even in two separate windows
* random audio device switching on every morning (even if you don't close the app and computer for the night)
It's fine. Messages sometimes fail to appear unless you navigate away and back and sometimes they fail to appear at all until 30 minutes later but it's fine. This regularly slows down communication and costs company time, but it's fine. It's 2026, classrooms full of children can vibe code a chat app but a $3T company struggles with basic chat functionality. It's fine.
Whatever. I've been using it since day one and its still a broken turd. People are just used to shit software, restarting, rebooting, missing calls, missing messages. Sure you can make it work, but you can't deny its a real piece of shit.
Page crashed after downloading and extracting. On safari iPhone that’s a few years old, latest iOS. I was really interested in trying / why I waited
Ed: tried again it crashed at 66% loading (after 100% loading)
I mean, naturally there's Doom on a vape [0], so as far as I'm concerned, that box is already ticked. Someone should give a good name to the law that every hardware device with a screen has a Doom port.
reply