I remember reading about an ultra-low power wifi antenna that uses incoming wifi signals and "reflects" those signals back at the sender, but somehow manipulates the reflected signal to carry data. This reduced power required by the transmitter by some large fraction. This is the only reasonable explanation I can think of because remote battery charging is not efficient at all, but this signal reflection claimed to be very efficient.
I'm not in favor of working on other projects when on the clock for someone else, but it is a very normal thing to take many breaks for any intellectual job. The brain necessitates it. You literally cannot learn anything new while your working memory is consumed by what you've been thinking about. You must take time to forget in order to learn. You do most of your learning when your working memory is empty.
An apprentice under a master is a good way for someone to learn. The problem is there are almost no masters and way too many cargo-cult programmers in the industry that will be passing on their superstitious religion of how they think programming works. A master knows when not to use best practices. A master should be confident enough in their abilities that they can safely ignore the warnings of other masters, but obviously wise enough to know when to take good advice. Or as one master said(paraphrased) ~"If I tell you to not ever do something and you always listen to what I say, you are not a master". Or another one who said ~"A master knows when to use an anti-pattern". According to psychology, a master can synthesize knowledge without having to remember it; Thinking is all that is required. This is also almost exactly the definition of abstract reasoning.
My biggest gripe about how most other programmers "teach" is they want you to memorize everything because that's what they do. No better than a good hands-on technical college. What people need is more theory and practical application of theory.
Only mediocrity can be trusted to be always at its best.
Mediocrity at best breeds more mediocrity, but a master can better themselves.
And don't confuse expertise for mastery. An expert may spend a lifetime honing a skill to deliver mediocrity of a consistent quality. A master will intuitively understand new problems with no time spent. Expertise is dependent on knowledge and experience, mastery is not. One may master without being an expert, but master do tend to be experts.
Someone smarter than someone else could flood the other person's brain. Doesn't even need to be overall intelligence, just in whatever part is creating the thoughts. What if I'm thinking about an n-dimensional problem where n is much greater than 3, and I try to transmit this idea to someone else? This is excluding my A.D.D.. Sometimes I think so fast I almost blackout. Many concurrent thoughts traversing many different paths, trying to solve a difficult problem.
I recognize that the rate and quality of ideas transference is highly limited by traditional communication methods, but there is always going to be some amount of "[lossy] compression" going on unless two brains are identical.
Fearing concurrency is irrational. Difficult to reason about concurrency when you're in an irrational state of mind. The ability to quickly debug concurrency issues separates cargo-cult from programmers, because understanding concurrency requires understanding of the code. I will agree that working in poorly designed concurrent code is a major headache.
No, just under-performing. I am one of those that does not write any code before thinking about the problem. I may go weeks without even opening a prorgamming tool. Just staring blankly at my computer, thinking. For any slightly complex project, I am about 10 faster, ignoring my reduced number of bugs and higher performance.
A more recent projects was one that I had already done in the past. I spent about two weeks working on it. Around 4 days thinking and 6 days coding and testing. It was a high performance async concurrent library that could be easily reused and extended. Extending required little knowledge of concurrency as I wanted the library to be easy to use for any programmer.
Another project came along about a year later that would have been a 100% perfect fit for my library. I could have had the project completed in 1-2 days. Instead management decided to give the project to some senior programmers, because the project was of "high priority". It was a two man team. They came to me for guidance because they were aware that I have worked on this kind of stuff before. I spent about 3-4 weeks in meetings with them, then it took about 5 months for them to complete it. In the end, there was no tests, because they didn't have time, the code was brittle, was slow, everything was hard-coded. Small requests for change would take days, where in my system, everything was just a configuration, so they changes would have taken minutes with my library.
I got to look at their code in git. It's crazy simplistic. Loads tens of gigabytes of data into memory instead of streaming it, among other horrors. Looking at git, I could see they started coding the day they got the project.
For all non-social or coding aspects of programming, abstract reasoning is universally considered the single most important ability. Yet this ability allows one to solve problems with zero prior knowledge. It is by definitive the ability to recognize a new problem and solve it with no prior knowledge of anything. Knowledge is virtually useless for anyone with decent abstract reasoning. If anything, knowledge is a hindrance that makes it more difficult to learn because accessing knowledge is mentally expensive.
You make a clean discretion between "text book" knowledge and the ability to use knowledge, but the same ability that allows you to use knowledge also makes knowledge moot. There are people who can "use" knowledge but have weak abstract reasoning, but they also have the problem of not knowing when to NOT use their knowledge. This is dangerous. Behold, the golden hammer. The only way these people learn is from making mistakes over very long periods of time and the luck of happen-stance allows them to realize their error.
This is why there is virtually zero correlation between experience and ability in the tech industry. People with knowledge are useful as reference books.
Another related topic is about forgetting. Turns out forgetting is an important part of learning. The brain regularly needs to make room. Research seems to be leaning towards the inability of older people being able to learn and reason seems to be highly correlated with how much knowledge they have. Being able to quickly learn and quickly forget is important. Abstract reasoning allows for quick learning. They even say abstract reasoning peaks in your teens, for a normal person. After that, they assume people start to rely more on their knowledge, allowing their abstract reasoning to atrophy.
Knowledge seems inversely related to understanding./sarc
But really. In psychology, it is known that accessing memory while attempting to learn hampers your ability to learn. Internalizing a concept such that you no longer need to access memory, but instead "just think that way" frees up your memory. A typical person can only hold a hand full of concepts in their head at once. If you're dealing with a complex system, memorizing it is incredibly inefficient. Learning to think like the system allows you to effectively hold it all in your head without having to use your memory.
Like Minecraft, if you instead algorithmically generate your "memories" you can free up your actual memory. Minecraft manages to compress an entire map down to a small seed and only has to store the differences. This is how you deal with large complex system.
I literally have a memory disability, but I can manage hugely complex systems in my head by designing the system using simple patterns and making sure the patterns can express the complexity of the system. Like a fractal. I compensate for my disability by "regenerating" my memory in real time. I have difficulty telling the difference between something I just thought of or something that I remembered because thinking is nearly the same as remembering for me.
This breaks down outside of logical systems. Day-to-day activities give me issues. Sometimes I forget my own birthday. It took me nearly 6 months to remember my wife's name while we were dating, and I saw her almost every day. I had to give her a pet name. At first she didn't like it, but it grew on her. Most people who meet me think I'm fairly normal but slightly dunce. That is until they get me working on something that requires abstract reasoning.
I think anyone could do what I do, but I take a much longer time getting up to speed because it takes time for me to internalize a concept into my way of thinking. But once I integrate a concept, I no longer have to remember anything about it, it become natural for me to think that way. I am forced to do this because of my disability, but if people were not in such a hurry to crank out some code, they to could free up their limited memory for other more important things, like learning.
I don't know most terms myself. I typically self discover nearly everything that I know by thinking about a problem for a little bit. I didn't know the term "race condition" when I was 8 years old when I theorized they would be an issue within a few minutes of learning that multi-core CPUs exist. I've been using "tiling" for years to optimize memory access without knowing what it was called. These things just seem blindly obvious when you see the problem.
I wouldn't say you have to specialize. It would just mean you need to spend more of your time researching. In general, I find I can catch up to almost any specialist within a month, but that's a month of no production, just learning. That is a lot of down time. On the flip side, most projects that we have take 6 months to a year, and spending 1 month of it researching to catch up to what a specialist spent a life-time specializing is probably acceptable.
It really comes down to the size of your project. If it's really small and needs to be done quickly (less than several months) and well, go with a specialist.
I think you're a bit off. The faster a rocket goes, the more thrust it produces, not to mention that as the rocket burns through its fuel, it gets lighter.
For performance you don't predict. Experiments are the only thing you have that work
In my experience, I am better at predicting performance than synthetic tests. In many cases, intuition out-ranks empirical evidence because some things are impossible to directly measure, only theory works.
The "Clean Code" guy makes a lot of extremist devil's advocate assertions with the intention of making your think about clean code in a purist way. Of course it is up to you, the reader, to apply his wisdom in a practical manner. His most useful chapters are about code smells. They are the most practical. Kind of "If you see this, stop and think about why, and if it should be done this way or is there a cleaner way".
Sometimes you can even get away with just knowing how the code should NOT work to fix a bug.
I wish I was so lucky. When ever I have to deal with other software engineers, they only define the overly simplistic happy paths. Failure paths? What are those? That really grinds my gears. I always rub their nose in it when I ask them if that is how it should work, only to find out they did not think of that situation. I just tell them it is undefined, so it is not a bug. "Fixing" the situation is now a feature request.
I should refine my statement. "You cannot know how your code does not work until you know how it is supposed to work, and you cannot know how your code is supposed to work until you know how it should not work." I work with very complex multi-threaded code. Every bug that I have not been able to explain has been a result of a bug in the framework or library that I used. I make sure my code has well defined failure paths and guaranteed state transitions handled by single points of responsibility.
Particularly when debugging legacy code where knowing how it works is not all that realistic.
I actually get pulled into helping people debug their code when I don't even have access to the code. I find the quickest way is to just keep asking "what all is responsible for handling this and how are they meant to work". Even when working at an abstract level, I can help them find the issue quickly with the above approach. And it always makes for a good time to slip in "imaging how much easier this would be if you only had to look in one place". SOLID is your friend.
Some times I don't even get the advantage of someone to ask, seeing the code, or knowing the architecture. Everything that I know is just what the customer reports and I have to infer the rest and make lots of educated guesses. And I still mange to figure out the problem faster than the ones who wrote it. But I've always had a strong intuition when it comes to computers. My co-worker is very intelligent, but he has little intuition. He has a math background and can quickly implement nearly any algorithm or protocol by reading an RFC. He needs empirical data. The problem is a lot of the hard issues we deal with, you only get to see the symptoms, which means all of your empirical data is not about the cause, but the effects created. Many times if you read too far into the data, it will send you in the wrong direction.
I always strive to have a theory why something works the way it does. If my theory does not match, I try to create predictions with my theory and see if the are true. My co-worker doesn't really have a theory, he just has a bunch of data and reads it too literally. The thing is, I cannot argue against his logic, he has flawless logic, what I argue against are the hidden variables that cannot be directly measured. My theories predict these and make clean predictions. He has learned to humor me with my thoughts.
A simple example is perhaps he looks at the memory profiler and sees some objects getting promoted to Gen2 and causing lots of GC. Then I argue that in theory, those objects should be used momentarily and the root issue is something is blocking the release of those objects. Look around, and see a stack variable that references those objects well past when they're needed, but the resulting work caused by those objects is taking some time, keeping the stack reference in scope. Just null the stack reference to the objects after they're needed, and the problem goes away.
You know that you're going to throw away most of the code. Most people don't see a prototype meant as a learning experience, they instead see "working" code. All working code is equal in their mind. Except they don't actually know how it works, it only seemingly works. You can tell they don't know how it works when something finally goes wrong and they can't even guess as to why it's not working.
One of my rules of thumb is "You can't know why your code doesn't work unless you first know how it works.". 80%+ of the time, in the rare case that someone finds a bug in my code, I can typically tell them where the bug is and under which situations it will occur without ever looking at the code or using a debugger. I can many times do the same thing to other's people code for which I have never seen. I can infer much of how their program is designed based on how the characteristics of the bug. I purposefully try to write well-factored code with single-responsibility to make it easy for me to reason about. When I get dragged into helping someone debug their code because they're lost in their own maze.
Many times I've had programmers tell me they think there is a bug in.Net or SQL because their program is not working correctly. They can't even understand their own code, why are they so willing to blame someone else's?
0.999... = I (I = 1)
IV = 4 (1*4 = 4) (V = 4)
V = 4/I (4 = 4/1)
V = IR (4 = 1 * R) (R = 4)
I = V/R (1 = 4/4)
V = 4R/V (4 = 4*4/4)
R = V^2/4 (4 = 4^2/4)
but V = 5 (WRONG, it was defined as 4 by the second line)
But "Mr.Z of the LotFC" points out "IV=4 & V=5 as Roman numerals (as is 0.999...=I)...the derivation appears to be a math pun of sorts."
Do Lots of Deliberate Practice... "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."
The quote about deliberate practice is taken out of context.
1) It is said it typically takes 10,000 of deliberate practice to become "elite", but it can take as few as 100 hours for those "naturally" good at something
2) This mostly applies to professions where practice matters, like playing an instrument. As a profession becomes less about muscle memory and more about thinking, practice becomes less useful.
Becoming an elite in a purely intellectual profession can require virtually zero practice. Some people are able to learn by thinking. They can reason through to the conclusion without having to actually practice/experience. Of course nothing is purely intellectual. Even with programming, we have to deal with other humans and need to deal with the fact that we are also human and can make mistakes. You must learn to write clear and defensive code, and be able to communicate with others.
Rule of thumb, don't write any code until you understand the problem and have thought of a good solution. If you were wrong at any point, figure out what was wrong with your reasoning that lead to the mistake and don't make that same logical mistake again. It really comes down to having strong fluid intelligence. This is how someone realizes what they don't know and if what they do know will work for the situation at hand. If you suffer from Dunning–Kruger effect, have a golden hammer, or don't realize you're doing something wrong, you probably need to exercising your fluid intelligence.
There is absolutely ZERO expectation of privacy when using an asset that is provided by your employer.
Is that so? The only way I can access some of my medical information is via my work computer. Are you saying I have zero expectations of privacy to access my private medical data? I'm sure my company is not the only one that has many benefits that are only accessible via intranet services. IT has no right viewing any of that data.
Same thing with math. We can only use math to prove math. At some point we have to assume something without proof in order for everything to work. All science has a bootstrap issue. Time may not exist in the way we think it does, but we're pretty sure it is real.
They're at least 1 cubic plank-length. Not to mention the notion of a true singularity is probably wrong. There's a lot of magic hand-waving to think of a blackhole as a true singularity. Some how the blackhole can grow, yet nothing can fall past the event horizon in any frame of reference, and all of the information is at the "center"? What? How does the information get to the center if by definition it can not?
The more recent idea that a blackhole is just the highest density of information with the information being stored on the surface, just above the theoretical event horizon, is much simpler and agrees or at least does not create a bunch of paradoxes.
Learn to read. I never said there's a 15 gigawatt energy gradient, I just said there's 15 gigawatts of energy moving around in the form of IR. Just because there is not a gradient doesn't mean we're not being bathed in it.
The high voltage power lines are not just dumping ozone into the air, the air is acting like an electrolytic solution. The ozone "disperses" into the air like metallic dust "disperse" in a magnetic field.
Slashdot Mirror
I remember reading about an ultra-low power wifi antenna that uses incoming wifi signals and "reflects" those signals back at the sender, but somehow manipulates the reflected signal to carry data. This reduced power required by the transmitter by some large fraction. This is the only reasonable explanation I can think of because remote battery charging is not efficient at all, but this signal reflection claimed to be very efficient.
I'm not in favor of working on other projects when on the clock for someone else, but it is a very normal thing to take many breaks for any intellectual job. The brain necessitates it. You literally cannot learn anything new while your working memory is consumed by what you've been thinking about. You must take time to forget in order to learn. You do most of your learning when your working memory is empty.
My biggest gripe about how most other programmers "teach" is they want you to memorize everything because that's what they do. No better than a good hands-on technical college. What people need is more theory and practical application of theory.
Only mediocrity can be trusted to be always at its best.
Mediocrity at best breeds more mediocrity, but a master can better themselves.
And don't confuse expertise for mastery. An expert may spend a lifetime honing a skill to deliver mediocrity of a consistent quality. A master will intuitively understand new problems with no time spent. Expertise is dependent on knowledge and experience, mastery is not. One may master without being an expert, but master do tend to be experts.
Someone smarter than someone else could flood the other person's brain. Doesn't even need to be overall intelligence, just in whatever part is creating the thoughts. What if I'm thinking about an n-dimensional problem where n is much greater than 3, and I try to transmit this idea to someone else? This is excluding my A.D.D.. Sometimes I think so fast I almost blackout. Many concurrent thoughts traversing many different paths, trying to solve a difficult problem.
I recognize that the rate and quality of ideas transference is highly limited by traditional communication methods, but there is always going to be some amount of "[lossy] compression" going on unless two brains are identical.
Fearing concurrency is irrational. Difficult to reason about concurrency when you're in an irrational state of mind. The ability to quickly debug concurrency issues separates cargo-cult from programmers, because understanding concurrency requires understanding of the code. I will agree that working in poorly designed concurrent code is a major headache.
No, just under-performing. I am one of those that does not write any code before thinking about the problem. I may go weeks without even opening a prorgamming tool. Just staring blankly at my computer, thinking. For any slightly complex project, I am about 10 faster, ignoring my reduced number of bugs and higher performance.
A more recent projects was one that I had already done in the past. I spent about two weeks working on it. Around 4 days thinking and 6 days coding and testing. It was a high performance async concurrent library that could be easily reused and extended. Extending required little knowledge of concurrency as I wanted the library to be easy to use for any programmer.
Another project came along about a year later that would have been a 100% perfect fit for my library. I could have had the project completed in 1-2 days. Instead management decided to give the project to some senior programmers, because the project was of "high priority". It was a two man team. They came to me for guidance because they were aware that I have worked on this kind of stuff before. I spent about 3-4 weeks in meetings with them, then it took about 5 months for them to complete it. In the end, there was no tests, because they didn't have time, the code was brittle, was slow, everything was hard-coded. Small requests for change would take days, where in my system, everything was just a configuration, so they changes would have taken minutes with my library.
I got to look at their code in git. It's crazy simplistic. Loads tens of gigabytes of data into memory instead of streaming it, among other horrors. Looking at git, I could see they started coding the day they got the project.
Not on the whole, but a select few greatly profit.
For all non-social or coding aspects of programming, abstract reasoning is universally considered the single most important ability. Yet this ability allows one to solve problems with zero prior knowledge. It is by definitive the ability to recognize a new problem and solve it with no prior knowledge of anything. Knowledge is virtually useless for anyone with decent abstract reasoning. If anything, knowledge is a hindrance that makes it more difficult to learn because accessing knowledge is mentally expensive.
You make a clean discretion between "text book" knowledge and the ability to use knowledge, but the same ability that allows you to use knowledge also makes knowledge moot. There are people who can "use" knowledge but have weak abstract reasoning, but they also have the problem of not knowing when to NOT use their knowledge. This is dangerous. Behold, the golden hammer. The only way these people learn is from making mistakes over very long periods of time and the luck of happen-stance allows them to realize their error.
This is why there is virtually zero correlation between experience and ability in the tech industry. People with knowledge are useful as reference books.
Another related topic is about forgetting. Turns out forgetting is an important part of learning. The brain regularly needs to make room. Research seems to be leaning towards the inability of older people being able to learn and reason seems to be highly correlated with how much knowledge they have. Being able to quickly learn and quickly forget is important. Abstract reasoning allows for quick learning. They even say abstract reasoning peaks in your teens, for a normal person. After that, they assume people start to rely more on their knowledge, allowing their abstract reasoning to atrophy.
Knowledge seems inversely related to understanding. /sarc
But really. In psychology, it is known that accessing memory while attempting to learn hampers your ability to learn. Internalizing a concept such that you no longer need to access memory, but instead "just think that way" frees up your memory. A typical person can only hold a hand full of concepts in their head at once. If you're dealing with a complex system, memorizing it is incredibly inefficient. Learning to think like the system allows you to effectively hold it all in your head without having to use your memory.
Like Minecraft, if you instead algorithmically generate your "memories" you can free up your actual memory. Minecraft manages to compress an entire map down to a small seed and only has to store the differences. This is how you deal with large complex system.
I literally have a memory disability, but I can manage hugely complex systems in my head by designing the system using simple patterns and making sure the patterns can express the complexity of the system. Like a fractal. I compensate for my disability by "regenerating" my memory in real time. I have difficulty telling the difference between something I just thought of or something that I remembered because thinking is nearly the same as remembering for me.
This breaks down outside of logical systems. Day-to-day activities give me issues. Sometimes I forget my own birthday. It took me nearly 6 months to remember my wife's name while we were dating, and I saw her almost every day. I had to give her a pet name. At first she didn't like it, but it grew on her. Most people who meet me think I'm fairly normal but slightly dunce. That is until they get me working on something that requires abstract reasoning.
I think anyone could do what I do, but I take a much longer time getting up to speed because it takes time for me to internalize a concept into my way of thinking. But once I integrate a concept, I no longer have to remember anything about it, it become natural for me to think that way. I am forced to do this because of my disability, but if people were not in such a hurry to crank out some code, they to could free up their limited memory for other more important things, like learning.
"Tell me what a class invariant is."
I don't know most terms myself. I typically self discover nearly everything that I know by thinking about a problem for a little bit. I didn't know the term "race condition" when I was 8 years old when I theorized they would be an issue within a few minutes of learning that multi-core CPUs exist. I've been using "tiling" for years to optimize memory access without knowing what it was called. These things just seem blindly obvious when you see the problem.
I wouldn't say you have to specialize. It would just mean you need to spend more of your time researching. In general, I find I can catch up to almost any specialist within a month, but that's a month of no production, just learning. That is a lot of down time. On the flip side, most projects that we have take 6 months to a year, and spending 1 month of it researching to catch up to what a specialist spent a life-time specializing is probably acceptable.
It really comes down to the size of your project. If it's really small and needs to be done quickly (less than several months) and well, go with a specialist.
All intranet services are only accessible via work computers.
I think you're a bit off. The faster a rocket goes, the more thrust it produces, not to mention that as the rocket burns through its fuel, it gets lighter.
For performance you don't predict. Experiments are the only thing you have that work
In my experience, I am better at predicting performance than synthetic tests. In many cases, intuition out-ranks empirical evidence because some things are impossible to directly measure, only theory works.
The "Clean Code" guy makes a lot of extremist devil's advocate assertions with the intention of making your think about clean code in a purist way. Of course it is up to you, the reader, to apply his wisdom in a practical manner. His most useful chapters are about code smells. They are the most practical. Kind of "If you see this, stop and think about why, and if it should be done this way or is there a cleaner way".
Sometimes you can even get away with just knowing how the code should NOT work to fix a bug.
I wish I was so lucky. When ever I have to deal with other software engineers, they only define the overly simplistic happy paths. Failure paths? What are those? That really grinds my gears. I always rub their nose in it when I ask them if that is how it should work, only to find out they did not think of that situation. I just tell them it is undefined, so it is not a bug. "Fixing" the situation is now a feature request.
I should refine my statement. "You cannot know how your code does not work until you know how it is supposed to work, and you cannot know how your code is supposed to work until you know how it should not work." I work with very complex multi-threaded code. Every bug that I have not been able to explain has been a result of a bug in the framework or library that I used. I make sure my code has well defined failure paths and guaranteed state transitions handled by single points of responsibility.
Particularly when debugging legacy code where knowing how it works is not all that realistic.
I actually get pulled into helping people debug their code when I don't even have access to the code. I find the quickest way is to just keep asking "what all is responsible for handling this and how are they meant to work". Even when working at an abstract level, I can help them find the issue quickly with the above approach. And it always makes for a good time to slip in "imaging how much easier this would be if you only had to look in one place". SOLID is your friend.
Some times I don't even get the advantage of someone to ask, seeing the code, or knowing the architecture. Everything that I know is just what the customer reports and I have to infer the rest and make lots of educated guesses. And I still mange to figure out the problem faster than the ones who wrote it. But I've always had a strong intuition when it comes to computers. My co-worker is very intelligent, but he has little intuition. He has a math background and can quickly implement nearly any algorithm or protocol by reading an RFC. He needs empirical data. The problem is a lot of the hard issues we deal with, you only get to see the symptoms, which means all of your empirical data is not about the cause, but the effects created. Many times if you read too far into the data, it will send you in the wrong direction.
I always strive to have a theory why something works the way it does. If my theory does not match, I try to create predictions with my theory and see if the are true. My co-worker doesn't really have a theory, he just has a bunch of data and reads it too literally. The thing is, I cannot argue against his logic, he has flawless logic, what I argue against are the hidden variables that cannot be directly measured. My theories predict these and make clean predictions. He has learned to humor me with my thoughts.
A simple example is perhaps he looks at the memory profiler and sees some objects getting promoted to Gen2 and causing lots of GC. Then I argue that in theory, those objects should be used momentarily and the root issue is something is blocking the release of those objects. Look around, and see a stack variable that references those objects well past when they're needed, but the resulting work caused by those objects is taking some time, keeping the stack reference in scope. Just null the stack reference to the objects after they're needed, and the problem goes away.
You know that you're going to throw away most of the code. Most people don't see a prototype meant as a learning experience, they instead see "working" code. All working code is equal in their mind. Except they don't actually know how it works, it only seemingly works. You can tell they don't know how it works when something finally goes wrong and they can't even guess as to why it's not working.
.Net or SQL because their program is not working correctly. They can't even understand their own code, why are they so willing to blame someone else's?
One of my rules of thumb is "You can't know why your code doesn't work unless you first know how it works.". 80%+ of the time, in the rare case that someone finds a bug in my code, I can typically tell them where the bug is and under which situations it will occur without ever looking at the code or using a debugger. I can many times do the same thing to other's people code for which I have never seen. I can infer much of how their program is designed based on how the characteristics of the bug. I purposefully try to write well-factored code with single-responsibility to make it easy for me to reason about. When I get dragged into helping someone debug their code because they're lost in their own maze.
Many times I've had programmers tell me they think there is a bug in
but V = 5
is wrong. V is 4.
0.999... = I (I = 1)
IV = 4 (1*4 = 4) (V = 4)
V = 4/I (4 = 4/1)
V = IR (4 = 1 * R) (R = 4)
I = V/R (1 = 4/4)
V = 4R/V (4 = 4*4/4)
R = V^2/4 (4 = 4^2/4)
but V = 5 (WRONG, it was defined as 4 by the second line)
But "Mr.Z of the LotFC" points out "IV=4 & V=5 as Roman numerals (as is 0.999...=I)...the derivation appears to be a math pun of sorts."
Do Lots of Deliberate Practice ... "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."
The quote about deliberate practice is taken out of context.
1) It is said it typically takes 10,000 of deliberate practice to become "elite", but it can take as few as 100 hours for those "naturally" good at something
2) This mostly applies to professions where practice matters, like playing an instrument. As a profession becomes less about muscle memory and more about thinking, practice becomes less useful.
Becoming an elite in a purely intellectual profession can require virtually zero practice. Some people are able to learn by thinking. They can reason through to the conclusion without having to actually practice/experience. Of course nothing is purely intellectual. Even with programming, we have to deal with other humans and need to deal with the fact that we are also human and can make mistakes. You must learn to write clear and defensive code, and be able to communicate with others.
Rule of thumb, don't write any code until you understand the problem and have thought of a good solution. If you were wrong at any point, figure out what was wrong with your reasoning that lead to the mistake and don't make that same logical mistake again. It really comes down to having strong fluid intelligence. This is how someone realizes what they don't know and if what they do know will work for the situation at hand. If you suffer from Dunning–Kruger effect, have a golden hammer, or don't realize you're doing something wrong, you probably need to exercising your fluid intelligence.
There is absolutely ZERO expectation of privacy when using an asset that is provided by your employer.
Is that so? The only way I can access some of my medical information is via my work computer. Are you saying I have zero expectations of privacy to access my private medical data? I'm sure my company is not the only one that has many benefits that are only accessible via intranet services. IT has no right viewing any of that data.
It's not an implementation error. "Secure HTTPS MITM" is undefined. Some many even argue, an oxymoron.
Same thing with math. We can only use math to prove math. At some point we have to assume something without proof in order for everything to work. All science has a bootstrap issue. Time may not exist in the way we think it does, but we're pretty sure it is real.
They're at least 1 cubic plank-length. Not to mention the notion of a true singularity is probably wrong. There's a lot of magic hand-waving to think of a blackhole as a true singularity. Some how the blackhole can grow, yet nothing can fall past the event horizon in any frame of reference, and all of the information is at the "center"? What? How does the information get to the center if by definition it can not?
The more recent idea that a blackhole is just the highest density of information with the information being stored on the surface, just above the theoretical event horizon, is much simpler and agrees or at least does not create a bunch of paradoxes.
Learn to read. I never said there's a 15 gigawatt energy gradient, I just said there's 15 gigawatts of energy moving around in the form of IR. Just because there is not a gradient doesn't mean we're not being bathed in it.
The high voltage power lines are not just dumping ozone into the air, the air is acting like an electrolytic solution. The ozone "disperses" into the air like metallic dust "disperse" in a magnetic field.