I don't entirely agree with this article, but I do understand its merits.
When I was really young, around 8, I didn't have books, TV, and the internet wasn't around. I spent much of my time thinking about computers because I saw them once and was fascinated by them. One of the thoughts I had was about multi-socket computers. How did the two CPUs communicate and run in the same system.
I eventually came up with the concept of race conditions, but I had no word for this concept, but I could see it in my mind's eye. I eventually thought of different ways to work around race conditions by making certain assumptions.
Nearly 2 decades later I was in my first job when a CPU bound problem showed up and I quickly slapped together some multithreaded code that worked the first time and was not only the first time I ever wrote multithreaded code, but was also my first real world programming project. I hand rolled a lockless queue. It was messy, it had some redundancies, but what I wrote was based on the concepts that I thought about when I was 8 years old.
It was at this point that I decided to look into my concerns about "data access ordering multithreading" and learned about the term "race conditions".
Of course learning this term opened up my mind, furthering my understanding of the concept both in communications and in more concrete concepts than the abstract blurs in my mind.
I actually deal with unknown unknowns all of the time. When I envision a problem in my head, I tend to focus on guarantees. I enumerate assumptions that my designs require, and if I can't prove to myself that I can guarantee that assumption, then it is now a known unknown.
I have a track record at my work of finding corner cases. I do this entirely by my "guarantee" approach. If I can't guarantee something, can I think of a proof of concept that could cause the assumption to be violated. This also works well for multi-threading. I don't need to worry about thinking about a problem in a serial fashion, I only have to think about "in order for this to work, what assumptions do I have to make and can I prove those assumptions."
It's quite often that I learn about new concepts by describing an assumption that I can't guarantee, and I will find an existing answer or solution.
I've reflected on my obsession with correctness. I've found my issue is my ADD. If I can't prove something can't happen, my mind will wander uncontrollably thinking of what might go wrong. In order to cull these distracting rabbit trail thoughts, I have to prove to myself that no issue can occur.
This approach works well enough that I've had large complex mulithreaded projects where the process deadlocked several times. When the problem got priority and my team lead asked me if I had any ideas, I told him "I read thought my code, it must be .Net framework". He thought I was joking at first. Three times in a row, non-reproducible deadlocks that rarely occurred, I diagnosed as "not my code", and 3 times I was correct.
Not only does this process seem to work well for me, but I've also used it with other's who were stuck pair programming a bug that they couldn't figure out. I can generally just start asking questions and eventually the programmers figure it out on their own.
I think if more people focused on guarantees, there would be fewer issues.
Where was I? Oh yeah. If you can't guarantee something and you can't figure out why, then there must exist an unknown. You don't need to know what this is in order to know it exists. Having a word for it helps tremendously, but it is not required in order to reason about it.
.. I don't think you're disagreeing with me at all.
I agree with this: "You don't need to know what this is in order to know it exists. Having a word for it helps tremendously, but it is not required in order to reason about it."
When I was really young, around 8, I didn't have books, TV, and the internet wasn't around. I spent much of my time thinking about computers because I saw them once and was fascinated by them. One of the thoughts I had was about multi-socket computers. How did the two CPUs communicate and run in the same system.
I eventually came up with the concept of race conditions, but I had no word for this concept, but I could see it in my mind's eye. I eventually thought of different ways to work around race conditions by making certain assumptions.
Nearly 2 decades later I was in my first job when a CPU bound problem showed up and I quickly slapped together some multithreaded code that worked the first time and was not only the first time I ever wrote multithreaded code, but was also my first real world programming project. I hand rolled a lockless queue. It was messy, it had some redundancies, but what I wrote was based on the concepts that I thought about when I was 8 years old.
It was at this point that I decided to look into my concerns about "data access ordering multithreading" and learned about the term "race conditions".
Of course learning this term opened up my mind, furthering my understanding of the concept both in communications and in more concrete concepts than the abstract blurs in my mind.
I actually deal with unknown unknowns all of the time. When I envision a problem in my head, I tend to focus on guarantees. I enumerate assumptions that my designs require, and if I can't prove to myself that I can guarantee that assumption, then it is now a known unknown.
I have a track record at my work of finding corner cases. I do this entirely by my "guarantee" approach. If I can't guarantee something, can I think of a proof of concept that could cause the assumption to be violated. This also works well for multi-threading. I don't need to worry about thinking about a problem in a serial fashion, I only have to think about "in order for this to work, what assumptions do I have to make and can I prove those assumptions."
It's quite often that I learn about new concepts by describing an assumption that I can't guarantee, and I will find an existing answer or solution.
I've reflected on my obsession with correctness. I've found my issue is my ADD. If I can't prove something can't happen, my mind will wander uncontrollably thinking of what might go wrong. In order to cull these distracting rabbit trail thoughts, I have to prove to myself that no issue can occur.
This approach works well enough that I've had large complex mulithreaded projects where the process deadlocked several times. When the problem got priority and my team lead asked me if I had any ideas, I told him "I read thought my code, it must be .Net framework". He thought I was joking at first. Three times in a row, non-reproducible deadlocks that rarely occurred, I diagnosed as "not my code", and 3 times I was correct.
Not only does this process seem to work well for me, but I've also used it with other's who were stuck pair programming a bug that they couldn't figure out. I can generally just start asking questions and eventually the programmers figure it out on their own.
I think if more people focused on guarantees, there would be fewer issues.
Where was I? Oh yeah. If you can't guarantee something and you can't figure out why, then there must exist an unknown. You don't need to know what this is in order to know it exists. Having a word for it helps tremendously, but it is not required in order to reason about it.