This really resonates with the way I struggle towards academic writing. I see my friends who can put together their ideas in a very elegant manner in no time. The words just flow for them. But for me, I absolutely need a dedicated block of time and iterations to get to a professional piece of text. At times I only manage to complete a paragraph after spending more than an hour.
I can definitely see where the difference comes from. I was not exposed to formal writing during high school or even undergraduate studies. Being able to communicate the ideas in writing was never rewarded or seen as a skill. So, I need to put in this extra time now to polish my writing every now and then.
Mattsays:
This really resonates, thanks for writing it down! I feel the same way: I am more confident also now that I am older that going slow and ruminating on ideas is even just a better idea for long-term efficiency (I’m doing IT/coding, for reference). There is usually so much peer pressure for doing things fast and the collateral damage seems so obvious but few people either recognize or have the will to slow things down and fix the process.
One of the biggest things that helped me was, when asked the question “do you understand this?” was to answer “No.” But a confident “No,” not an ashamed one. And repeatedly doing so after having things explained. It usually confused people because when they probe me, I can usually answer their questions, but I have come to realize that I usually have different personal criteria for what it means for me to understand something. And it helps to be open and confident in my non-understanding, both with myself and with the people I work with. It usually leads to better understand for everybody (I hope).
Dennis Decker Jensensays:
The title of your post alludes to this citation:
Elegance is not a dispensable luxury but a quality that decides
between success and failure.
— Edsger W. Dijkstra
I am reminded how I used to, and to a large degree still work out things and thinking things through on paper before even making a program text: A consequence of not having a computer for the first nearly four years after I begun learning about computers and programming. Imagine my surprise when I learned that the programs actually worked with only minor adjustments due to my incomplete understanding! All your points resonate with me: checking assumptions; working slowly; localize parts of a larger problem; and consider alternatives on several levels.
Adam G.says:
This is also a weak point of coding interviews. They only look for quick, clever answers, rather than thought-out, deep answers. Having worked at a (large) software company, no one ever asked me, “Quick, I need a solution to this problem in the next 2 minutes!” The best coders were the ones who would take the time to think out a thorough solution.
AYMEN BENsays:
As a young student I face this issue on a daily basis. I look around me and everyone’s concern seems like “How to get the “right” answer, How to make sure the approach produces same answers as the test cases…”
I consider myself slow compared to other students… But when reading your post I saw myself doing the steps that you describe. I spend too much time (compared to other students) trying to think of every possible way of solving a problem when everyone has already gone through implementations.
This is a GREAT post! It’s always a pleasure to learn from you.
Jeansays:
Bah! Others would call that “experience”, and the more cynical: aging! I often remind my students that methodology is hard to master, as it is generally so unpleasant and counterintuitive a way of working on a problem (mathematical, logical or philosiophical). And with experience and methodology, comes patience. Only ignorants always try to learn fast, as if knowledge was an easy thing to catch, not to mention to discover!
Davidesays:
Thanks for writing this very nice post.
It makes me feel better about being “the slow one” when everyone on the team is trying to be fast and rushing to get the result.
And then discovering that there were N important mistakes and relevant bugs.
Although with some differences, your post reminds me of “the curse of the gifted” described by E.S. Raymond, available for example here http://lwn.net/2000/0824/a/esr-sharing.php3
This really resonates with the way I struggle towards academic writing. I see my friends who can put together their ideas in a very elegant manner in no time. The words just flow for them. But for me, I absolutely need a dedicated block of time and iterations to get to a professional piece of text. At times I only manage to complete a paragraph after spending more than an hour.
I can definitely see where the difference comes from. I was not exposed to formal writing during high school or even undergraduate studies. Being able to communicate the ideas in writing was never rewarded or seen as a skill. So, I need to put in this extra time now to polish my writing every now and then.
This really resonates, thanks for writing it down! I feel the same way: I am more confident also now that I am older that going slow and ruminating on ideas is even just a better idea for long-term efficiency (I’m doing IT/coding, for reference). There is usually so much peer pressure for doing things fast and the collateral damage seems so obvious but few people either recognize or have the will to slow things down and fix the process.
One of the biggest things that helped me was, when asked the question “do you understand this?” was to answer “No.” But a confident “No,” not an ashamed one. And repeatedly doing so after having things explained. It usually confused people because when they probe me, I can usually answer their questions, but I have come to realize that I usually have different personal criteria for what it means for me to understand something. And it helps to be open and confident in my non-understanding, both with myself and with the people I work with. It usually leads to better understand for everybody (I hope).
The title of your post alludes to this citation:
Elegance is not a dispensable luxury but a quality that decides
between success and failure.
— Edsger W. Dijkstra
I am reminded how I used to, and to a large degree still work out things and thinking things through on paper before even making a program text: A consequence of not having a computer for the first nearly four years after I begun learning about computers and programming. Imagine my surprise when I learned that the programs actually worked with only minor adjustments due to my incomplete understanding! All your points resonate with me: checking assumptions; working slowly; localize parts of a larger problem; and consider alternatives on several levels.
This is also a weak point of coding interviews. They only look for quick, clever answers, rather than thought-out, deep answers. Having worked at a (large) software company, no one ever asked me, “Quick, I need a solution to this problem in the next 2 minutes!” The best coders were the ones who would take the time to think out a thorough solution.
As a young student I face this issue on a daily basis. I look around me and everyone’s concern seems like “How to get the “right” answer, How to make sure the approach produces same answers as the test cases…”
I consider myself slow compared to other students… But when reading your post I saw myself doing the steps that you describe. I spend too much time (compared to other students) trying to think of every possible way of solving a problem when everyone has already gone through implementations.
This is a GREAT post! It’s always a pleasure to learn from you.
Bah! Others would call that “experience”, and the more cynical: aging! I often remind my students that methodology is hard to master, as it is generally so unpleasant and counterintuitive a way of working on a problem (mathematical, logical or philosiophical). And with experience and methodology, comes patience. Only ignorants always try to learn fast, as if knowledge was an easy thing to catch, not to mention to discover!
Thanks for writing this very nice post.
It makes me feel better about being “the slow one” when everyone on the team is trying to be fast and rushing to get the result.
And then discovering that there were N important mistakes and relevant bugs.
Although with some differences, your post reminds me of “the curse of the gifted” described by E.S. Raymond, available for example here
http://lwn.net/2000/0824/a/esr-sharing.php3