pavas's comments

Yep that's a cogent, serious stance, and it sounds a lot like illusionism (famously argued by Daniel Dennett) or functionalism if you ever wanted to check out more about it.

It’s a serious stance, but the really interesting thing to me here is that its not a settled fact. What’s quite surprising and unique about this field is that unlike physics or chemistry where we generally agree on the basics, in consciousness studies you have some quite brilliant minds totally deadlocked on the fundamentals. There is absolutely no consensus on whether the problem is 'solved' or 'impossible,' and its definitely not a matter of people not taking this seriously enough or making some rash judgments or simple errors.

I find this fascinating because this type of situation is pretty rare or unique in modern science. Maybe the fun part is that I can take one stance and you another and here there's no "right answer" that some expert knows and one of us is "clearly" wrong. Nice chatting with you :)

Yeah that pretty much seems to be it.

> then isn't the experience just of "a surface attribute, of given spatial extent".

I don't know why this seems to be so hard for me to think about and even put into words, but isn't "the experience of the surface attribute of a given spatial extent" something other than the experience of the surface attribute of a given spatial extent itself?

I mean that the words we use to describe something aren't the something itself. Conceivably, you can experience something without ever having words, and having words about a phenomenal visual experience doesn't seem to change the experience much or at all (at least for me).

Maybe another way of phrasing this would be something like: can we talk about red blotches using red blotches themselves, in the same way that we can talk about words using words themselves? And then, supposing that we could talk about red blotches using red blotches (maybe the blotches are in the form of words or structured like knowledge, I dunno), can we talk about red blotches without ever having experienced red blotches? I learned this idea from Mary's Room thought experiment, but I still don't know what to think about it.

I'm actually curious here, because maybe our experiences are different. When you look at something red, before any associations or thoughts kick in, before you start thinking "this reminds me of fire" or analyzing it, is there something it's like for that redness to be there? Some quality to it that exists independent of what you can say about it?

For me, I can turn off all the thinking and associations and just... look. And there's something there that the looking is of or like, if that makes sense. It's hard to put into words because it's prior to words, and can possibly be independent of them.

But maybe that's not something universal? I know some people don't have visual imagery or an inner voice, so maybe phenomenal experience varies more than we assume. Does that distinction between the experience itself and your ability to think/talk about it track for you at all?

> It seems entirely possible that the "philosophical zombie" is an impossible/illogical construct, and that in fact anything with all the structure necessary for consciousness will of necessity be conscious.

Yes, and that's pretty much exactly the point: we don't know of any way of determining whether someone is a p-zombie or a being with conscious phenomenal experience. We can certainly have an opinion or belief or assume that sufficient structure means consciousness, which is a perfectly reasonable stance to take and one that many would take, but we have to be careful to understand that's not a scientific stance since it isn't testable or falsifiable, which is why it's been called the "hard problem" of consciousness. It's an unfounded belief we choose out of reasons like psychological comfort.

With regards to your latter point, I think you are making some sophisticated distinctions regarding the "map and territory" relation, and it seems you've hit upon the crux of the matter: how can we report "what its like" for us to experience something the other person hasn't experienced, if its not deconstructible to phenomenal states they've already experienced (and therefore constructible for them based off of our report)? The landmark paper here is "What Is It Like to Be a Bat?" by Josh Nagel, and if you're ever curious it's a pretty short read.

With regards to "blindsight" since I'm not familiar with it and curious, how do we distinguish between loss of visual consciousness and loss of information transfer between conscious regions, or loss of memory about conscious experience?

> As noted, consciousness seems to just be the ability to self-observe, which is useful as another predictive input.

As far as I know, consciousness is referring to something other than self-referential systems, especially with regards to the hard problem of consciousness.

The [philosophical zombie](https://en.wikipedia.org/wiki/Philosophical_zombie) thought experiment is well-known for imagining something with all the structural characteristics that you mention but without conscious experience as in "what-its-like" to be someone.

It's the sound your passengers make, which is a joke.

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.

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.

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.

Agreed. Cause I trained it not to.

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.

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.

What are your thoughts on marriage between people of who one is infertile?

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.

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.

Luckily my company doesn't have much prescription about commit process, so its up to each team to determine what works for them and we've been pushing for small atomic commits (probably what you'd term micro-commits).

The idea is that each commit should be small enough to fit in one "page" of PR review, with source lines and test line diffs <150 each, and everything should be one integrated and independent change with unit tests all passing and deployable to prod, etc. Honestly, I can't see a downside to this, other than maybe taking a while to internalize this process and to properly decompose commits.

Have you considered advocating for a change of company standards? Sometimes thats a sisyphean task, but if the only argument against it is "that's how it's always been done" it might be a worthwhile endeavor.

I consider myself a git noob, but I do find myself using rebase several times weekly. It seems to get easier the more I use it, along with all other git tactics.

Why bundle all changes into a single commit? How can the commit message be meaningful at that point? Why not just submit multiple atomic commits?

Our team has been pushing for and implementing small, atomic commits on mainline. Honestly, I'll keep fighting for it and never go back. PRs are easy to review, commits are easy to reason about, what's not to love?

Why squash commits to begin with? Unless you're getting too many commits per package per time period, then maybe that's an indication that you should modularize your codebase.