All more or less true. Self-driving cars really haven't put in enough km of testing or gone through enough rounds of refinement to be at the level where they can be trusted by the general public, or really even by a community of experts who's motives are unbiased.
But self-driving technology is observing a ratchet effect. It's not getting worse or regressing to a mean, it's always getting better, and at a pretty good rate. It seems that a competent company with deep pockets, like Alphabet/Waymo, will choose to delay the extra 5-10 years beyond when they "think" it's good enough tech, to the time at which it's just so provably better than humans that it can overcome any political or perceived obstacles (especially with the profit incentives behind it). And to the time at which they think the expected returns exceed the liability exposure. But then, it will happen.
But the tech is getting better, constantly, and it's not limited in the ways that humans are, just more limited in some other ways. Faster and more perceptive, but stupider about how it quickly responds to its perceptions. Hard to say exactly when it reaches the point of expected "cha-ching, let's cash in", but it will happen and it seems to be moving forward pretty fast.
My stock portfolio would like a word with you about his "good results".
And unlike the previous results he took so much credit for, but with the exception of the tax "reform" had absolutely nothing to do with, these latest bad results are a direct and immediate result of his lovely little trade war. And it will hit the pocketbooks of folks who own no stocks at all.
There's almost always a bit of a lag before a President begins to make his mark on the economy. Looks like we're seeing Trump making his mark right about.. now.
It does, to the point where it can get hard to leave if you haven't saved a lot of it. So I do a ridiculous amount of that.
But what I'm getting at is that it requires interface contracts that are well thought-out and well respected, on both sides of the interface. Even when we do get to enforce a consistency of architectures, we don't always choose a single tool for needs that might at first blush seem fairly homogeneous. For example, we've not found a single database architecture that can accept 100K rather complex transactions per second in our environment and at the same time provide a flexible, easy to manipulate model from which the front-end can issue nearly arbitrary queries. We've chosen a CQRS architecture using CRDTs where we can (sorry for the acronyms, but they're actual things) to get the scale we need. But even using that and other techniques, and the best tools we can find, it requires an irreducible amount of complexity. Failures don't usually occur because something "doesn't work". They occur because something that was a great idea at scale X isn't so great at scale 10X, or 100X. And we can't tell our customers to just get a 20-million dollar server.
Don't get me wrong, complexity is not our friend, any more than it's yours. But you try to make things as simple as you can, and no simpler. That's true no matter what problem you're trying to solve.
Users want it all and the front-end folks are there to give it to them, within reason. The back-end folks are too. When done well, neither role is for the faint of heart, nor should it be, to do it well. Perhaps each "role" will develop more defined distinctions within itself as time goes by.
Personally, I enjoy dealing with this stuff. I'm not fighting bad management, though I do that too. I'm trying to find ways to make the math work out. I can't break the math, or even bend it. But I can find its nuances. Like you I suspect, I try to capitalize on what people who are likely smarter than me have done before, and make it fit what I'm trying to do. Sometimes that requires the use of more than one tool, for what at first seems like one purpose.
It's not all accidental complexity when your customers use different back-end architectures and you must work fairly seamlessly, albeit not identically, within each. Now add in the requirement that not all "clients" for each server are human beings that operate in wait times measured in seconds. For machine-to-machine interactions, wait times (latencies, effective RTTs) may need to be measured in milliseconds, or microseconds.
And it's not pragmatic to talk lightly about ditching this or that crap when the crap actually is proven and has millions of dollars invested in it, and your base of expertise is in this or that crap, and when it's not really crap to begin with, just imperfect.
For complex applications, well executed, both the back-end folks AND the front-end folks have jobs that require brains and expertise. Neither is anything close to trivial. I've done both, in very sophisticated applications and architectures. Both have my respect. Both demonstrate the importance of having people who are, if not masters of their craft, are on their way to becoming such.
Being really good at whatever you do, tends to be rewarded more. Maybe not enough, surely not as much as we'd like. But certainly worth some thought. If you think you're undervalued (not you, but whoever) find out if that's really true, do something about it if you can, make it clear to the people who are actually hiring you for the next position, then switch.
Worked for me. I was doing well, decided (not assumed) that I could do better, made sure that was true, switched. One week vacation in between. (But once you do this, realize that a very big part of your life now is your profession. Treat it well, water it often, but keep it in its place.)
You forgot "explodes when going straight at over 50 km/h, in the rain, at night." Yes, many APIs are inelegant, limited in expressiveness, or even buggy to the point of uselessness. The trick is sniffing out the ones that aren't, and will still be around next year. Then they can help quite a bit.
As an aside: If you have a fool-proof way of doing this, please let me know.
Many of us (but not all, maybe not even most) don't assume either way, except to the extent that the context warrants it. Some others may have a high IQ (pretending here that that's actually a useful term) but it's only applicable to a narrow area or type of thinking and behavior. So social judgements of others might be a weak area for them. This happens a lot, in my experience.
Also, a real problem with high IQ people is that we sometimes have become accustomed to being considered the one who is "right", by default. WE ARE NOT. Arrogance can arise from being told you are right "all the time", which does correlate with intelligence, but just ain't true. Usually, it can be slapped down pretty quickly and should be, in a semi-polite way. Very smart people can be quite useful, and maybe worth the extra money we often get, once you've gotten them (us) in our place, and reminded or taught them/us that puzzle-solving intelligence is only one factor among many that define what an individual can offer.
Hmm. Reading rtb's post I was able to follow it fine. Then I read the Captain's post, went back, and yes there were some errors (e.g., "ie" with no punctuation, and a few other things that you typically just give a pass on in an internet post.) Then I read your post, went back and read both prior, and wondered if you had missed the "/s" in Quark's, then wondered what I might be missing in all three. Yeesh, I'm overanalyzing. Decided to skip it, get coffee. Then post-coffee, I figure I might as well post myself (cause: coffee, of course).
My conclusions: 1) Editors probably aren't overrated, just under-hated, 2) Coffee is a double-edged sword, 3) I used the word "post" too many times, but I'm not going to go back and fix that ex post facto.
Yeah, I only really had to pay attention to it recently when designing a high-throughput application, where some of the unavoidable round-trips in our ingestion pipelines need to finish inside of 10-15 microsecs. For most use cases it doesn't matter.
Er.. the velocity factor in CAT-7 equates to about 3/4 of c in a vacuum.That's close to the best copper can do. Fiber has a refractive index which results in about 2/3 light speed for signal propagation.
Slashdot Mirror
And when the companies really have no choice but to do what a nation's government tells them to do, what does that imply?
At what?
You criticized him. You terrorist.
The course is available through edX, which is the same way they said they'd continue to make content available in the very post you cited.
"Inner Voices"
https://xkcd.com/378/
All more or less true. Self-driving cars really haven't put in enough km of testing or gone through enough rounds of refinement to be at the level where they can be trusted by the general public, or really even by a community of experts who's motives are unbiased.
But self-driving technology is observing a ratchet effect. It's not getting worse or regressing to a mean, it's always getting better, and at a pretty good rate. It seems that a competent company with deep pockets, like Alphabet/Waymo, will choose to delay the extra 5-10 years beyond when they "think" it's good enough tech, to the time at which it's just so provably better than humans that it can overcome any political or perceived obstacles (especially with the profit incentives behind it). And to the time at which they think the expected returns exceed the liability exposure. But then, it will happen.
But the tech is getting better, constantly, and it's not limited in the ways that humans are, just more limited in some other ways. Faster and more perceptive, but stupider about how it quickly responds to its perceptions. Hard to say exactly when it reaches the point of expected "cha-ching, let's cash in", but it will happen and it seems to be moving forward pretty fast.
Umm.. you realize that's probably not necessary. They're obviously already doing a lot of fucking just amongst themselves.
I'm watching it right now.
Back then there were no tablets. Everyone used mainframes, or nothing at all.
Humans are one of the only animals that ARE adversely affected by poisonous plants they don't eat (e.g., Coca, Opium).
My stock portfolio would like a word with you about his "good results".
And unlike the previous results he took so much credit for, but with the exception of the tax "reform" had absolutely nothing to do with, these latest bad results are a direct and immediate result of his lovely little trade war. And it will hit the pocketbooks of folks who own no stocks at all.
There's almost always a bit of a lag before a President begins to make his mark on the economy. Looks like we're seeing Trump making his mark right about.. now.
Maybe it was that new barge they just brought into use, the "I Always Look Fat In Photos", and they skipped the close-ups out of politeness.
It's the kind of article that is sighted in the precise site where it occurs, a fact that is then cited elsewhere. Hopefully producing new insights.
It does, to the point where it can get hard to leave if you haven't saved a lot of it. So I do a ridiculous amount of that.
But what I'm getting at is that it requires interface contracts that are well thought-out and well respected, on both sides of the interface. Even when we do get to enforce a consistency of architectures, we don't always choose a single tool for needs that might at first blush seem fairly homogeneous. For example, we've not found a single database architecture that can accept 100K rather complex transactions per second in our environment and at the same time provide a flexible, easy to manipulate model from which the front-end can issue nearly arbitrary queries. We've chosen a CQRS architecture using CRDTs where we can (sorry for the acronyms, but they're actual things) to get the scale we need. But even using that and other techniques, and the best tools we can find, it requires an irreducible amount of complexity. Failures don't usually occur because something "doesn't work". They occur because something that was a great idea at scale X isn't so great at scale 10X, or 100X. And we can't tell our customers to just get a 20-million dollar server.
Don't get me wrong, complexity is not our friend, any more than it's yours. But you try to make things as simple as you can, and no simpler. That's true no matter what problem you're trying to solve.
Users want it all and the front-end folks are there to give it to them, within reason. The back-end folks are too. When done well, neither role is for the faint of heart, nor should it be, to do it well. Perhaps each "role" will develop more defined distinctions within itself as time goes by.
Personally, I enjoy dealing with this stuff. I'm not fighting bad management, though I do that too. I'm trying to find ways to make the math work out. I can't break the math, or even bend it. But I can find its nuances. Like you I suspect, I try to capitalize on what people who are likely smarter than me have done before, and make it fit what I'm trying to do. Sometimes that requires the use of more than one tool, for what at first seems like one purpose.
I actually have seen stable backends. But even when they're very well put together, I prefer them when they sway from side to side a bit.
It's not all accidental complexity when your customers use different back-end architectures and you must work fairly seamlessly, albeit not identically, within each. Now add in the requirement that not all "clients" for each server are human beings that operate in wait times measured in seconds. For machine-to-machine interactions, wait times (latencies, effective RTTs) may need to be measured in milliseconds, or microseconds.
And it's not pragmatic to talk lightly about ditching this or that crap when the crap actually is proven and has millions of dollars invested in it, and your base of expertise is in this or that crap, and when it's not really crap to begin with, just imperfect.
For complex applications, well executed, both the back-end folks AND the front-end folks have jobs that require brains and expertise. Neither is anything close to trivial. I've done both, in very sophisticated applications and architectures. Both have my respect. Both demonstrate the importance of having people who are, if not masters of their craft, are on their way to becoming such.
Being really good at whatever you do, tends to be rewarded more. Maybe not enough, surely not as much as we'd like. But certainly worth some thought. If you think you're undervalued (not you, but whoever) find out if that's really true, do something about it if you can, make it clear to the people who are actually hiring you for the next position, then switch.
Worked for me. I was doing well, decided (not assumed) that I could do better, made sure that was true, switched. One week vacation in between. (But once you do this, realize that a very big part of your life now is your profession. Treat it well, water it often, but keep it in its place.)
You forgot "explodes when going straight at over 50 km/h, in the rain, at night." Yes, many APIs are inelegant, limited in expressiveness, or even buggy to the point of uselessness. The trick is sniffing out the ones that aren't, and will still be around next year. Then they can help quite a bit.
As an aside: If you have a fool-proof way of doing this, please let me know.
Many of us (but not all, maybe not even most) don't assume either way, except to the extent that the context warrants it. Some others may have a high IQ (pretending here that that's actually a useful term) but it's only applicable to a narrow area or type of thinking and behavior. So social judgements of others might be a weak area for them. This happens a lot, in my experience.
Also, a real problem with high IQ people is that we sometimes have become accustomed to being considered the one who is "right", by default. WE ARE NOT. Arrogance can arise from being told you are right "all the time", which does correlate with intelligence, but just ain't true. Usually, it can be slapped down pretty quickly and should be, in a semi-polite way. Very smart people can be quite useful, and maybe worth the extra money we often get, once you've gotten them (us) in our place, and reminded or taught them/us that puzzle-solving intelligence is only one factor among many that define what an individual can offer.
Hmm. Reading rtb's post I was able to follow it fine. Then I read the Captain's post, went back, and yes there were some errors (e.g., "ie" with no punctuation, and a few other things that you typically just give a pass on in an internet post.) Then I read your post, went back and read both prior, and wondered if you had missed the "/s" in Quark's, then wondered what I might be missing in all three. Yeesh, I'm overanalyzing. Decided to skip it, get coffee. Then post-coffee, I figure I might as well post myself (cause: coffee, of course).
My conclusions: 1) Editors probably aren't overrated, just under-hated, 2) Coffee is a double-edged sword, 3) I used the word "post" too many times, but I'm not going to go back and fix that ex post facto.
Yeah, I only really had to pay attention to it recently when designing a high-throughput application, where some of the unavoidable round-trips in our ingestion pipelines need to finish inside of 10-15 microsecs. For most use cases it doesn't matter.
Er.. the velocity factor in CAT-7 equates to about 3/4 of c in a vacuum.That's close to the best copper can do. Fiber has a refractive index which results in about 2/3 light speed for signal propagation.
And the rich fucks are in a Rolls-o-dex.
And accessories.
He should use a very high magnification telephoto lens, to determine if really is turtles all the way down.