jaawn

That isn't a "new" model with all of the uncertainty that goes along with it though. Rav4 and CR-V have established reputations, entrenched supply chains, etc... A better comparison would be brand new models, not refreshed old models.

I guess that is fair, but according to this carsalesbase.com site, it isn't even remotely close. Tesla has built/sold more Model 3s in its first year of production than anything else I can find...by a lot. They built/sold more in the past few months than entire years for all of the other models I have checked.

That's why I asked what models the other person looked at because so far all of the information I can see from the site that they linked confirms the "pro-Tesla" person's statements.

Which models did you look at? I don't remember a lot of models that are new to the market recently. I checked the Mazda CX-3 and the Nissan Leaf, and the Model 3 does appear to have crushed both of those based on first year numbers.

Obviously we don't know yet, but I would be absolutely shocked if they don't basically flag everything about well-known politicians as "political", and paying to boost something like that should fall under the new restrictions. It would be trivial for most large tech companies to make an automatic "political post" classifier at this point. The post "boosting" use case is a pretty easy target too because blocking someone from paying to boost something is fairly low-risk.

"Zero cost abstraction" is like a sarcastic joke at this point in web development. If you pull up performance comparisons for web backends, a lot of the popular ones based on interpreted languages are absolutely abysmal when compared to c++ or Java code (Node is a good example). Many definitely have streamlined development workflows and have nice, high-level abstractions, but at a cost to performance. I don't mean that Node is useless or something, sometimes it makes sense, but it still forces you to compromise.

Front-end frameworks are even worse. A lot of older (but not "ancient") PCs are unusable on the modern web because of poorly-optimized JS or Adobe Flash (a decent portion of this issue is also due to the inherent inefficiency of JS and Flash as well). Fortunately, Google has been making strides with V8, Mozilla did awesome with Firefox "Quantum" and everyone is slowly ditching Flash, but performance still seems to be an ever-present issue.

Oh absolutely. I have been noticing this is starting to happen with SSDs as well. A lot of modern games run awful on mechanical drives.

I have thought for awhile, and continue to think, that developers avoid "premature" optimization too fiercely. Yes, there are diminishing returns with optimization effort, but too often people interpret "avoid premature optimization" as "never optimize unless it feels slow, and even then only if it feels slow when it's the only thing running. Otherwise, blame everything else that is running first!"

This is a really good point, I hadn't thought of this before. Because of how many other options there are, the "scarcity" of Bitcoin is only real if there is something that is going to prevent other cryptocurrencies from being used, or promote Bitcoin above all others. Given that Bitcoin has been demonstrated to be inferior at scale vs. some of the other options, I don't see a reason to expect that it will continue to be the most prolific in the long term. By extension, there doesn't seem to be an obvious indication that any of them will see a lot of use in the long term.

To piggy back on something you said: a big issue I noticed recently is that it seems a lot of the websites people use to track this stuff have charts in <other coin> vs. BTC rather than <other coin> vs. USD (or some other established currency). As BTC goes up and down, these charts are extremely misleading due to the volatility. This dramatically pushes things into fantasy speculation land since people are valuating their speculative investments based on another very speculative investment. If BTC drops in USD price, and your altcoin of choice gains slightly vs BTC, these charts would show a "gain" when I think in reality it is still a loss.

within roughly 5 years or so (very rough guess on my part), all of the available Bitcoin will have been mined. At that point, the mining part of the equation will be moot, leaving only the blockchain infrastructure to consider. Note that this may not hold true for various "forks" of the bitcoin blockchain, or for other cryptocurrencies.

The Java performance was the most interesting part of the results for me. I'm glad it got some attention. I have been developing the opinion for awhile that, as an industry, we've become far too avoidant of "pre-mature" optimization. It is astonishing to me how much slower a lot of this stuff is than Java.

Granted, I also think considering Java to be "not compiled" is a slight misrepresentation since it does get compiled to Java bytecode.

This is a fair point, but most vocational programs last years not months, so that is where the analogy breaks down here. I think "vocational" code schools offering 2-year degrees would be very, very attractive as an alternative to a traditional CS degree (both for students and hiring managers), but that's not what we're looking at.

According to a quick Google search, the average program length for these boot camps in 2015 was 11 weeks. That is on par with a single semester at a university. Even if you take a heavy course load of only practical CS courses, one semester is not nearly enough to prepare someone fully for a full-time dev position at top-tier companies. Sure, they may be able to answer the interview questions...but then what? I'm pretty skeptical of this trend and don't see it ending well for most of the boot camp graduates or companies who hire a large number of them.

Also to be fair, learning how to select elements by CSS class is so trivial that it doesn't effectively separate levels of developers. Whether you choose the basic JavaScript version or one from a popular framework, it should take less than a minute to look up if you don't already know it. I imagine that seasoned developers (and possibly recent CS grads, depending on school) are much, much less likely to waste time wondering why $(".myClass") is giving them a "$ is undefined" error in their Angular/React/etc... project.

I might be wrong, I don't have any direct experience with boot camps, but stripping dev skills down to just the minimal, core, practical skills needed to build a working prototype in the language-of-the-month seems like just the latest version of the same short-sightedness that has been plaguing businesses for years. Low-risk, long-term success will always come from building on experience, not "hacks" and short cuts. There will be exceptions/outliers, but they're just lucky, not a model to be copied.

This is exactly what I was thinking. Put into words that are easier on my brain: If the things taxes are being spent on (social programs, shared services, and shared spaces like parks) are significantly better, one might still have a "better living" with a lower salary.

One of the main aspects of this that is very relevant to Americans is how easy or difficult it is to be fired and what programs are available for those who lose their job. Even if you are never fired, simply the threat of it can cause anxiety and stress that simply wouldn't exist in places where it is harder to be fired and which have better programs for people who are fired.

Whoah, I did not know they had a free plan for personal use. Thanks for the tip!

I imagine that if the service call to verify mock data fails, it should retroactively invalidate all tests based on that mock data, or at least this should be understood to be the case by the people reviewing test reports.

I have been cringing every time I see/hear the word "disrupt" (in its various forms) for a couple years now. In pretty much all cases, the more often a given person uses that word, the more vapid I come to think they are.

"Except digital signing makes the compromised OS totally and utterly useless for other phones."

This carries with it the assumption that the digital signing and verification mechanisms are infallible and impervious to attack. That is an unwise assumption. Even if a software system appears to be perfectly secure at a given time, it is reasonable to assume that at some point a vulnerability will be discovered.

Yes, it is. I can observe innocent tourists and citizens taking photos and avoid them if I want to. The key part you missed was "without my knowledge." I'm not going to obsess over being in the background of the occasional tourist photo, but if I want to avoid it, I can by simply observing the obvious camera and avoiding it. I could even discuss it with them if I really cared for some reason, and possibly have them delete a photo of me.

I am aware of tourist photos and photos by friends. It is reasonable to expect that I'll be in occasional photographs where I am not the subject. I know that. It is reasonable to expect that I won't be the subject of photos without my knowledge or included in detailed photographic records just because I went to a public place. Detailed imagery of your whereabouts and activities should never be expected and should only be legal with a warrant.

It is unreasonable to expect to not be observed in a public place, but it is reasonable to expect to not be recorded artificially without your knowledge. This goes for all locations, including public ones.

If someone doesn't want to be captured, too bad, they shouldn't be throwing photons at you (read: if they want privacy, they shouldn't be in a public location).

That is true when it comes to merely being seen, but not being recorded. Being in a public location naturally implies consent to be seen, but it does not imply consent to be recorded artificially. (This includes any augmentations to human abilities from future technology, as someone mentioned this in a later comment)

That is a much better approach. It incorporates the humility you need to have with this type of data. That system works because it does not assume and expect accuracy, it works around the problem in a different way.

So, I guess my original sentiment is more like: "data-driven" is not a good thing on its own, because you need more than just a bunch of data, you need analytics.

It may seem more semantic than anything else, but I think there are some real differences in how people (especially managers) perceive "data-driven" vs. some other term like "analytics-driven". "Data is not magic" should be a catch phrase spread far and wide among the non-technical business world.

This is entirely possible. However, when the data being measured is about complex human behavior (i.e. time allocation, productivity, work habits, etc...), I don't think we are even a little bit close to accurately representing reality. If we were "pretty close," then sure you could justify making decisions based on that data, but I don't think we are close enough for that.

Even just the "time worked on X" example is too complex to track. It is deceptively "simple." It seems like (especially to managers) employees should be able to work on a task for awhile, and afterward record how much time they spent working on it. However, it isn't that simple.

In reality, "working on X" might actually mean working on X along with several other things such as email or web browsing or talking to a co-worker or answering the phone. With reliance on self-reporting, and without some sort of monitoring system, it is unreasonable to expect this metric to be accurate, yet this is how many (most?) time reporting systems work.

Managers are making large-scale decisions based on this data. It looks like accurate data, it has fancy graphs and charts and reporting...but it isn't actually very accurate. An employee might report an hour spent on a project, when really only 40 minutes of that hour were spent on the project work, while the remaining 20 minutes were spent on various interruptions and extra tasks. This inaccuracy isn't much of an issue for informal uses, such as sticking to a personal schedule, but for driving decisions as part of a greater pool of data, it is misleading.

At my organization, upper management is trying to use time reporting data to come up with a total cost for various initiatives. This is the kind of scenario I am talking about. Managers don't typically sit and watch everyone work, nor do they discuss time reporting entries individually, so all they end up seeing is the data. This separates them from how that data is generated and leads to inappropriate reliance on that data. From their perspective, it feels like reliable data that can be used to assign a cost to various projects, but the data probably doesn't adequately support that use case.

Not all technology has an equal ability to displace human workers. I'd argue that the most displacing technology is just now being developed. Sure, some technology has a neutral impact on the job market, but some!=all

Hurray Capitalism?

Then, depending on structure, people could assist on the delayed dependency, or devote time to a lower-priority project until they are able to work on the more important one.

If neither of these are possible, then it probably is okay for that employee to work shorter days in the meantime, and leadership resources should spend time solving the bottle neck issues to prevent the situation in the future.

I agree, but what I mean is managers trying to govern how employees work rather than how they are managed. There are cases where these are related, but I think most of the time they are separate.

You should have clear, stated goals for deliverables, each deliverable should have a group of people who is responsible for it. Anyone who is is responsible for any deliverables which are delayed should not be working 5 hour days.

I think this is something that varies a lot based on the nature of the work. Creative software development/design/engineering is more taxing in a way that precludes almost anyone from being productive at an 80+ hour/week level, especially if it is the "normal" workload.

Not to diminish finance people, by the way. I'm sure they work hard, but in a different way.

Mr. Bezos' response strikes me as the all-too-familiar case of upper management not keeping tabs on middle and lower management. If he is truly sincere that he does not recognize the version of Amazon depicted in the article, and does not agree with that type of management, then he (like many high-level managers) needs to take an active approach in weeding out abusive managers at all levels (especially lower level managers).

I work at a large enterprise (5,000+ employees) and this is a huge problem for us. Upper management has a vision for the organization, but it gets lost on its way down the chain. A simple phrase is the main culprit: "...<any given policy> is up to manager discretion."

For example, upper management: "We are creating a flexible part-time teleworking agreement whereby employees can work from home up to 2 days per week. Usage of this arrangement is up to manager discretion." Lower management: "I know about the new teleworking option, but our department is not participating because how can anyone get work done at home?"

If upper management does not actively monitor and intervene with stifling lower-level managers, they can definitely create an organization that, in practice, differs greatly from the one they imagine, the one they wanted to create.