fallous

I'm not sure we treat individuals as good/bad or successful/unsuccessful based on purely on outcomes. Criminal law, for example, depends upon intent in many cases.

The general biological view of viruses certainly demonstrate the absence of a categorical divide between "life" and "not life" as does the philosophy of the Turing Test. I'd argue that level of organization is less useful than the level of feedback loops in something, particularly if those loops are internal rather than external.

We daily operate with the idea of the Ship of Theseus as non-paradox in any number of ways. The City of Philadelphia retains its identity not because it is composed of the same people, geography, and structures established in its founding but rather because of the role it plays as an organizational concept, the Mississippi River retains its identity despite course changes over the centuries (let alone the constant replenishment of the individual water atoms within it).

I'd agree that we do not consistently apply bottom-up organization across the board, but that also necessarily means that we apply no consistent philosophy across the board. That leads to the question of how you're defining "Western modernist canon" given such an absence of a unified system.

Is this not similar to the philosophy of capitalism (at least as posited by Adam Smith) upon which much of modern Western thought rests? Arguably it's also very much reflected in John Locke's work as well as many philosophical foundations for democratic institutions.

By "things" it seems you ignore the key bit of the parent I was replying to... namely "technology," especially within the confines of the main article which focused on UX.

Specifically I used the word "changing" rather than "improving" because within the tech world (and to a degree the larger world of product) there is a long history of new and novel equating to better, hence the tired ad slogan "new and improved!" That emphasis on newness as desirable is a result of the many measurable improvements that did result from the rapid pace of innovation that occurred in the 19th and 20th century, improvements that were obviously perceptible in that they resulted in large leaps forward vs incrementally over long time periods.

Also, to claim that there has been improvements for large-scale populations via some new thing is nowhere close to being sufficient to explain how that new thing is an improvement for the individual customer.

I'm not sure I'd use the term "improving" but would instead say "changing." The perception of those changes has certainly been weighted towards "improvement" but some of that perception is a hangover from the popular mid-century views that most people held regarding science and technology (others held such views prior to that time but I wouldn't say they were the majority).

Those aren't anachronisms, they actually existed in the 80s and 90s on private online networks.

Real-time chat? Compuserve's CB Simulator. Craigslist? Compuserve certainly had classified ads as I'm sure did most of the others, including BIX. Usenet/Bullet Boards for interest groups? Compuserve Interest Groups, and every other service had that as well. Online gaming was also available on most of the networks, but special shout-out to Air Warrior that ran on GEnie.

You could also purchase airline reservations via SABRE which was supported by Compuserve and GEnie, get news, stock quotes, etc.

And yes, most of those services started out buying timeshare cycles from the likes of oil, insurance, and banking companies during evenings and weekends.

I went a bit further back when I saw "mechanical programming" and thought of this video. https://www.youtube.com/watch?v=gwf5mAlI7Ug

Mechanical analog computing FTW!

Why does it make human-like predictions as if it knows about reality? Because it's essentially pattern-matching the consensus of the literature it was trained on. Literature as a whole will tend to settle on a consensus sentiment, albeit one that is probably significantly behind the current consensus sentiment (it takes time to accumulate enough mass to move the weights). If your interactions with GPT-3 fall into the rather sizeable consensus that most people either subscribe to or are familiar with then it will certainly prove a decent mimic of understanding. If, however, you attempt to teach it a novel concept or if you dig into its interactions long enough to test for depth of understanding you run into the gaps and GPT-3 either begins to mimic that bullshit artist everyone knows that claims to know things but is only regurgitating platitudes and buzzwords or it begins to mimic behavior that would make you question whether it was sober and/or sane.

There's little doubt that GPT-3 could hold its own quite well in a bout of polite conversation and/or small talk that features in many social situations but that's more a commentary on the limited area of knowledge and behavior that etiquette expects for interactions in such settings.

It could also be trained on the canon of Shakespeare and behave as a prior work of Shakespeare, but if you left one play out of that canon and then attempted to have GPT-3 generate that missing work it wouldn't... at all. It doesn't approximate how Shakespeare thought, it approximates the literature he produced that you used for training.

None of this is to denigrate the achievement that GPT-3 represents, it is merely to point out that it is unfair to GPT-3 to attempt to hold it to the standards of AGI.

I'm not sure that you can assert that language is tightly coupled to reality, unless you're using the term "reality" to mean something akin to "as one perceives the world" (regardless of whether that perception is correct or not).

Most expressions of language that survived from a few thousand years ago are centered around myths, and while those myths may have contained certain moral or ethical lessons (that were and are subject to interpretation) they certainly weren't tightly coupled to reality in an objective sense.

Training on expressions of language (I separate the concept of language itself from its expression in the form of writing, speaking, etc) certainly has use cases but can GPT-3 recognize a previously unknown analogy and correlate it with the proper piece of applicable "knowledge" it has? If not then it really has no understanding.

You invite the problem of eventual vs strong consistency, split brain issues, etc. There's a reason that the two hard problems in computing are naming things, cache coherency, and off by 1 errors.

My interpretation of current ML solutions is that it's mostly brute force statistical models hoping to hit a satisfactory p-value (some implementations being more elegant in the brute force than others). The calculating power defines the limits of the finite domain you can apply the solution towards.

A simplified analogy that I believe is applicable is the application of flocking behavior in birds. Current ML implementations would demand a large dataset of groups of birds in flight, both flocking and non-flocking, and curating the correct p-value of brute-forced models that allege to predict whether behavior is flocking or not (and in the case of an individual bird whether it is appropriate flocking behavior given the individual behaviors of birds in the dataset and their circumstances). But flocking behavior is easily modeled right now, and has been for decades, using simple rules for individuals and depending upon emergent phenomena within a group.

I'm concerned that most of the ML efforts now are merely attaining the low-hanging fruits of brute force but will run into a wall that halts progress at the level of relatively "easy" things solved by worms and other comparable biological solutions since so many domains have a level of complexity that would exceed any realistically imaginable level of simple mathematical computing power.

If this is a result of poor execution then I'd stay and change it. If instead it's a result of a cultural or company vision that does not embrace focusing on the customer, their problem (not just your opinion of it), and working constantly towards solving the problem then you should bail.

I spent a lot of years in several companies thinking I could correct a bad vision or culture, and unless you're the CEO you can't. Poor execution of a good vision/culture is always correctable, although you should consider what is the root cause of that poor execution... often it's personnel.

Note that my post isn't limited to credit card inputs, nor do I say that the request for clarity is mandatory in all fields.

What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.

Too many times I've had to deal with data that someone optimistically sanitized or filtered client-side and then stored, only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules.

Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that the meaning or intent isn't the same but even that isn't entirely reliable.

You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.

The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.

You're limiting it to "I want to do something, I need reminders" but it also applies when you're trying to convince people to do something as well, such as sales or particular behavior in apps. I can't begin to count the number of times that someone ignores the level of motivation and requisite "ability," in most cases mental/time costs, in something like account creation on a site. A barrage of fields irrelevant to the actual necessities of account creation get shoved in because "we want marketing data" or some other idiocy because either they discount the barriers they're erecting or wildly overestimating the motivation.

That this kind of basic understanding of human behavior and interaction is no longer considered common sense, at least within the business domains he's targeting, is pretty sad. How it lost its place in the basic toolkit of dealing with people isn't clear to me, but in mentoring startups over the last several years I've certainly noticed its absence and also that some are actually resistant to such ideas (although I suspect that's due more to vanity and wish-based thinking than any intellectual reasoning).

The above is in no way intended to denigrate or disagree with Fogg's work or its usefulness. In fact I applaud him for providing such work and hope that it is successful enough that it restores such knowledge of human behavior back in the expected canon of common sense.

With regards to Eternal September, you're exactly right. Prior to that AOL invasion you had relatively small bursts of new people joining with no predetermined cultural expectations who had to assimilate into an existing culture. When AOL hit usenet you had a massive number of people with their own established cultural expectations due to the walled and managed AOL garden colliding with the existing Internet culture, and the Internet culture was overwhelmed.

Prior to Eternal September the primary conception of the Internet by those on it was that it was a tool. After Eternal September the primary conception was that it was a channel for consumption and entertainment.

It was less the barrier to entry than a combination of limitations in the rate of new members in a subgroup (you may get burst of new members in September but the total number added over the course of a year was manageable) and a process of cultural (with regards to expectations of behavior and discourse) assimilation, made easier by the fact that there was no prior cultural expectations on the part of new members.

Remember that usenet newsgroups numbers in the tens of thousands, usually focused on a very specific interest. New members joined either to gain knowledge, be among those who share an interest, or occasionally to troll. Trolls were easy enough to add to .ignore files, and the others had a desire for the benefits the newsgroup offered and thus were inclined to respect whatever rules were in place in order to receive that benefit.

The general model of a usenet group is echoed on the web with message boards, absent the unified means of distribution and discovery.

If I rephrase the title to "Why are the results of software engineering so bad?" it makes it easier for me to point out the most obvious problems, in my experience at least.

The alternative to nearly all software solutions is "bunch of people do that thing" or "hire costly expert." Software is usually a combination of transitory, relatively quick to implement, mostly opaque, and very inexpensive in up-front costs in comparison to the alternative, which both reduces the perceived risks as well as makes it unusually attractive as a means to achieve some goal. That combination also lowers the bar for what qualifies as "a goal," providing a much larger universe of possible actions available for those who are establishing the goals.

With the lowered bar of what constitutes a goal, given that the overall costs are perceived to be so very low, the decision maker feels unburdened enough to choose goals without vetting the decision and its consequences against the standards that would be applied to "hire a bunch of people to do that." You've taken what used to be a decision that carried with it all the forethought and examination that one would usually apply to purchasing an automobile or home and replaced it with a decision that has no more consequential cost than to decide whether one wants fries or carrot sticks with a sandwich.

As with the choice of fries, it's not the single instance of such a choice that lays you out on a cardiac surgeon's table but instead the repeated accumulation of what seemed to be inconsequential decisions to get fries. If you asked someone if eating fries with every meal could set someone up for a heart attack they'd most likely say "of course, that's obvious." But our patient did not encounter the situation in which they had to make the decision as to what side they will have with every forthcoming meal, and all the forethought answering such a question would entail. They only made one little decision whose importance was as fleeting as a single meal. Until it wasn't.

This effect on decision-making, with regards to software, almost always spreads to the entire organization (and often beyond, to infect customers and the general public as well). The CEO, the VPs, the Directors, the Managers, not to mention the programmers themselves, all make decisions and set goals that meet the lowered standard (or at least a standard lower than what should or used to be the standard).

When you lower the standards for decisions and goals, you get results commensurate with those standards.

Definitely gives me some nostalgia for the days when I ran AfterStep for my desktop machine while at Netscape.

It's event driven in the manner of stimulus/response. A computer may process a series of instructions, but absent a loop it then finishes and does nothing without being told to process another series of instructions. Even within a listening loop it is essentially looking for "something to happen" and if nothing happens it NOPs, or does some basic house cleaning regarding the loop which is essentially the same. It is only when a stimulus occurs that the computer responds with a not-loop series of instructions.

I think the level of abstraction applied to "event" is key in determining whether the architecture is successful (or even appropriate).

If you attempt to implement at a granular level (got click on button!) then it turns into a giant mess because you're essentially reinventing the logical flow and event loop of programming via a message bus, which is a pretty terrible idea. If instead you operate at the business logic level of abstraction it can result in a much more coherent and easily-extended system, especially since that level also sees the most change from executives or operations. At that level it's also easier to integrate with third-party services.

It is certainly not a cure for all that ails you, despite the claims of some snake-oil salesmen to the contrary.

Yeah, a senior engineer role is most assuredly is NOT "all-nighters and unreadable code." But neither is it necessarily the mentor style of role that the author advocated, which is more appropriate as the job duties of a team lead.

A senior engineer most assuredly should be the one that thinks about the problem at hand in a deep way, preferably understanding the business needs and such, and provides solutions that not only solve the immediate need but also has the flexibility to anticipate future demands. It would also be nice if they proactively tried to improve less-senior engineers via mentoring and contributed leadership to team building but those are, in my opinion, bonus attributes rather than fundamental necessities.

Will I, especially since I'm actually the engineer with 30 years of experience?

Jumping from new hotness to new hotness isn't a means to achieving real experience, it's often a quick way to 10 of the same one year since you never gain depth of understanding by flitting from one thing to the next.

Nowhere did I claim that you must have new projects/tools/stacks/toys/whatever to gain real experience.

I'd agree with your criticism of tool/new hotness as a bad metric for measuring leveling up. It's too easy to get the dopamine hit from novelty or being busy rather than putting in the real work that provides value.

We learn to solve the same problems better because we're exposed to the limitations of our initial naive understanding of those problems and the methods we choose, which may be sufficient in the first year, but over time that understanding becomes deeper and the methods become more elegant, reliable, and maintainable.

The wisdom and methodology improvements are necessary components of achieving 10 years of experience, but the 10 years of the same year approach literally is staying at the same level of understanding no matter the number of projects.

Indeed, and given that this was an intentional design tells you who they truly believe is their primary "customer."

I think the article has some good points regarding the expectations of a senior engineer but also seems to conflate the duties of a team lead with senior engineer, but in my experience those are two different roles (and usually titles).

Indeed. As I've had to remind many people over the years, "doing the same basic work you learned in your first year repeatedly for 10 years is not 10 years of experience... it's 10 of the same one year."

I'm probably picking nits, but is something intentionally designed and implemented a "flaw" if it works as intended?

It's not that the products are poor but that Intel has a long and proud tradition of killing any product that is not directly related to x86.

Intel GPU started with i740 (a stand-alone AGP card), which is the last stand-alone GPU they made... and that was 1998 or so.

Their networking chipsets were a result of Intel's own x86 motherboard business, especially in the server arena. Intel also bought out companies in the late 90s/early 2000s to build their stand-alone network appliance business (routers, firewalls, SSL accelerators, etc) only to prompt kill that off when x86 started stumbling thanks to the P4 and AMD's competition.

Just a quick reminder when considering Intel products... if it ain't Mama x86, it won't be around very long.