Read the Humanities - Revision history

Kevlin at 15:00, 18 August 2009

2009-08-18T15:00:42Z

←Older revision		Revision as of 15:00, 18 August 2009
Line 13:		Line 13:
	Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and recreate tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.		Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and recreate tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.

-	Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in ''Natural Categories'' and later works that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.	+	Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in ''Natural Categories'' and later works, that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

Kevlin at 14:57, 18 August 2009

2009-08-18T14:57:06Z

←Older revision		Revision as of 14:57, 18 August 2009
Line 3:		Line 3:
	People write software with people for people. It's a people business.		People write software with people for people. It's a people business.

-	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal well with other people.	+	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into — nor ability to deal well with — other people.

	The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Programmers also collaborate closely with one another, often in very complex ways in very complicated settings. That's hard. Luckily there is an entire field of study that can help us.		The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Programmers also collaborate closely with one another, often in very complex ways in very complicated settings. That's hard. Luckily there is an entire field of study that can help us.

-	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements". Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why ~~programers~~ who are steeped in their problem domain tend to do better than those who stand apart from it.	+	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements." Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programmers who are steeped in their problem domain tend to do better than those who stand apart from it.

-	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming ~~names~~ like "cash flow" which we might encounter in talking about a financial system can be seen as metaphorical. Here the metaphor is that "money is a liquid". How does that metaphor influence the way we think about systems that handle money? As technologists, to, we might talk about "layers" in a "stack" of protocols with some being "high level" and some "low level". This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking form time to time.	+	Lakoff and Johnson present us with a catalogue of ''Metaphors We Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming terms like ''cash flow'', which we might encounter in talking about a financial system, can be seen as metaphorical. Here the metaphor is that "money is a liquid." How does that metaphor influence the way we think about systems that handle money? As technologists, too, we might talk about ''layers'' in a ''stack'' of protocols with some being ''high level'' and some ''low level''. This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking form time to time.

-	Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and ~~re-create~~ tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.	+	Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and recreate tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.

	Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in ''Natural Categories'' and later works that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.		Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in ''Natural Categories'' and later works that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.

KeithBraithwaite at 14:54, 18 August 2009

2009-08-18T14:54:32Z

←Older revision		Revision as of 14:54, 18 August 2009
Line 13:		Line 13:
	Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and re-create tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.		Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and re-create tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.

-		+	Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in ''Natural Categories'' and later works that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite at 14:06, 18 August 2009

2009-08-18T14:06:05Z

←Older revision		Revision as of 14:06, 18 August 2009
Line 5:		Line 5:
	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal well with other people.		Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal well with other people.

-	The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Luckily there is an entire field of study that can help us.	+	The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Programmers also collaborate closely with one another, often in very complex ways in very complicated settings. That's hard. Luckily there is an entire field of study that can help us.

	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements". Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programers who are steeped in their problem domain tend to do better than those who stand apart from it.		For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements". Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programers who are steeped in their problem domain tend to do better than those who stand apart from it.

-	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming names like "cash flow" which we might encounter in talking about a financial system can be seen as metaphorical. Here the metaphor is that "money is a liquid". How does that metaphor influence the way we think about systems that handle money? As technologists, to, we might talk about "layers" in a "stack" of protocols with some being "high level" and some "low level". This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build.	+	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming names like "cash flow" which we might encounter in talking about a financial system can be seen as metaphorical. Here the metaphor is that "money is a liquid". How does that metaphor influence the way we think about systems that handle money? As technologists, to, we might talk about "layers" in a "stack" of protocols with some being "high level" and some "low level". This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking form time to time.

		+	Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and re-create tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in ''Being and Time'', the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.
		+
		+

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite at 13:36, 18 August 2009

2009-08-18T13:36:10Z

←Older revision		Revision as of 13:36, 18 August 2009
Line 7:		Line 7:
	The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Luckily there is an entire field of study that can help us.		The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Luckily there is an entire field of study that can help us.

-	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a ~~serialisation~~ format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding. Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programers who are steeped in their problem domain tend to do better than those who stand apart from it.	+	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements". Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programers who are steeped in their problem domain tend to do better than those who stand apart from it.

-	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live.	+	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming names like "cash flow" which we might encounter in talking about a financial system can be seen as metaphorical. Here the metaphor is that "money is a liquid". How does that metaphor influence the way we think about systems that handle money? As technologists, to, we might talk about "layers" in a "stack" of protocols with some being "high level" and some "low level". This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build.

		+
	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite at 08:15, 16 August 2009

2009-08-16T08:15:40Z

←Older revision		Revision as of 08:15, 16 August 2009
Line 3:		Line 3:
	People write software with people for people. It's a people business.		People write software with people for people. It's a people business.

-	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. ~~Luckily there is an entire field of study that can help us.~~	+	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal well with other people.

-	~~It used~~ to ~~be quite common~~ to ~~attend plays~~ and ~~read literature and philosophy (at least~~, ~~not~~ the ~~analytic kind~~) ~~in quite large volumes in order~~ to ~~find out what it meant~~ to be a person.	+	The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Luckily there is an entire field of study that can help us.
		+
		+	For example, Ludwig Wittgenstein makes a very good case in the ''Philosophical Investigations'' (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialisation format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding. Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programers who are steeped in their problem domain tend to do better than those who stand apart from it.
		+
		+	Lakoff and Johnson present us with a catalogue of ''Metaphors we Live By'', suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live.

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite at 15:46, 9 August 2009

2009-08-09T15:46:50Z

←Older revision		Revision as of 15:46, 9 August 2009
Line 3:		Line 3:
	People write software with people for people. It's a people business.		People write software with people for people. It's a people business.

-	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help us.	+	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help us.
		+
		+	It used to be quite common to attend plays and read literature and philosophy (at least, not the analytic kind) in quite large volumes in order to find out what it meant to be a person.

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite at 08:13, 8 August 2009

2009-08-08T08:13:52Z

←Older revision		Revision as of 08:13, 8 August 2009
Line 3:		Line 3:
	People write software with people for people. It's a people business.		People write software with people for people. It's a people business.

-	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help ~~the programmer out~~.	+	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help us.

	by [[Keith Braithwaite]]		by [[Keith Braithwaite]]

KeithBraithwaite: added boilerplate

2009-08-08T07:50:48Z

added boilerplate

←Older revision		Revision as of 07:50, 8 August 2009
Line 4:		Line 4:

	Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help the programmer out.		Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help the programmer out.
		+
		+	by [[Keith Braithwaite]]
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

KeithBraithwaite: begun

2009-08-08T07:49:11Z

begun

New page

In all but the smallest development project people work with people to achieve the goal. In all but the most abstracted field of research people write software for the purpose of supporting someone in some goal of theirs.

People write software with people for people. It's a people business.

Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into nor ability to deal with other people. Luckily there is an entire field of study that can help the programmer out.