Sometimes knowledge is not in a form that can be effectively communicated.
This is an interesting example. I am looking in the context of engineering, software engineering in particular. Many leads, and directors, are like these elephant trainers, with an attitude that "this can't be taught, you just have to learn it".
Generally, this is countered with "if you can't write it down, how well do you really know what your doing?". No process can be known perfectly or completely, but all processes can be recorded to the extent known, and then refined as more knowledge is gained. The measure of "knowledge" is the extent to which it can be taught. The elephant trainer is an a good non-software example.
Would well though it were. It simply does not work that way
Does for me fairly consistently, but perhaps I am a special case. I lack the overall negative outlook. Perhaps other factors than sharing are at play?
I wonder if you've ever been in a car wreck.
lol! Classic! I guess that answers the question.
Clearly, this "cooperation and sharing with the group" thing is not your bag. Fair enough. You have a demonstrated level of expertise and experience that show your way works for you with great and consistent success. I would not presume to persuade you to change anything. Thank you for sharing your thoughts.
trade secret in this case is not every one wants to do the tedious work of programming and soldering, I would be a rich person if I had a dime every time I did something and heard...
"why did you do that you could have bought it made already?"
Part of the reason for mentioning the elephant trainer example is that the people who have the knowledge are not necessarily the ones who are suited for distilling it and passing it on. Sometimes the knowledgable people don't understand their own knowledge or don't understand the steps that need to be taken to understand it. That's where the professional "knowledge engineer" can be helpful. These are people who have to have some knowledge at least of the subject area, but mostly have to be excellent students of human behavior.
I suppose you would like Parallax to share all their information and designs with the rest of the world. Be for real.
...
Oh, and by the way, I noticed the two of you also avoided the Parallax issue I brought up. Should Parallax share their knowledge?
Sorry bruce, missed this post. Did not mean to "avoid" the issue.
My opinion - It up to Parallax as to what Parallax does with their knowledge. They share some stuff, they don't share other stuff. It their choice to make.
As long as I have the information I need to do what I do, then I am fine. If I don't have the information I need, I have to get it or find it out for myself. Fairly clear cut.
Parallax has always shared the information I need to do what I want to do, and the extent of sharing and Parallax's business model has not presented any conflict to me. The information Parallax does not share is for the most part irrelevant to my needs.
parallax is a cool company they seem to want to encourage us to use the parts they make for other things this is smart since the more things the parts can be used for the more parts they sell.
that being said.
parallax is sponsoring my Earth-Day contest contest post any ideals you have and you can win first prize is a choice of a C3 full kit or scribbler.
and that's what we call shameless promotion
prof_braino,
You're a real hoot.
Yes, things generally go well, people are pleased, especially the "must be a self-starter" gigs.
When supervisors inevitably (that's a good word) go off to greener pastures, or some darned thing, successors have the bright idea that I get busy documenting everything I do so that "anyone, someone walking by" could follow the steps and get along - and it's not because they want the best for me. I wonder (rhetorically) why it gets their goat (VERY upset, as though I asked them to sacrifice their daughters in a satanic ritual) when I point out that my job isn't anything like theirs and suggest that they do as they propose.
As with so many things in life there is no absolute answer to this question. In general sharing knowledge is a good thing, particularly for society as a whole. On the other hand PJ has a valid point about not wanting to share knowledge that would be used to your own detriment.
I doubt that "anyone, someone walking by" could perform the job of someone who has spent years acquiring the knowledge, experience, and expertise required regardless of how well it is documented. That however is not the point. The real point is that any supervisor or manager stupid enough to waste the time required to document something to that level of detail is also stupid enough to beleive it is possible, and to fire you when the job is done.
Oh, and by the way, I noticed the two of you also avoided the Parallax issue I brought up. Should Parallax share their knowledge?
Parallax already shares a tremendous amount of knowledge, however they do not (nor should they) share the information required to manufacture the chips. There is already enough knowledge out there that a competitor could produce a similar chip with a relatively modest effort, and if Parallax should fail it is very likely that the IP and other knowledge would be bought up and put to use.
Parallax already shares a tremendous amount of knowledge
I agree and do not dispute that point, I was just giving everyone an example that was close to home The sharing of knowledge is not always beneficial to either the person sharing the knowledge or the person receiving the knowledge, it all depends on the knowledge and information being shared.
For instance, here is another example:
Let's say a DIYer comes up to me and asks me how to wire up a 220V 50A circuit for his brand new welder. And let's say I tell him exactly how to do it, along with the safety precautions that should be followed.
Then, 24 hours later, I am reading about how he died of electrocution in the morning newspaper. Was it it beneficial to either of us for me to share my knowledge? No it wasn't, because for the rest of my life, I will have to live with the fact that I shared knowledge with this guy that resulted in his death, and of course it was not beneficial to him, because he is no longer breathing.
And let's say I tell him exactly how to do it, along with the safety precautions that should be followed. Then, 24 hours later, I am reading about how he died of electrocution in the morning newspaper. Was it it beneficial to either of us for me to share my knowledge?
This is a very bad example. The sad fact is, you can't cure stupid. If you did indeed advise someone of the risks and safety precautions and they didn't follow through, it's hardly your fault. One could argue that they would have been at greater risk trying to do it with other advice, or none at all, lacking the safety instructions. I would hope that those of us who aren't stupid don't have trouble getting the info we need because of such liability... oh wait, sometimes we do. Well that sucks.
Irregardless of fault, if I shared such knowledge with a person, and they died, I would feel guilty.
While understandable, this is also irrational. If you give correct instructions and they are not correctly followed, the results aren't your fault. Now if you give bad instructions (Lights out? No fuse? You can use a penny instead...) that's a different story. But our civilization would grind to a halt if nobody dared giving instructions that could result in harm if not followed correctly. You can burn the house down baking a cake if you do it wrong enough.
...if I shared such knowledge with a person, and they died, I would feel guilty.
Because their death wasn't as quick as it would have been had you not shared your knowledge and they went ahead anyway, ignoring your entreaty to hire an electrician? Either way, it seems, regardless of the advice you give them, or not, you have a connection to their subsequent fate. Unless you stand a chance of dissuading them, you've got to give them the best information you can.
Let's say a DIYer comes up to me and asks me how to wire up a 220V 50A circuit for his brand new welder. And let's say I tell him exactly how to do it, along with the safety precautions that should be followed.
Then, 24 hours later, I am reading about how he died of electrocution in the morning newspaper. Was it it beneficial to either of us for me to share my knowledge? No it wasn't, because for the rest of my life, I will have to live with the fact that I shared knowledge with this guy that resulted in his death, and of course it was not beneficial to him, because he is no longer breathing.
Bruce
I have to agree with localroger on this one. How do you decide what is worse in a case like this?
I could refuse to provide any advice, advise him of the danger, and recommend he has a qualified electrician do the work, or provide step by step instructions starting with "First make sure the power is OFF. 220V CAN KILL YOU".
He could decide to do it any way and be electrocuted so unless he appeared to be mentally challenged I would warn him of the danger, recommend having a professional do the work, and then provide the step by step instructions. If he did appear to be mentally challenged I would tell him not to try it and warn whoever is responsible for him of his intentions.
Yes, I would feel bad if he managed to get electrocuted but at the risk of seeming callous I would have to consider that "chlorine for the gene pool".
this line I have drawn if the person asks for advice on how to do something dangerous I say,
"that is dangerous ____________ can occur, don't do."
sadly one did not listen and sent himself to the ER when he asked how do you fix a TV tube and I told him
"Don't even try the capacitors can hold voltages and provide a huge shock."
he did and his wife had to call for an ambulance.
The real point is that any supervisor or manager stupid enough to waste the time required to document something to that level of detail is also stupid enough to beleive it is possible...
I have spend a good part of my career working under such regimes. Usually in military and aerospace fields. When software is built by large teams, really has to work and really have to outlive the puny careers and whims of individual programmers you will find that is common practice.
As almost a joke, my project manager on the Boeing 777 Primary Flight Computer project printed out the requirement specification document. It was a stack of paper a meter and a half high. That's before we get to the actual architecture, design and detail design specs of the software to be written. Or the millions of test case that need to be documented, and approved.
I'm sure you will be much more comfortable when flying in a 777 knowing that we took the trouble to do all of that. Rather than just having the code thrown together by some software pre-madonna with nobody else in the world knowing what he has put in there.
In general if anyone is investing their money in employing you to produce code and all you return is a binary blob and perhaps source then you are not a good investment.
Why do software engineers (if the term "engineer" is applicable to most of them) feel they are some how different from engineers in electronics, building construction, bridge design, avionics, etc etc where a great deal of documentation and traceability is often required?
True that! Writing code for medical devices, the documentation is exhaustive. More time is spent writing specifications than is ever spent coding. After the code is written, a series of design reviews go over every line of that code, two or three times.
I was going to say, too, that it is not as easy to give away knowledge as you might think. In a previous job, I did everything I could do to try to explain a particular MODEM design to my intended replacements. But I found it impossible. They simply lacked the foundational knowledge. Meanwhile I didn't have the time to teach courses they'd missed in their education. Eventually it became clear that there was a reason they had never taken those courses, if you know what I mean.
Why do software engineers (if the term "engineer" is applicable to most of them) feel they are some how different from engineers in electronics, building construction, bridge design, avionics, etc etc where a great deal of documentation and traceability is often required?
Since you posed the question....
Somebody said manufacturing physical items is probabilistic (holes are here within a tolerance), while manufacturing software is deterministic (every copy of the final software will be exactly identical). So the tools and methods for data collection and analysis of manufacturing physical items do not make sense when directly transferred to the realm of software.
On the other hand, the design and development process for software (rather than the reproduction of the final image) CAN be approached with similar methods. This is the big deal. It allows us to use data to mature the design process just as other sections mature the manufacturing process. This is a new concept to many old geezers in software, and it scares the poop out of them. Any scrutiny or suggestion of "do differently" is taken as an offense or insult.
In non regulated industries, there is a perception that if we work too fast, or skip steps, or get the Smile out the door before its finished, that we are somehow helping the company, because we can collect the money one day sooner. In fact, the exact opposite is true, it is nearly always damaging, due to bugs, rework, bad customer feeling, lost sales, etc. Even if you show folks how nuts this behavior is, the response is usually some nonsense about "we have to do this because of the business realities". Text book insane.
For the most part, only industries where scrutiny of process is required by government regulation do software engineers and management learn to use process in a mature or mature-able fashion, such as aviation, medical, nuclear. Even in these industries, it takes years to teach folks (particularly management) that process analysis is not there to hurt them but to protect them. If we follow our process, we can't get in trouble, because we can find errors and correct them; if we don't follow process, or have a nonsense process, or falsify records, we always get in trouble or somebody gets hurt or we go to jail, when something eventually goes wrong.
But this whole concept is still too new, and will not become common place for quite some time.
We are talking about two different things here. I would never consider starting a hardware/software design without a clear specification or presenting a finished product to a customer or employer without adequate testing and documentation. The previous post was a comment on the idea of documenting the steps required to design and create the hardware/software in enough detail that someone else could use that to do the same.
Comments
This is an interesting example. I am looking in the context of engineering, software engineering in particular. Many leads, and directors, are like these elephant trainers, with an attitude that "this can't be taught, you just have to learn it".
Generally, this is countered with "if you can't write it down, how well do you really know what your doing?". No process can be known perfectly or completely, but all processes can be recorded to the extent known, and then refined as more knowledge is gained. The measure of "knowledge" is the extent to which it can be taught. The elephant trainer is an a good non-software example.
Does for me fairly consistently, but perhaps I am a special case. I lack the overall negative outlook. Perhaps other factors than sharing are at play?
lol! Classic! I guess that answers the question.
Clearly, this "cooperation and sharing with the group" thing is not your bag. Fair enough. You have a demonstrated level of expertise and experience that show your way works for you with great and consistent success. I would not presume to persuade you to change anything. Thank you for sharing your thoughts.
Vive la diff
"why did you do that you could have bought it made already?"
Sorry bruce, missed this post. Did not mean to "avoid" the issue.
My opinion - It up to Parallax as to what Parallax does with their knowledge. They share some stuff, they don't share other stuff. It their choice to make.
As long as I have the information I need to do what I do, then I am fine. If I don't have the information I need, I have to get it or find it out for myself. Fairly clear cut.
Parallax has always shared the information I need to do what I want to do, and the extent of sharing and Parallax's business model has not presented any conflict to me. The information Parallax does not share is for the most part irrelevant to my needs.
that being said.
parallax is sponsoring my Earth-Day contest contest post any ideals you have and you can win first prize is a choice of a C3 full kit or scribbler.
and that's what we call shameless promotion
You're a real hoot.
Yes, things generally go well, people are pleased, especially the "must be a self-starter" gigs.
When supervisors inevitably (that's a good word) go off to greener pastures, or some darned thing, successors have the bright idea that I get busy documenting everything I do so that "anyone, someone walking by" could follow the steps and get along - and it's not because they want the best for me. I wonder (rhetorically) why it gets their goat (VERY upset, as though I asked them to sacrifice their daughters in a satanic ritual) when I point out that my job isn't anything like theirs and suggest that they do as they propose.
I doubt that "anyone, someone walking by" could perform the job of someone who has spent years acquiring the knowledge, experience, and expertise required regardless of how well it is documented. That however is not the point. The real point is that any supervisor or manager stupid enough to waste the time required to document something to that level of detail is also stupid enough to beleive it is possible, and to fire you when the job is done.
Parallax already shares a tremendous amount of knowledge, however they do not (nor should they) share the information required to manufacture the chips. There is already enough knowledge out there that a competitor could produce a similar chip with a relatively modest effort, and if Parallax should fail it is very likely that the IP and other knowledge would be bought up and put to use.
I agree and do not dispute that point, I was just giving everyone an example that was close to home
For instance, here is another example:
Then, 24 hours later, I am reading about how he died of electrocution in the morning newspaper. Was it it beneficial to either of us for me to share my knowledge? No it wasn't, because for the rest of my life, I will have to live with the fact that I shared knowledge with this guy that resulted in his death, and of course it was not beneficial to him, because he is no longer breathing.
This is a very bad example. The sad fact is, you can't cure stupid. If you did indeed advise someone of the risks and safety precautions and they didn't follow through, it's hardly your fault. One could argue that they would have been at greater risk trying to do it with other advice, or none at all, lacking the safety instructions. I would hope that those of us who aren't stupid don't have trouble getting the info we need because of such liability... oh wait, sometimes we do. Well that sucks.
That is funny, but oh so true.
As for this part....
Irregardless of fault, if I shared such knowledge with a person, and they died, I would feel guilty.
Bruce
While understandable, this is also irrational. If you give correct instructions and they are not correctly followed, the results aren't your fault. Now if you give bad instructions (Lights out? No fuse? You can use a penny instead...) that's a different story. But our civilization would grind to a halt if nobody dared giving instructions that could result in harm if not followed correctly. You can burn the house down baking a cake if you do it wrong enough.
-Phil
I did not look at it from that perspective, but you have a very valid point.
Bruce
I have to agree with localroger on this one. How do you decide what is worse in a case like this?
I could refuse to provide any advice, advise him of the danger, and recommend he has a qualified electrician do the work, or provide step by step instructions starting with "First make sure the power is OFF. 220V CAN KILL YOU".
He could decide to do it any way and be electrocuted so unless he appeared to be mentally challenged I would warn him of the danger, recommend having a professional do the work, and then provide the step by step instructions. If he did appear to be mentally challenged I would tell him not to try it and warn whoever is responsible for him of his intentions.
Yes, I would feel bad if he managed to get electrocuted but at the risk of seeming callous I would have to consider that "chlorine for the gene pool".
"that is dangerous ____________ can occur, don't do."
sadly one did not listen and sent himself to the ER when he asked how do you fix a TV tube and I told him
"Don't even try the capacitors can hold voltages and provide a huge shock."
he did and his wife had to call for an ambulance.
I got close to doing that a few weeks ago ..............
-Phil
Do we need to get Matt and Ken to offer an Easy Bake Oven as a contest prize...
C.W.
untill I made a new form of carbon that Mr Bucky would be proud of ...
I have spend a good part of my career working under such regimes. Usually in military and aerospace fields. When software is built by large teams, really has to work and really have to outlive the puny careers and whims of individual programmers you will find that is common practice.
As almost a joke, my project manager on the Boeing 777 Primary Flight Computer project printed out the requirement specification document. It was a stack of paper a meter and a half high. That's before we get to the actual architecture, design and detail design specs of the software to be written. Or the millions of test case that need to be documented, and approved.
I'm sure you will be much more comfortable when flying in a 777 knowing that we took the trouble to do all of that. Rather than just having the code thrown together by some software pre-madonna with nobody else in the world knowing what he has put in there.
In general if anyone is investing their money in employing you to produce code and all you return is a binary blob and perhaps source then you are not a good investment.
Why do software engineers (if the term "engineer" is applicable to most of them) feel they are some how different from engineers in electronics, building construction, bridge design, avionics, etc etc where a great deal of documentation and traceability is often required?
I was going to say, too, that it is not as easy to give away knowledge as you might think. In a previous job, I did everything I could do to try to explain a particular MODEM design to my intended replacements. But I found it impossible. They simply lacked the foundational knowledge. Meanwhile I didn't have the time to teach courses they'd missed in their education. Eventually it became clear that there was a reason they had never taken those courses, if you know what I mean.
Since you posed the question....
Somebody said manufacturing physical items is probabilistic (holes are here within a tolerance), while manufacturing software is deterministic (every copy of the final software will be exactly identical). So the tools and methods for data collection and analysis of manufacturing physical items do not make sense when directly transferred to the realm of software.
On the other hand, the design and development process for software (rather than the reproduction of the final image) CAN be approached with similar methods. This is the big deal. It allows us to use data to mature the design process just as other sections mature the manufacturing process. This is a new concept to many old geezers in software, and it scares the poop out of them. Any scrutiny or suggestion of "do differently" is taken as an offense or insult.
In non regulated industries, there is a perception that if we work too fast, or skip steps, or get the Smile out the door before its finished, that we are somehow helping the company, because we can collect the money one day sooner. In fact, the exact opposite is true, it is nearly always damaging, due to bugs, rework, bad customer feeling, lost sales, etc. Even if you show folks how nuts this behavior is, the response is usually some nonsense about "we have to do this because of the business realities". Text book insane.
For the most part, only industries where scrutiny of process is required by government regulation do software engineers and management learn to use process in a mature or mature-able fashion, such as aviation, medical, nuclear. Even in these industries, it takes years to teach folks (particularly management) that process analysis is not there to hurt them but to protect them. If we follow our process, we can't get in trouble, because we can find errors and correct them; if we don't follow process, or have a nonsense process, or falsify records, we always get in trouble or somebody gets hurt or we go to jail, when something eventually goes wrong.
But this whole concept is still too new, and will not become common place for quite some time.
We are talking about two different things here. I would never consider starting a hardware/software design without a clear specification or presenting a finished product to a customer or employer without adequate testing and documentation. The previous post was a comment on the idea of documenting the steps required to design and create the hardware/software in enough detail that someone else could use that to do the same.
http://www.ted.com/talks/yves_rossy_fly_with_the_jetman.html
He said his goal was to share the knowledge with a "younger person" teach and learn to fly in formation, and get it "to everyone".
This as an example of one person being the only person on the planet with this knowledge, and find it interesting the sharing is the goal.