I've been in Europe for almost 2 months now and started seeing the GDPR banners a lot more often. I've yet to feel like I'm missing anything by either clicking reject all, or by avoiding the site if I can't reject all non-required cookies in a few clicks.
> Once you have worked a while in business or marketing, you will see that it's not that easy unfortunately
Nobody is forcing anybody to do this, this is a personal and business decision to make more money at the expense of users' well-being. When you're surrounded by lots of people that think a certain way, you start to see it as acceptable and even good.
Though I know lots of people that disagree, I personally don't think it's justifiable. If someone finds it justifiable, they should take responsibility for it.
My experience is that the source of all this is the fear of having a substantial disadvantage against the competition and having to defend your decision of sustaining such a perceived disadvantage against the CEO/board. Understandable from my point of view, even though I don't like the outcome. This then usually trickles down the hierarchy in companies and, yes, someone will somehow implement it to earn their living. I'd define the implication of losing your livelihood as a consequence of not doing what you are told as force, but that is open to opinion I guess.
An anecdote that might be worth mentioning in this context:
I was once told by some CEO that they didn't hire a really qualified person, because that person had enough money to not be dependent on the job. This is, in my experience, an appropriate reflection of the role of money in controlling people's decisions. It's essential that you are dependent so that you can be forced to comply or risk losing your livelihood.
My team's systems play a critical role for several $100M of sales per day, such that if our systems go down for long enough, these sales will be lost. Long enough means at least several hours and in this time frame we can get things back to a good state, often without much external impact.
We too have manual processes in place, but for any manual process we document the rollback steps (before starting) and monitor the deployment. We also separate deployment of code with deployment of features (which is done gradually behind feature flags). We insist that any new features (or modification of code) requires a new feature flag; while this is painful and slow, it has helped us avoid risky situations and panic and alleviated our ops and on-call burden considerably.
For something to go horribly wrong, it would have to fail many "filters" of defects: 1. code review--accidentally introducing a behavioral change without a feature flag (this can happen, e.g. updating dependencies), 2. manual and devo testing (which is hit or miss), 3. something in our deployment fails (luckily this is mostly automated, though as with all distributed systems there are edge cases), 4. Rollback fails or is done incorrectly 5. Missing monitoring to alert us that issue still hasn't been fixed. 5. Fail to escalate the issue in time to higher-levels. 6. Enough time passes that we miss out on ability to meet our SLA, etc.
For any riskier manual changes we can also require two people to make the change (one points out what's being changed over a video call, the other verifies).
If you're dealing with a system where your SLA is in minutes, and changes are irreversible, you need to know how to practically monitor and rollback within minutes, and if you're doing something new and manually, you need to quadruple check everything and have someone else watching you make the change, or its only a matter of time before enough things go wrong in a row and you can't fix it. It doesn't matter how good or smart you are, mistakes will always happen when people have to manually make or initiate a change, and that chance of making mistakes needs to be built into your change management process.
>My team's systems play a critical role for several $100M of sales per day, such that if our systems go down for long enough, these sales will be lost.
Would they? Or would they just happen later? In a lot of cases in regular commerce, or even B2B, the same sales can often be attempted again by the client for a little later, it's not "now or never". As a user I have retried things I wanted to buy when a vendor was down (usually because of a new announcement and big demand breaking their servers) or when my bank had some maintainance issue, and so on.
It's both (though I would lean towards lost for a majority of them). It's also true that the longer the outage, the greater the impact, and you have to take into account knock-on effects such as loss of customer trust. Since these are elastic customer-goods, and ours isn't the only marketplace, customers have choice. Customers will typically compare price, then speed.
It's also probably true that a one-day outage would have a negative net present value (taking into account all future sales) far exceeding the daily loss in sales, due to loss of customer goodwill.
It would be a serious issue for in person transactions like shops, supermarkets, gas stations, etc
Imagine Walmart or Costco or Chevron centralised payment services went down for 30+ mins. You would get a lot of lost sales from those who don’t carry enough cash to cover it otherwise. Maybe a retailer might have a zapzap machine but lots of cards aren’t imprinted these days so that’s a non starter too.
Not just lost sales. I've seen a Walmart lose all ability to do credit card sales and after about 5 minutes maybe 10% of people waiting just started leaving with their groceries in their cart and a middle finger raised to the security telling them to stop.
It depends on the business. It's not uncommon for clients to execute against different institutions' systems, and they can/would re-route flow to someone else if you're down.
Think less "buying a car" and more "buying a pint of milk". If you're buying a car and the store is closed, you might come back the next day. If you're buying milk you will just go to the store down the street.
I imagine same with time based or opportunistic businesses. If the shopping channel (assuming it runs around the clock) couldn't process orders, they'd have to decide if they want to forgo selling other products to rerun the missed ones.
For certain types of entertainment like movies or sports, the sale may no longer be relevant.
You're talking about the dog not minding being in the crate since you've taught them its nice and cozy. In that case why does it have to be a crate, why not say, an indoor doghouse?
As far as that goes, there's nothing wrong with that and that's not the part that people actually have problems with (but it's a nice strawman to argue against).
The part that is cruel and abusive is locking them up when nobody is at home so they can't damage your possessions. If there is some emergency like a fire, intruder, something falling down, etc, they can't do anything about it.
A salaried role is paid the same regardless of how long one works. A rationally run business should care about what's produced, not the amount of labor-hours it takes to produce it. Developer productivity varies wildly, so in a fair labor market, time worked and compensation should vary with developer productivity (sometimes compensation is correlated with time worked, but generally at diminishing marginal returns).
Of course there is a dynamic between the business and the employee when it comes to their expectations of each other. All else being equal, a business would like to get more output per dollar spent, and an employee would like to get paid more in total and work fewer hours. Nowhere in the goals of this dynamic does hours worked come into the picture. What does happen is that businesses believe they would get more output per dollar spent if they can get a salaried employee to work more hours, so they pressure employees into doing so. People generally like to be in charge of others, so un-enlightened managers force employees to be at the office because they like seeing them there.
Enlightened managers care first about cultivating great relationships, secondly about the total output of an employee, and therefore not at all about hours worked. Marginal productivity per hours worked eventually goes negative as hours worked increase, and in my opinion the point at which it becomes negative is a lot lower than most people believe (probably ~20-30 hrs/week over the long term).
Besides, highly productive developers are in very high demand. You're just shooting yourself in the foot if you don't give them a fair deal, because they'll go somewhere else, unless they're on a work visa in which case they'll remember if you don't treat them well.
Please do note that this argument applies mostly to salaried employees in knowledge-work.
> Besides, highly productive developers are in very high demand. You're just shooting yourself in the foot if you don't give them a fair deal, because they'll go somewhere else
Ok, but "we expect you to work full time when we hire you for a full time job" is a fair deal. It is not "unfair" to hire people full time rather than part time.
Socratic dialogue, where everyone is intent on building up a shared truth. Socrates talks about these two different ways of engaging in dialogue in Plato's works.
Ironically, Plato's Socrates rarely ever actually arrives at what he considers truth, most dialogues just end at an impasse. This is arguably why they're still so readable. They're more about teaching you how to think and question what you know than proselytizing some particular doctrine.
For the developer working on the change, or for the reviewer + everyone that comes after them looking at your commit (which can include your future self)?
We tend to discount everyone else's time but our own.
Might also be worth thinking about long term asymptotic effort vs marginal effort at a particular point in time--typically, the more often you do something (decomposing a commit into multiple independent parts, in this instance), the easier and less time-consuming it becomes.
> For the developer working on the change, or for the reviewer + everyone that comes after them looking at your commit (which can include your future self)?
Both. I don't really follow what you're getting at, I think we're in agreement? confused
Yes we are; I thought you were advocating for larger commits since they're too difficult to break apart into logically independent pieces, but it seems I just misunderstood what you wrote the first time I read it.
