A three-page paper that shook philosophy, with lessons for software engineers
1–10 of 185 posts
Re: A three-page paper that shook philosophy, with lessons for software engineers
#2The "cow in the field" example reminds me of two heuristics I like: am I right for the wrong reason?; am I wrong for the right reason?
Being right for the wrong reason is dangerous: it's not easy to spot, and it perpetuates false sense of security leaving "black swan events" unanticipated. This might occur during debugging as the article points out, or e.g. during A/B testing of a product.
Bring wrong for the right reason is just plain frustrating.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#3These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions.
One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?
Re: A three-page paper that shook philosophy, with lessons for software engineers
#4This hits close to me as a possible reason why I could never get good at solving geometry problems, solid geometry especially. Most problems would be trivial when one assumes specific preconditions, but my mind was always wandering around, looking at all potential sides of a problem and I could never solve anything. To quote the author from my particular pov:
a problem has multiple potential causes, and you have every reason to believe in one of them, even though another is secretly responsible.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#5I had a philosophy lecture last year that included a lot of epistemology (Theory of Knowledge). We talked a fair bit about justified true beliefs, but Gettier only came up in a side note - the professor being more interested in skepticism and the responses thereto. Never would have dreamt of applying that lecture to programming, though.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#6These cases seem to come up often (weekly?) in software development. I wonder how often they come up in other professions. One common case is when you change or delete a comment, and suddenly something breaks. It couldn't have been the comment... but it was working fine before my edit... wasn't it?
Considering the fact that so much of programming is error finding, it's useful (and probably necessary) to have a solid heuristic for quickly determining causal relationships.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#7This hits close to me as a possible reason why I could never get good at solving geometry problems, solid geometry especially. Most problems would be trivial when one assumes specific preconditions, but my mind was always wandering around, looking at all potential sides of a problem and I could never solve anything. To quote the author from my particular pov: a problem has multiple potential causes, and you have ever…
I think you should try looking at geometry more like a creation initially then a problem. In this manner you can see assumptions as just building up more simple worlds with those constraints. I have found this view helps when teaching geometry as it empowers the mind.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#8The propensity for mistaking belief for facts certainly take daily hits as a software developer. "How come this simple thing isn't working? I thought of everything didn't I?". After a while you are forced to realize that belief isn't the same as reality.
It seems insights like this don't easily translate into other domains though, like relationships, dearly held political views etc. We prefer to think of them as based on facts, when in all probability they are merely beliefs fraught with assumptions.
Some people might be good at being skeptics in all areas, but I sense most share my own ineptitude here, the reason probably being that any such (incorrect) beliefs don't immediately come back and bite us, as in programming.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#9The propensity for mistaking belief for facts certainly take daily hits as a software developer. "How come this simple thing isn't working? I thought of everything didn't I?". After a while you are forced to realize that belief isn't the same as reality. It seems insights like this don't easily translate into other domains though, like relationships, dearly held political views etc. We prefer to think of them as base…
The funny thing about development is what's say 90% of the time you are convinced everything is correct and should be working and it's immensely frustrating because it's not, so you know you are wrong but are unable to offer yourself a more convincing theory and just get stuck until something clicks. But then there's that 10% of the time where you're actually right. And you don't know which one it's going to be. So you have to calm yourself down like "I know I think Im right about this but clearly Im not" but at the same time you have to hold onto that conviction because you're right damnit. Haha.
Re: A three-page paper that shook philosophy, with lessons for software engineers
#10This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are:
* expected output from a known input (intention)
* unexpected output from a known input (defect)
* expected output from an unknown input (serendipity)
* unexpected output from an unknown input (unintentional)
For example I maintain a parser and beautifier for many different languages and many different grammars of those languages. In some cases these languages are really multiple languages (or grammars) imposed upon each other and so the application code must recursively switch to different parsing schemes in the middle of the given input.
The more decisions you make in your application code the more complex it becomes and predicting complexity is hard. Since you cannot know of every combination of decisions necessary for every combination of input you do your best to impose super-isolation of tiny internal algorithms. This means you attempt to isolate decision criteria into separated atomic units and those separated atomic units must impose their decision criteria without regard for the various other atomic decision units. Provided well reasoned data structures this is less challenging than it sounds.
The goal in all of this is to eliminate unintentional results (see forth bullet point above). It is okay to be wrong, as wrong is a subjective quality, provided each of the atomic decision units are each operating correctly. When that is not enough you add further logic to reduce the interference of the various decision units upon each other. In the case of various external factors imposing interference you must ensure your application is isolated and testable apart from those external factors so that when such defects arise you can eliminate as much known criteria as rapidly as possible.
You will never be sure your open-ended system works as intended 100% of the time, but with enough test samples you can build confidence against a variety of unknown combinations.