4 ms·

The problem is, what you define as a pro is completely vague. There's no adequate definition of one as its simply presumed that a pro "knows what to do in X sit

The problem is, what you define as a pro is completely vague. There's no adequate definition of one as its simply presumed that a pro "knows what to do in X situation in X domain" which is almost no different than "knowing what to do in every situation that resides in X domain". There's literally no difference, its that vague. Professional drivers really don't need to know much outside of the behavior of what they experience while driving. This is why there are things like pit crews and staff that support the driver. Its so the driver has to think about driving, not what fuel to air mixture is adequate to prevent piston knock. This is the problem, nobody adequately defines what a professional is and can only be seen when "someone knows what to do" which implies having broad, wide scoping knowledge about a topic which again, is supposed to be something that isn't required and is the point of having models in the first place. Its not that having in depth knowledge is bad, its just that having in depth knowledge is often not required and it doesn't make you any less of a professional for not "knowing it at the right time". And with regards to Y / 0, a programmer is mostly thinking about how to catch the exception properly for a given task. He does not care that the exception is nested X levels deep in the class hierarchy. He does not even need to know the mathematical understanding of Y / 0, just that its an error state. He does not care how the error code is generated, just that it exists. He does not care how the list adds/removes items and what the worst case runtime is, he just cares about its use. Because the point is, you're not supposed to care about implementation details. Abstraction is king and you can go a long way without knowing a lot.

stcredzero 8y ago
The problem is, what you define as a pro is completely vague. I think it's pretty clear from this thread. In the context of programming, it's someone who can do what a "mere user" can do, but who can push the thing to extreme limits, modify it to do something completely new, or fix it if it's somehow broken or has holes in its design. Professional drivers really don't need to know much outside of the behavior of what they experience while driving. In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance. There's a lot to know about competition rules and regulations. They need to know enough about the physics of car aerodynamics, and how it affects their grip in different situations. Not knowing such things has literally gotten professional drivers killed. And professional encompasses more than just racecar drivers. Truck drivers working in extreme conditions have to know quite a bit, it turns out. Truck drivers who are pointedly ignorant about their engines can end up costing someone a lot of money in repairs. "Professional driver" actually encompasses a number of careers. The point is, professionals have to know a lot that goes much, much deeper than just being an "end user." And with regards to Y / 0, a programmer is mostly thinking about how to catch the exception properly for a given task. Not necessarily. This would vary a lot depending on the language and the particular task. He does not care how the list adds/removes items and what the worst case runtime is, he just cares about its use. Not necessarily. This would vary a lot depending on the language and the particular task. Because the point is, you're not supposed to care about implementation details. Abstraction is king and you can go a long way without knowing a lot. The king is just another fallible mortal. All abstractions leak. I'll grant that there are professionals what can mostly get away with basically just being an end user. 95+% of the time, everything will be routine, and copacetic. It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional."
- jshowa3 8y ago
  I think it's pretty clear from this thread. In the context of programming, it's someone who can do what a "mere user" can do, but who can push the thing to extreme limits, modify it to do something completely new, or fix it if it's somehow broken or has holes in its design. Its not clear at all because you can simply move the goal post. Someone with 20 years of programming in client side apps struggles with programming a website and can't figure things out on X situation without help. Does that mean they are automatically not professional? In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance... Again, another arbitrary definition. I bet you can go to most professional drivers and they won't understand the physics at all, they have an understanding from experience and consultation of the experts, but I would bet that 90% of drivers aren't going to pull out calculus or kinematic equations to analyze a race track. They either hire someone to do that or use a computer (most likely) to simulate the race. And even then, the simulations are inaccurate due to driver emotional state. My guess is they have, at most, a surface level understanding of driving physics. Not necessarily. This would vary a lot depending on the language and the particular task. So does everything, but we know that Y/0 is a programmed failure state based on the library being used. So the solution is either, catch the exception (and by catch, I mean control in a broader sense since you can condition the input), use a different library, or write your own library. I would hope, in a business setting and in most settings, you would choose to catch the exception or control for it in some way. It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional." So you base your decision on the few percent of people that can do X vs. the 95% of people that can't, but can solve all other problems without knowing the details? Seems like a very irrational outlook considering the following: a) Some of these top 5% of people may not even exist b) If they do exist, they are most likely consulting c) They are being paid more than most businesses can afford d) They work for companies you probably don't work at e) They are doing research work and publishing papers you probably never read f) They probably can't solve X problem outside their expertise without assistance But the point is that even if abstractions leak, they rarely do. And that's the whole point of engineering and technological advancement in general, is so that you don't need to know the details.

stcredzero 8y ago

The problem is, what you define as a pro is completely vague. I think it's pretty clear from this thread. In the context of programming, it's someone who can do what a "mere user" can do, but who can push the thing to extreme limits, modify it to do something completely new, or fix it if it's somehow broken or has holes in its design. Professional drivers really don't need to know much outside of the behavior of what they experience while driving. In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance. There's a lot to know about competition rules and regulations. They need to know enough about the physics of car aerodynamics, and how it affects their grip in different situations. Not knowing such things has literally gotten professional drivers killed. And professional encompasses more than just racecar drivers. Truck drivers working in extreme conditions have to know quite a bit, it turns out. Truck drivers who are pointedly ignorant about their engines can end up costing someone a lot of money in repairs. "Professional driver" actually encompasses a number of careers. The point is, professionals have to know a lot that goes much, much deeper than just being an "end user." And with regards to Y / 0, a programmer is mostly thinking about how to catch the exception properly for a given task. Not necessarily. This would vary a lot depending on the language and the particular task. He does not care how the list adds/removes items and what the worst case runtime is, he just cares about its use. Not necessarily. This would vary a lot depending on the language and the particular task. Because the point is, you're not supposed to care about implementation details. Abstraction is king and you can go a long way without knowing a lot. The king is just another fallible mortal. All abstractions leak. I'll grant that there are professionals what can mostly get away with basically just being an end user. 95+% of the time, everything will be routine, and copacetic. It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional."

jshowa3 8y ago
I think it's pretty clear from this thread. In the context of programming, it's someone who can do what a "mere user" can do, but who can push the thing to extreme limits, modify it to do something completely new, or fix it if it's somehow broken or has holes in its design. Its not clear at all because you can simply move the goal post. Someone with 20 years of programming in client side apps struggles with programming a website and can't figure things out on X situation without help. Does that mean they are automatically not professional? In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance... Again, another arbitrary definition. I bet you can go to most professional drivers and they won't understand the physics at all, they have an understanding from experience and consultation of the experts, but I would bet that 90% of drivers aren't going to pull out calculus or kinematic equations to analyze a race track. They either hire someone to do that or use a computer (most likely) to simulate the race. And even then, the simulations are inaccurate due to driver emotional state. My guess is they have, at most, a surface level understanding of driving physics. Not necessarily. This would vary a lot depending on the language and the particular task. So does everything, but we know that Y/0 is a programmed failure state based on the library being used. So the solution is either, catch the exception (and by catch, I mean control in a broader sense since you can condition the input), use a different library, or write your own library. I would hope, in a business setting and in most settings, you would choose to catch the exception or control for it in some way. It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional." So you base your decision on the few percent of people that can do X vs. the 95% of people that can't, but can solve all other problems without knowing the details? Seems like a very irrational outlook considering the following: a) Some of these top 5% of people may not even exist b) If they do exist, they are most likely consulting c) They are being paid more than most businesses can afford d) They work for companies you probably don't work at e) They are doing research work and publishing papers you probably never read f) They probably can't solve X problem outside their expertise without assistance But the point is that even if abstractions leak, they rarely do. And that's the whole point of engineering and technological advancement in general, is so that you don't need to know the details.