in reply to Re: Re: Initiative or otherwise?
in thread Initiative or otherwise?
I think that while programming is a science, a good programmer is more artist than scientist. Knowledge in and of itself is fairly useless. It's the application of it that yields the rewards, the craftsmanship if you will.
I don't think that knowing that something works is the same thing as why it works. You can't understand why the design was done the way it was or if it's an optimal solution or even if it will work in the "real world" application.
I truly belive you learn more from your failures than your successes. Sometimes the "B" approach is totally appropriate though "A" types, with their overall knowledge of the subject will (eventually) be in a much better position to leverage the "B" approach effectively than the "B" types (Also know when not to). Knowing how the pieces fit together, how they might not often without doing any actually work.
This very much reminds me of several recent events in my life, that while not in the programming field bear much resemblance in my mind. I'll tell you one.
Example 1. A registered nurse goes to a hospital with pains in her gallbladder. She sees this everyday so she is very familiar with the presentation of it. Many hospitals in Boston are teaching hospitals so you get a lot of "B" care. Interns don't have much practical experience. Mostly what they "learned" by reading. Hospital 1 says it can't be a gallbladder problem because so and so enzyme isn't elavated. She goes to another, and another and another. All of the hospitals refuse to remove it due to what they "learned". Finally, the fifth hostpital (a non-teaching) takes her and her gallbladder disintigrates as they remove it because it is so badly infected. Due to the delay because of hospitals 1..4 she gets complications and has liver failure. Luckily this ended well. While most of us are not in such dire positions of responsibility (mostly time and money to lose) I think it does well to illustrate my point.
As an aside, I never did the examples in the back of the books.
-Lee
"To be civilized is to deny one's nature."
I don't think that knowing that something works is the same thing as why it works. You can't understand why the design was done the way it was or if it's an optimal solution or even if it will work in the "real world" application.
I truly belive you learn more from your failures than your successes. Sometimes the "B" approach is totally appropriate though "A" types, with their overall knowledge of the subject will (eventually) be in a much better position to leverage the "B" approach effectively than the "B" types (Also know when not to). Knowing how the pieces fit together, how they might not often without doing any actually work.
This very much reminds me of several recent events in my life, that while not in the programming field bear much resemblance in my mind. I'll tell you one.
Example 1. A registered nurse goes to a hospital with pains in her gallbladder. She sees this everyday so she is very familiar with the presentation of it. Many hospitals in Boston are teaching hospitals so you get a lot of "B" care. Interns don't have much practical experience. Mostly what they "learned" by reading. Hospital 1 says it can't be a gallbladder problem because so and so enzyme isn't elavated. She goes to another, and another and another. All of the hospitals refuse to remove it due to what they "learned". Finally, the fifth hostpital (a non-teaching) takes her and her gallbladder disintigrates as they remove it because it is so badly infected. Due to the delay because of hospitals 1..4 she gets complications and has liver failure. Luckily this ended well. While most of us are not in such dire positions of responsibility (mostly time and money to lose) I think it does well to illustrate my point.
As an aside, I never did the examples in the back of the books.
-Lee
"To be civilized is to deny one's nature."
|
|---|
In Section
Meditations