A lot of the above discussion came from another discussion I participated in about four years ago. In that discussion, fdrake responded with a post I thought was interesting. Different from my way of looking at things, but with characteristics in common. I hope you don't mind me reposting this here, fdrake:

Can describe the steps in doing a standard statistical analysis (hypothesis test on model parameters) of some data in a similar way:

(1) Describe data collection method and problem data is being used to study.
(2) Identify derivable statistics for problem and their distributions.
(3) Aggregate derived statistics into a statistical model appropriate for research question.
(4) Model fitting - instabilities? weirdness? go to (1) .
(5) Model checking - violated assumptions? go to (1)
(6) Fit checking - what purpose is the model to be given?
(7) Impact assessment - what does the model mean for the problem at hand?
(8) Interpretive conclusions? Ambiguities? Quantificational results? Improvements for further study?
(9) Return to (2) until all avoidable violations and weirdness have been removed or accounted for and fit is adequate. — fdrake

(1) Describe data collection method and problem data is being used to study.
(2) Identify derivable statistics for problem and their distributions.
(3) Aggregate derived statistics into a statistical model appropriate for research question.
(4) Model fitting - instabilities? weirdness? go to (1) .
(5) Model checking - violated assumptions? go to (1)
(6) Fit checking - what purpose is the model to be given?
(7) Impact assessment - what does the model mean for the problem at hand?
(8) Interpretive conclusions? Ambiguities? Quantificational results? Improvements for further study?
(9) Return to (2) until all avoidable violations and weirdness have been removed or accounted for and fit is adequate. — fdrake

In other words: insofar as possible, isolate the piece of world you wanna investigate, hold it against or in bright light, turn it upside-down, inside-out, vice-versa, squeeze it, pull it, throw it, heaten it up or cool it down, while you mentally paint a picture of a state of affairs. Try to write up your mental model, by every means possible. Repeat the process until the desired level of understanding suffices for the use of the piece of world.

One cannot justify the usefulness of a model of data without first making ontological commitments. The concept of usefulness only comes after committing to some notion of truth, that cannot be pragmatically determined on pain of circularity.

(Subject to correction on matters of engineering, me not being an engineer.) The products of engineering are discrete and measurable. The product being established as a goal, the efforts of engineers being to achieve the goal within given parameters, according to given standards. The methodologies for which filling bookshelves. And the Site Conceptual Model (SCM) seems to me to make explicit and substantial what should be steps taken. Or about as @Raymond, above said.

And there seem lots of ways that philosophy is not transcribable as any kind of engineering. But that imo in no way disqualifies an engineering approach to philosophic matters. Expectations of utility have to be modified, to be sure. But salient is the command to think, think through, test and analyze, evaluate (& etc.), rinse and repeat until done.

As a pragmatist, I assert that no philosophical position is meaningful unless it has concrete implications for phenomena present in the everyday world, life, and experience of normal human beings. As a pragmatic epistemologist I assert that the primary value of truth and knowledge is for use in decision making to help identify, plan, and implement needed human action. Philosophy that does not meet this standard is not useful. — T Clark

What this needs, imo, is the addition of the word "possible." Possible implications, world, experiences, people. Nor even impossible ruled out, but perhaps qualified in some way. And primary value but not exclusive value. And thus such philosophy instead of being not useful - which of course in a sense it isn't - is instead denominated not especially useful at this time.

Philosophy and engineering then each able profitably to inform the other, but in important ways different, and thus not directly translatable one into the other.

An ontological commitment though can't exist before you have had pragmatic confrontation. The ontological commitment is based on a knowledge of the object/subject in question. It has to be admitted though that there seems an a priori knowledge of, and an accompanying ontological commitment to most objects/subjects one approaches. These might be innate or gathered by myriads of (unconscious) encounters one has during life from which a new (conscious) approach can follow.

One cannot justify the usefulness of a model of data without first making ontological commitments. The concept of usefulness only comes after committing to some notion of truth, that cannot be pragmatically determined on pain of circularity. — sime

I think it's clear from what I've written that I don't agree.

And there seem lots of ways that philosophy is not transcribable as any kind of engineering. But that imo in no way disqualifies an engineering approach to philosophic matters. Expectations of utility have to be modified, to be sure. But salient is the command to think, think through, test and analyze, evaluate (& etc.), rinse and repeat until done. — tim wood

Engineering is nothing special. It's mostly just figuring stuff out and then deciding what to do. I'm using it here as a stand-in for all the regular stuff all people do every day. People need to know things in order to make decisions about what needs to be done. It bothers me that all the philosophical talk about knowledge and truth never gets around to the reason we need knowledge in the first place. We need it because we need to know things in order to do things. The knowledge we talk about here on the forum has very little to do with the knowledge I use, all of us use, on a day to day basis.

What this needs, imo, is the addition of the word "possible." Possible implications, world, experiences, people. Nor even impossible ruled out, but perhaps qualified in some way. And primary value but not exclusive value. And thus such philosophy instead of being not useful - which of course in a sense it isn't - is instead denominated not especially useful at this time. — tim wood

If what you're getting at is that the knowledge we gather that seems useless may have a use we don't know of yet, I agree. Curiosity is a very pragmatic drive. It helps us build an understanding of the world beyond our current needs. That context helps make what we know more robust and provides additional information for when conditions change.

I don't think my list starts far back enough to be a general guideline. Most questions aren't even precise enough to get numbers associated with them!

I don't think my list starts far back enough to be a general guideline. Most questions aren't even precise enough to get numbers associated with them! — fdrake

I didn't mean to imply the processes you and I described were the same. I was using it to show that the way I was presenting things was not limited to just one kind of knowledge.

I didn't mean to imply the processes you and I described were the same. I was using it to show that the way I was presenting things was not limited to just one kind of knowledge. — T Clark

Ah I see. Sorry. Do you have a reference for a Site Conceptual Model?

I think it's clear from what I've written that I don't agree. — T Clark

I'm not sure that we do disagree. You presumably agree that modelling assumptions , which are ultimately causal or logical, aren't empirically verifiable, and that on the other hand, unless modelling assumptions are made, to speak of learning from data is meaningless.

It isn't clear to me how to philosophically distinguish epistemological pragmatism from a supposed anti-thesis. I am under the impression that epistemological pragmatism is being defined here in terms of the practicality of the problem pursued, rather than in terms of the method of inquiry which at every step hangs upon intuition regarding non-verifiable assumptions of causality.

Ah I see. Sorry. Do you have a reference for a Site Conceptual Model? — fdrake

Here's a link to where you can see a copy of U.S.EPA's "Guidance for Conducting Remedial Investigations and Feasibility Studies Under CERCLA." CERCLA is the law that created the Superfund program. This really is the source for all the work we did doing site cleanup. I always thought EPA did a good job with this guidance. States and other agencies often wrote their own guidances, but this provided the model for much of that. EPA called it Conceptual Site Model. I don't know why we always called it Site Conceptual Model.

https://nepis.epa.gov/Exe/ZyNET.exe/10001VGY.TXT?ZyActionD=ZyDocument&Client=EPA&Index=1986+Thru+1990&Docs=&Query=&Time=&EndTime=&SearchMethod=1&TocRestrict=n&Toc=&TocEntry=&QField=&QFieldYear=&QFieldMonth=&QFieldDay=&IntQFieldOp=0&ExtQFieldOp=0&XmlQuery=&File=D%3A%5Czyfiles%5CIndex%20Data%5C86thru90%5CTxt%5C00000003%5C10001VGY.txt&User=ANONYMOUS&Password=anonymous&SortMethod=h%7C-&MaximumDocuments=1&FuzzyDegree=0&ImageQuality=r75g8/r75g8/x150y150g16/i425&Display=hpfr&DefSeekPage=x&SearchBack=ZyActionL&Back=ZyActionS&BackDesc=Results%20page&MaximumPages=1&ZyEntry=1&SeekPage=x&ZyPURL#

What did you engineer?

First - Put together what you know about the subject at hand and how you know it. — T Clark

So what you are describing in the method you set out presupposes that we already know stuff.

I assume the process is iterative?

I'm not sure that we do disagree. You presumably agree that modelling assumptions , which are ultimately causal or logical, aren't empirically verifiable, and that on the other hand, unless modelling assumptions are made, to speak of learning from data is meaningless. — sime

I'm not sure if I understand. A site conceptual model is just a description, image of the site which lays out all the information gathered during the investigations. To me, the most useful way of presenting a SCM is visually, using figures. Data tables are also needed. There will also be calculations e.g. groundwater flow direction and velocity, contaminant degradation rates, averages. On the figures, you can show the locations of the sources of the contamination and how it has moved and is presently distributed across the site. You can also show the expected distribution of contamination in the future based on groundwater and fate and transport modelling. You can also show the locations of existing and potential human and environmental receptors.

There are certainly assumptions that go into calculations and computer based modelling. Is that what you are talking about? There are also assumptions required by the fact that most of what is going on takes place underground and the number of data points we can provide is limited. Typical data points include boring logs; analytical results of soil, groundwater, and sediment samples; visual observation of site conditions; topographic and bathymetric surveys; geophysical surveys; and wetland surveys. Going deeper, there are assumptions associated with laboratory analytical methods. Which in particular are you talking about?

I am under the impression that epistemological pragmatism is being defined here in terms of the practicality of the problem pursued, rather than in terms of the method of inquiry — sime

The distinction that's important to me here is the one between one way of seeing knowledge and another. Typically, knowledge is defined based on the truth value of a proposition. Except in relatively simple situations, that type of knowledge isn't adequate to deal with practical problems. For that, information has to be incorporated into a comprehensive summary, what I called a site conceptual model. As I noted, SCMs aren't true or false, they are accurate or not.

which at every step hangs upon intuition regarding non-verifiable assumptions of causality. — sime

Please explain.

So what you are describing in the method you set out presupposes that we already know stuff.

I assume the process is iterative? — Banno

At a contaminated site, we generally know stuff before we really start a formal investigation. We observe the site, look at historic maps and aerial photographs, and talk to people living or working at the site. We check government databases to see if there have been any reports of environmental issues on the property or nearby ones. That limited information can be used to prepare a preliminary SCM which gives us enough to get started in planning additional investigation activities.

So, yes, it is an iterative process.

What did you engineer? — Raymond

My degree is in civil engineering. I worked for environmental engineering companies investigating and cleaning up contaminated properties.

Great! How was philosophy useful then? Ah. It's in your question!

Cheers.

Strikes me as simply good method. What is it that makes it specifically pragmatic?

You articulated well your experience as a civil and environmental engineer and how it formed your view about knowledge.

It appears like you're describing knowledge in the context of a single individual. I would add that when it comes to collective problem solving, it's important to articulate thoughts promptly and succinctly. Knowing something well means being able to effectively explain it to others. It's also important to challenge others to help them solidify their own knowledge. I'll go ahead and challenge some of the ideas in the OP.

"Pragmatic Excellence" is one of the engineering values at the company where I work as a software engineer. I endorse pragmatism a lot. To me, being pragmatic means making decisions despite the lack of knowledge or sometimes even against what I know. Knowledge and pragmatism can conflict. This makes me wonder if it's safe to combine the terms "pragmatic" and "epistemology" together.

It's easy to arrive at a contradiction with "pragmatic epistemology". If we all adopt a pragmatic attitude towards knowledge, then we will stop pursuing the knowledge that is far removed from our everyday lives. However, if we look back at the past, we will see that our modern everyday world is grounded in the scientific projects that didn't offer any practical value at the time they were carried out.

A good example of this is the discovery of quantum physics in 1920s. Some of the smartest physicists in the world were devoted to probing the behaviour of matter on the smallest scales. At the time, you could critique their fascination with atoms and claim that nothing could be more useless to you than what they were doing in the laboratory. But their work led to the invention of the digital computer. It's hard to think of anything less transformative of our everyday world than that.

Strikes me as simply good method. What is it that makes it specifically pragmatic? — Banno

I like this definition of "pragmatism," which is from Wikipedia:

Pragmatism is a philosophical tradition that considers words and thought as tools and instruments for prediction, problem solving, and action, and rejects the idea that the function of thought is to describe, represent, or mirror reality.

My example shows one way that knowledge can be used for "prediction, problem solving, and action." The most important issue here for me is the different definitions of "knowledge" required for the two approaches. When we talk about knowledge here on the forum, we usually talk about truth, with truth defined as something that applies to propositions, statements. The famous, maybe infamous, example of that is justified true belief. Again from Wikipedia:

The concept of justified true belief states that in order to know that a given proposition is true, one must not only believe the relevant true proposition, but also have justification for doing so. In more formal terms, an agent S knows that a proposition P is true if and only if:

• P is true
• S believes that P is true, and
• S is justified in believing that P is true.
  

I've always found this view of knowledge unsatisfactory. It's misleading and doesn't reflect how people really use knowledge. The fact that the definition can be undermined by something as silly as the Gettier problems shows me how weak it is.

As I stated previously, the definition of knowledge I prefer is information incorporated into a conceptual model that reflects the phenomena of interest. I think you could argue that this is similar to a coherence theory of truth. I have no problem with that. The important difference is that a pragmatic theory of knowledge always focuses on the use knowledge will be put.

To summarize, again - Philosophers mostly talk about knowledge as a proposition that can be true or false. In a pragmatic view, knowledge is a conceptual model that can be accurate or less accurate.

Pragmatism is a philosophical tradition that considers words and thought as tools and instruments for prediction, problem solving, and action, and rejects the idea that the function of thought is to describe, represent, or mirror reality. — T Clark

:up: Is Wikipedia good (enough)?

It doesn't have to be true, it's got to be useful.

It doesn't matter whether the cat is black or white so long as it catches mice. — Deng

It appears like you're describing knowledge in the context of a single individual. I would add that when it comes to collective problem solving, it's important to articulate thoughts promptly and succinctly. Knowing something well means being able to effectively explain it to others. It's also important to challenge others to help them solidify their own knowledge. — pfirefry

In my work, all of the activities described are typically performed by a project team of from three to 10 people. The process is specifically planned to use collective problem solving. One of the really good things about a well developed conceptual model is that it is very useful presenting a comprehensive vision of the problem to people who are not familiar with it, often including non-technical decision makers.

"Pragmatic Excellence" is one of the engineering values at the company where I work as a software engineer. I endorse pragmatism a lot. To me, being pragmatic means making decisions despite the lack of knowledge or sometimes even against what I know. Knowledge and pragmatism can conflict. This makes me wonder if it's safe to combine the terms "pragmatic" and "epistemology" together. — pfirefry

I don't know much about software engineering and how it compares with what I did for a living. If what you are saying is that sometimes you have to make decisions based on limited and uncertain knowledge, then I agree. If you mean something different than that, then I don't understand.

One thing I haven't discussed is how the information we incorporate into the conceptual model is evaluated, justified. Justification comes in the steps where we evaluate the SCM. We need to answer these questions:

• Does the information we have provide adequate support?
• Can we identify and document the source of that information?
• What are the uncertainties in our knowledge?
• What are the consequences of us being wrong?

It's easy to arrive at a contradiction with "pragmatic epistemology". If we all adopt a pragmatic attitude towards knowledge, then we will stop pursuing the knowledge that is far removed from our everyday lives. However, if we look back at the past, we will see that our modern everyday world is grounded in the scientific projects that didn't offer any practical value at the time they were carried out. — pfirefry

I don't see how that is a contradiction of anything, but I do think it is a valid criticism. I addressed it in a fairly half-assed way in a previous post. I said that curiosity is a pragmatic drive that leads us to try to gain a wider understanding of the world so we can address changing conditions. That's true, but weak. Here's the important point for me - even when scientists and others are studying phenomena with no known practical use, they still use methods similar to those I've described. The goal of any research is to develop conceptual models of the conditions being studied. Quantum mechanics, Newtonian physics, and relativity are all conceptual models.

Sure, pragmatism pretends to drop the notion of truth in the hope of working instead only with belief.

But one does not have to drop the notion of truth in order to act in accord with your six methodological points. Indeed, it is clear from the first point that some things are to be taken as true in order to get the process started.

It would not do in your example to doubt the existence of groundwater and soil. These are presumed as constitutive of the activity in which you are engaged.

But further, it would not do to doubt that one can keep accurate records, that one can make measurements, that one can communicate these with others, that one's actions can make a difference to the environment.

There is always soem stuff that is taken as fundamental.

Sure, pragmatism pretends to drop the notion of truth in the hope of working instead only with belief. — Banno

I'll let what I've already written stand as a response to this. I've tried to be clear about my understanding of these things and I think I've succeeded. You're a smart guy. It's not that hard. You just like being contrary. That doesn't mean you have to agree with me.

But one does not have to drop the notion of truth in order to act in accord with your six methodological points. Indeed, it is clear from the first point that some things are to be taken as true in order to get the process started.

It would not do in your example to doubt the existence of groundwater and soil. These are presumed as constitutive of the activity in which you are engaged.

But further, it would not do to doubt that one can keep accurate records, that one can make measurements, that one can communicate these with others, that one's actions can make a difference to the environment. — Banno

That's it? That's what truth is needed for - to tell us the world exists? That's more metaphysics than knowledge.

In software engineering, we have a practice of consolidating knowledge in Design Docs, also called RFCs (Requests For Comments). E.g. Google, Uber. Overall, it is similar to SCM. When someone needs to build a new feature or change an existing system, they will write the proposal in a design doc and assign relevant stakeholders for a review. This process has two main goals:

1. To help the author solidify their knowledge. Oftentimes when I start writing a design doc, I feel that I already understand the problem and the solution. But in the process of writing I discover significant gaps in my knowledge, which lead me to change the details of my solution.
2. To reach an alignment between stakeholders. A design doc needs to be approved by all stakeholders before the actual work can begin. Peer-reviewing helps evaluate the solution from a diverse set of perspectives.

A good design doc will clearly outline a problem, set a concrete goal, provide a solution, and evaluate the solution from various perspectives (how does it compares to alternatives, what are the performance and security implications, any assumptions made, main risks and unknowns).

I like this practice and actively promote it to others. Here are some of the problems that commonly occur:

• Sometimes it's hard to follow what the author is saying. The knowledge exists in the author's head, but it's difficult to reconstruct it by reading the document.
• Sometimes the author doesn't have a sufficient understanding of the problem. By reading their document I can tell that they didn't dive deep enough, or didn't put enough effort to clarify the details. I find this annoying because it places a burden on me to identify gaps and persuade the author to fill them.
• Design docs quickly run out of date. Software systems evolve at a rapid pace. When I look at older design docs, I need to keep in mind that the information that was relevant at the time of writing may no longer be accurate or relevant at the time of reading.
• Design docs are narrow-scoped. They are only concerned with the goal at hand, and they disregard any irrelevant information. They are effective tools to make progress, but they don't paint a clear picture of the current state of technology. That's why we maintain engineering documentation as a separate resource to provide a high-level overview of the system. Design docs are for deep problem solving, and engineering documentation is for high-level knowledge sharing.

Overall, my stance is that knowledge exists in our heads. We use processes such as SCM and design docs to solidify our own knowledge and to align our knowledge with the knowledge of others. The artefacts of the process, such as SCM and design docs, don't fully capture the knowledge that we have, but they help their readers to form their own knowledge. Obtaining knowledge and sharing it with others requires investing time and effort. A pragmatic person knows how to balance the time spent researching and the time spent doing.

Intuitively, we think that sharing knowledge is an altruistic act, because it takes away someone's time for the benefit of others. But I think oftentimes it is not the case. For example, this comment is an artefact of knowledge sharing. I expect that 90% of the value generated from this comment is for my personal gain, from organising my thoughts on this topic, and I can only hope that it will generate at least some value for others.

Philosophers mostly talk about knowledge as a proposition that can be true or false. In a pragmatic view, knowledge is a conceptual model that can be accurate or less accurate. — T Clark

Unless you mean to exclude pragmatics like Dewey and James, in a pragmatic view. knowledge is a conceptual
model that can be more or less USEFUL.

As a pragmatist, I assert that no philosophical position is meaningful unless it has concrete implications for phenomena present in the everyday world, life, and experience of normal human beings. — T Clark

You mentioned forms of philosophy reliant on truth propositional logic as not pragmatically meaningful, but I assume you would also include many Continental philosophers. There is a danger that ‘normal human beings’ becomes synonymous with ‘ human being who can understand the philosophy’. But the greatest works of continental philosophy, from Plato to Descartes, Spinoza, Hegel and Nietzsche, were initially and for the most part still to this day meaningful to only a small segment of the population. But such ‘useful’ philosophies became the basis for interpretations by mathematicians and scientists (Newton, Frege, Gauss, Heisenberg, Godel, Turing, Darwin, Freud) who produced models influenced by these ideas which in turn led to new technologies, therapies, sciences. So the usefulness doesn’t happen as a direct communication from abstract philosophy to ‘normal human beings’ , it happens in stages, by being translated into more and more pragmatically articulated versions over time, accessible to increasingly large segments of the population. The general concepts that led eventually to the computer you are using were first formulated by ‘useless’ philosophers 200 years ago. The concrete technology is just the final stage in a long process of the spread of an idea. As we speak there are a handful of philosophers generating the conceptual basis of what will constitute the next technological revolution 50 or 100 years from now. Only then will ‘normal human beings’ likely recognize its value, and only in a more narrowly engineered form.

In software engineering, we have a practice of consolidating knowledge in Design Docs, also called RFCs (Requests For Comments). E.g. Google, Uber. Overall, it is similar to SCM. When someone needs to build a new feature or change an existing system, they will write the proposal in a design doc and assign relevant stakeholders for a review. — pfirefry

The design docs you are talking about seem like what we call basis of design memoranda (BDM). BDM are usually prepared when data collection is complete, although design investigations required to gather specific additional information my be described. The BDM summarizes all the information required to complete the design including the goals of the design; performance requirements; required data analyses and modelling; a data summary; the SCM; and operation, maintenance, and monitoring requirements for the completed design.

Overall, my stance is that knowledge exists in our heads. We use processes such as SCM and design docs to solidify our own knowledge and to align our knowledge with the knowledge of others. The artefacts of the process, such as SCM and design docs, don't fully capture the knowledge that we have, but they help their readers to form their own knowledge. Obtaining knowledge and sharing it with others requires investing time and effort. A pragmatic person knows how to balance the time spent researching and the time spent doing. — pfirefry

In the kinds of designs I have worked on, professional standards and standard engineering practice require that the basis of the design has to be documented in writing to justify design decisions that are made. The same is true of all subsequent design documents. At any time I should be able to answer the question "Why did you do it that way?" and provide backup for the decision.

Intuitively, we think that sharing knowledge is an altruistic act, because it takes away someone's time for the benefit of others. But I think oftentimes it is not the case. For example, this comment is an artefact of knowledge sharing. I expect that 90% of the value generated from this comment is for my personal gain, from organising my thoughts on this topic, and I can only hope that it will generate at least some value for others. — pfirefry

What goes on here is really different from what goes on in the design process. During design, sharing knowledge, or at least documenting it, is a fundamental requirement. It's not altruistic at all.

What goes on here is really different from what goes on in the design process. During design, sharing knowledge, or at least documenting it, is a fundamental requirement. It's not altruistic at all. — T Clark

Yes, it is a requirement, and some people treat it as an inconvenience: "I understand the problem, and I have a solution. Why should I be wasting my time on writing it down for the sake of bureaucracy?" Software engineers are free-spirited and they despise inefficient processes. A part of my job is to teach them to embrace this process, because I'm convinced that writing design docs benefits the author even more than the reader.