4 added 8 characters in body
source | link

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experienceOne single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedicationabsolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

3 deleted 28 characters in body
source | link

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, innate talent (yeah right), practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, innate talent (yeah right), practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

2 added 3502 characters in body
source | link

Watch this spaceSo you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, I'mmindfulness, maths, passion, innate talent (yeah right), practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think aboutyou need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an answeroperator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Come back Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in halfthe system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an houropen mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or sixmore to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

Watch this space, I'm think about an answer... Come back in half an hour or six.

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, innate talent (yeah right), practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

1
source | link