If it needs software to fix it, you must provide that software. It will create some extra burden on the manufacturer
One difficulty with that approach is that the software required for a third-party replacement component might be completely different to the software required for the component from the original manufacturer. What is really needed isn't necessarily like-for-like copycat products, it's modularity and compatibility. That means it's the specs and interfaces that really need to be standardised and disclosed, not so much the full set of code.
However, that supposes that the original manufacturer designed their components and software in a conveniently modular way. That is a significant restriction to impose that could have all kinds of unwanted side effects if you required it by law, including potentially making some useful products objectively worse than they could have been and/or significantly more expensive than they could have been, perhaps even to the point of not being viable at all in some cases. On the other hand, without such a legal requirement, this is a gaping loophole in the protections, since a manufacturer can just build monoliths deliberately and then argue that interoperability is irrelevant. That in turn would be balanced by meaning that of course the manufacturer couldn't then replace the same components themselves either, which could be good for their built-in obsolescence plans if that's how they want to work, but again isn't necessarily good for the end customer.
As I said, it's a tricky area to balance. There are good arguments on both sides, but sometimes the goals are mutually exclusive.
Car manufacturers are required to offer parts and the information necessary to make repairs to third parties.
This is going to be a tricky area to balance as we increasingly rely on complicated, software-supported systems.
With a physical product like a car, a mechanical part can be observed, measured and reproduced by a third-party repair supplier. If they're accurate enough, it will work just like the original.
As you get into software systems, there are going to be legitimate and difficult questions about how much disclosure should be required. It's good to ensure fair competition and avoid lock-in effects. However, this also imposes overheads on a business, even if that business otherwise provides and supports good products. Quite reasonably, the business doesn't want to end up responsible for supporting every third party's possibly sub-standard replacements.
I'm not sure there are any really good answers here. It might be a good start to mandate that businesses can't knowingly and actively interfere with third party replacement components, for example, by introducing a software kill switch whose main or only purpose is to brick a device if it doesn't have "official" components.
Maybe the time has also come to look again at the short warranties and support periods often offered for these expensive devices, and start imposing stricter rules about end-of-life, compatibility and data portability, and so on to bust some of the lock-in effects that way.
This is where it comes to sacrifices you make when you live somewhere like Silicon Valley, or most major tech hubs.
Is this a particularly US thing, I wonder? The city near me is Cambridge, UK, and it's one of the most cycle-friendly cities in the country, while also being a major tech hub. The Really Big City near me is London, and again there are a lot of cyclists and a lot of tech.
That said, yes, nobody should suffer an abridgement of the rights just because someone else is retarded.
Ideally, no, but such an arrangement is not always practical.
Consider something like traffic laws. I'm an experienced driver, with a good car and statistically a very good safety record. There is no doubt that under various conditions I could break various technical traffic laws, for example exceeding the speed limit or passing a red light, without causing any risk or inconvenience to anyone else. And yet the limits and restrictions apply to me just as they do to everyone else, and consequently the rules are unambiguous. That means a driver who breaks them under less favourable conditions can effectively be penalised, which is beneficial to society (including me). If you consider freedom of movement a right, this is clearly a restriction on my ability to move freely, but with a "greater good" justification.
To give a more obvious example, at the risk of mentioning a bad subject on a forum with many American members, there's a lot of debate about the right to bear arms under the US Constitution, but no-one would seriously suggest that just anyone should be able to buy a WMD, even if they did know perfectly well how to handle it safely. The potential consequences of abuse by one person are too great to trust any one other person with that kind of power.
This is an underrated argument. If everything was effectively DRM'd, we would have to find solutions that weren't painful for legitimate customers or for society as a whole. There would have to be some mechanism where fair use could actually, well, be used. There would have to be some mechanism to demonstrate who a legitimate rightsholder was to qualify for the DRM, so takedown mechanisms that can be abused today wouldn't need to exist in the same way. Copyright durations would have to be sensible and there would have to be a mechanism for ensuring works were properly released when the time came. If businesses adopted subscription models and then started hiking up prices once they'd got data locked in, we would soon have laws mandating data portability to promote fair and legal competition (much as the EU is now introducing with the GDPR, albeit for a slightly different reason).
Most of the problems with DRM aren't really problems with DRM, they're problems with DRM denying customers what they legitimately paid for, DRM denying society its side of the copyright bargain, or badly implemented DRM having negative side-effects that are nothing to do with IP rights, such as creating security vulnerabilities or privacy problems.
Of course, in practice such a system would be unworkable for a variety of reasons, but it's an interesting thought experiment along the lines of "What if copyright law were actually enforced robustly?"
You gain experience by doing. The more things you're doing, the less you're doing of each.
Again, that doesn't necessarily follow. HTTP is HTTP whether you're learning about it from the client or the server side. HTML and CSS are the same wherever you render them. Basic principles of software design. Techniques and judgement for writing good code. Testing strategies. Many, many things are not so different just because of this (IMHO quite artificial) distinction between back-end and front-end development.
The differences tend to be in little things like which specific tools you use, but in the long run those are rarely the important details. Even when they are, picking up a new tool when you've used five similar ones before isn't something that takes months.
I think a person with one year would have to be pretty exceptional in some other respect to get hired over the one with five.
Sure, but in a way that's my point. The difference between someone with one year of experience using, say, React, and someone with five years of experience is unlikely to be how well they understand React itself. Both could easily understand its full API, how to write components in various ways, what the different lifecycle functions are for, and so on. The difference is going to be in other areas, like how well they design their overall system, or how clean and flexible their data models are, or their judgement about where to apply optimisations and understanding of other tools that could provide objective data to guide that process.
Many of these other concerns won't be specific to React itself, or even to front-end development. Again, to the extent that they are, it's likely to be a relatively small and quickly learned relationship. Knowing what shouldComponentUpdate is for or how to turn on React's own performance diagnostics is less important than knowing why there might be a bottleneck in the first place or being aware of the possibilities of using a profiler to guide optimisation work.
They have. It's not webscale because it uses joins.
Maybe you should use MongoDB. I hear MongoDB is web scale.
When the legalese is so long and cumbersome that it would be literally impossible for any normal person to read, understand and actively give informed consent to it, yes, I think it is their problem.
We've got into this strange situation with online services where there is this fantasy legal environment where everyone is signing up for things with these huge accompanying documents that they have supposedly read and agreed to, when those documents might contain terms that have very little to do with what the person thought they were signing up for.
Just imagine the bricks-and-mortar equivalent of what is supposedly happening with online purchases: you get to the checkout at the store with your groceries, spend a couple of minutes getting everything scanned and bagged up, and just before you tap your contactless card to conveniently pay for it in a few more seconds, you have to stop and spend an hour reading 27 printed pages of legal terms including how you may serve the beef, removing any responsibility from the store if your pack of fresh vegetables is half-rotten behind the packaging you can't see through, promising to pay the store's legal costs if anyone else who was in that day falls and hurts themselves but mentions your name while they're suing the store for damages, giving up your own right to take normal legal actions against the store in favour of some obviously not loaded at all "arbitration" process, and agreeing to let someone from the store visit your house whenever they want to check what's in your fridge and then stand in your lounge offering your whole family replacement products they think might interest you that are available from their carefully selected partners. It's absurd on so many levels.
Perhaps the greatest irony is that, at least in places with sensible legal systems, a lot of the legalese is mostly worthless anyway, because if there is something surprising and unreasonable in a standard form contract like this then it's unlikely to stand up in court anyway.
10 years experience in 4 things. So effectively only 2 to 3 in each.
That's not really how it works. You can be gaining experience with more than one thing during the same period.
Moreover, skills and understanding in related fields aren't independent. Learning one when you already have experience of another will often be faster. There will also be significant overlaps where the same knowledge or technique is relevant in multiple contexts.
It's also relevant that the learning curve for these technical fields is typically steepest at the start, with additional experience getting diminishing returns once a certain level of competence is achieved. If someone can understand the basics of a certain tool within a couple of days and master it within a couple of weeks, it doesn't matter whether they have one year or three years or five years of experience with that tool, their capability is still going to be much the same in that respect.
And bear in mind that experience decays.
To some extent yes, but mostly if you're not actively using the skills for an extended period. And even then, the underlying principles, which are the most valuable things you learn with experience, tend to last much longer than the details of some ephemeral tool.
That database you use is now two cycles out of fashion.
Unless all your understanding of relational databases and SQL have gone out of fashion as well, that's not a problem. You just learn the surface details of whichever specific database engine you need to use for your current work, and get on with the job using the rest of your skills and understanding that carried over anyway. Likewise if you've used one NoSQL database but this time your colleagues have chosen a different one, and so on.
If thats true then everyone over 40 who has been employed since they were in their 20's is a friggin unicorn... But a 'unicorn' is someone who contributes something 'unique'.
I'm not sure your preferred usage matches how most people use that word, but in any case, a lot of people who have 20+ years of professional experience and have continued their own professional development throughout certainly would qualify either way. It's difficult to do diverse work for that long and be paying attention without acquiring both a broad spread of knowledge and a lot of depth in some specialised areas.
Probably no-one is completely equal at everything they do. But it's not difficult to imagine someone with 10 years of experience who can do both front-end and back-end programming to a very high standard, and who also understands databases and infrastructure well enough to do everyday tasks themselves and to communicate intelligently with someone more specialised in those fields if necessary.
I've found so many people simply don't want to learn new things.
I agree with you, but I think that's only one part of the problem. Another part is that so many relatively inexperienced web developers today are learning the wrong new things. They buy into the hype and so focus on learning the details of one short-lived tool after another, instead of developing their more fundamental skills that will go far deeper and last far longer.
Developers often talk about needing to use tools they can take from one job to another so their careers don't stagnate, but these tools rarely last long enough in the spotlight to be valuable for more than one or two job moves anyway, and then all those skills and buzzwords are worth almost nothing.
Employers often talk about needing to hire people who can hit the ground running with Supreme Master Framework 1.7.3, but a generally competent developer with knowledge of JS can pick up a typical UI framework or library within a matter of days if not hours anyway, and then they'll still be more capable than a framework monkey.
If web developers learned more substantial development skills instead of obsessing over superficial resume-building with one trendy buzzword after another, then in the long run they'd be able to achieve far more, faster and with better quality results. And if more employers had sensible recruitment practices that focussed on those people instead of requiring silly resume padding just to get past the HR keyword scans, they'd have a much more capable workforce.
It's hard to blame the junior developers for getting caught in this trap, because I think a lot of it is driven by the buzzword bingo recruitment practices of too many employers, and the potential employees are just playing the game by the rules that have been set. But there are more enlightened employers out there too, and if you understand real development instead of just colouring by numbers with this week's framework, you also have options for branching out on your own.
As the saying goes, there is a difference between having ten years of experience and having one year of experience ten times.
A "unicorn" is mostly just someone who's been around for more than a few years and kept learning in a broad range of areas. There are plenty out there.
Some employers have trouble with wanting unicorns but only having the budget for newbies, but that's an entirely different problem.
And I agree with you in turn, but I think that also creates opportunities for smaller, more flexible organisations to do better. Corporate IT thinking it's there to be in charge is a recurring failure mode in large businesses, and they deserve everything they get if they don't fix that problem.
In this case, there is nothing so far to suggest the driver deliberately failed to act
And again, given that the driver was an Apple engineer, it would be very surprising if he were not intelligent and competent. That's not conjecture, just drawing a reasonable inference from the facts we do have.
This whole self drive thing seems way to wild wild west, where a developer goes, hey this would be cool, and adds it to the system. A system that is driving in the real world with real consequences.
Indeed. It is hard to imagine an environment where the SV mantra of "move fast and break things" is less appropriate, both literally and figuratively.
Not really. Conjecture implies guesswork and the drawing of some conclusion without reasonable evidence, like arth1's vague and entirely unsupported innuendos. In this case, there is nothing so far to suggest the driver deliberately failed to act, while there are several points known of his character and past behaviour that look inconsistent with someone who would then deliberately fail to take avoiding action in this situation. I very carefully stated that as an assumption rather than a firm conclusion, and having done so, it is logical to focus on the other possible explanations.
In any case, neither you nor arth1 (assuming you aren't the same person) is adding anything useful to this discussion, so I'm going to stop here.
Grudgingly accepted is good enough for their bottom line to be happy, sadly.
True, but the sustainability of a strategy based on grudging acceptance is always uncertain.
Of course when Adobe went to CC that was commercially good for them in the short term. They replaced intermittent revenue from customers, many of which were no longer buying every new CS update, with a more predictable subscription revenue stream. In most cases, that revenue stream was also going to work out at more money per customer even for those customers who really were updating regularly before.
However, credible alternatives for simple uses or specialist niche markets were starting to appear and steal small amounts of market share within a few years, and they are growing in number, scope and awareness. Go read any online forum visited by creative people today, and you'll find a mix of sentiment between people who view Adobe as still the industry standard/800lb gorilla and people who have made the switch to alternatives and been happy with the results. You'll find plenty of comments from those who are upset by the CC subscription pricing, and plenty of comments from people who still use CS 5/5.5/6 and refuse to upgrade. You'll find plenty of comments from people asking what has really been added in all the time since CS6 to justify the upgrade and lock-in and all the extra cost, too, but few good answers.
Adobe are very cagey about breaking down their subscriber figures, even in their official reporting. For example, consider any recent call or regulatory filing or investor literature and try to work out whether subscriber numbers in North America or Europe or Asia are trending up or down. Try to work out whether the money is coming from new customers or long-standing ones. Try to work out whether it's big institutional customers paying the bills or small agencies and freelancers. In fact, try to identify where the money and growth are coming from in the subscription revenues in any sort of detail at all. Usually the best you get is a few carefully chosen highlights.
My suspicion -- though that's all it can be, given the above-mentioned lack of hard data -- is that Adobe will continue to do OK with subscriptions for a while, but they opened the door to much more serious competition and over time that will hurt them. It's possible that this is already happening but it's being masked for now by growth outside of their traditional markets. In any case, if they don't seriously up their game and produce real extra value in CC to justify the ongoing subscriptions, sentiment could start to shift, and if the momentum in the market starts going in the wrong direction, that nice-looking stock chart could become very ugly.
There's no digging into the OS, but most people don't want to do that anyway.
This is one of the biggest concerns I have about current trends in tech. Making systems simpler, easier to use and more secure is all good, but we're also losing the ability for average users to explore and automate and make their computers into tools and not merely platforms to run software that someone else wrote.
I've seen the look on the face of someone who isn't a "programmer" but has just learned some basic scripting that let them turn a regular all-morning job into a regular ten-minute job. It's a delight. But it only works if they have the ability to write those scripts and a basic understanding of how computers work so they can see what to do.
How is the next generation going to learn what computers can really do and how to take advantage of it to achieve benefits we haven't even thought of yet, if their computer has more power than anything any of us learned with and fits in their pocket, yet has no readily available programming tools so they can experiment and learn?
Computers can do far more to help us than just accessing social networks and watching Netflix, but we're in danger of dumbing them down and locking them down so much that this is all a whole generation will see.
There was no conjecture in my original comment. I acknowledged three specific possibilities, and implied that one of them was unlikely on the evidence so far.
What we need here isn't philosophical cliches or conjecture, it's facts, or at least possible explanations that are consistent with the evidence available and worth investigating.
Comments like that really aren't helpful at this stage, and could be deeply hurtful if any of the victim's friends or family read them. Please engage your brain before posting.
Or maybe there had been warnings earlier in the drive, as Tesla's statement says, but then there was insufficient warning immediately before the fatal collision.
We simply don't know yet, based on the information released so far, and what is needed in a situation like this is facts, not speculation.
The driver was given six seconds warning to take control, which is more than ample to react to an emergency situation.
Then given that this appears to have been an intelligent driver who was also aware of potential problems with the automatic control, we have to ask why that didn't happen. If we assume the driver didn't deliberately allow an accident to happen with tragic results, then evidently either something wasn't clear enough about the situation and what needed to be done, or something interfered with the driver's ability to act accordingly.
Yes, I'm talking primarily about privacy and reliability aspects. If Windows will deploy automatic, opaque updates on its own schedule and will send arbitrary information home to the mothership, then both for me personally and also for my businesses, nothing else matters because we already have two deal-breakers.
It's all very regrettable. I appreciated a lot of what Microsoft used to make, but sadly the Microsoft of recent years has proven to be a greater risk than any external threat I have yet encountered. As long as that remains the case, we will treat Windows 10 the same as any other malware and keep it off our networks.
To be fair, what I get if I buy a standard Windows PC today will be a worse experience than what I got 6 years ago if I bought a new PC with Windows 7, regardless of any new hardware changes. I would welcome a machine that can cope with bigger and higher-resolution screens, larger and faster disks, a faster CPU with more cores, faster and more reliable networking, and so on. Maybe not everyone needs those things, but I would find all of them useful. But if the price is putting up with an unreliable, untrustworthy OS from a developer who is actively working against me, it's just not worth it.
The PC market in my office would pick up tomorrow to the tune of several new machines, if I could buy them with an updated version of Windows 7 with support for the new hardware and (real) security fixes.
Slashdot Mirror
If it needs software to fix it, you must provide that software. It will create some extra burden on the manufacturer
One difficulty with that approach is that the software required for a third-party replacement component might be completely different to the software required for the component from the original manufacturer. What is really needed isn't necessarily like-for-like copycat products, it's modularity and compatibility. That means it's the specs and interfaces that really need to be standardised and disclosed, not so much the full set of code.
However, that supposes that the original manufacturer designed their components and software in a conveniently modular way. That is a significant restriction to impose that could have all kinds of unwanted side effects if you required it by law, including potentially making some useful products objectively worse than they could have been and/or significantly more expensive than they could have been, perhaps even to the point of not being viable at all in some cases. On the other hand, without such a legal requirement, this is a gaping loophole in the protections, since a manufacturer can just build monoliths deliberately and then argue that interoperability is irrelevant. That in turn would be balanced by meaning that of course the manufacturer couldn't then replace the same components themselves either, which could be good for their built-in obsolescence plans if that's how they want to work, but again isn't necessarily good for the end customer.
As I said, it's a tricky area to balance. There are good arguments on both sides, but sometimes the goals are mutually exclusive.
Car manufacturers are required to offer parts and the information necessary to make repairs to third parties.
This is going to be a tricky area to balance as we increasingly rely on complicated, software-supported systems.
With a physical product like a car, a mechanical part can be observed, measured and reproduced by a third-party repair supplier. If they're accurate enough, it will work just like the original.
As you get into software systems, there are going to be legitimate and difficult questions about how much disclosure should be required. It's good to ensure fair competition and avoid lock-in effects. However, this also imposes overheads on a business, even if that business otherwise provides and supports good products. Quite reasonably, the business doesn't want to end up responsible for supporting every third party's possibly sub-standard replacements.
I'm not sure there are any really good answers here. It might be a good start to mandate that businesses can't knowingly and actively interfere with third party replacement components, for example, by introducing a software kill switch whose main or only purpose is to brick a device if it doesn't have "official" components.
Maybe the time has also come to look again at the short warranties and support periods often offered for these expensive devices, and start imposing stricter rules about end-of-life, compatibility and data portability, and so on to bust some of the lock-in effects that way.
This is where it comes to sacrifices you make when you live somewhere like Silicon Valley, or most major tech hubs.
Is this a particularly US thing, I wonder? The city near me is Cambridge, UK, and it's one of the most cycle-friendly cities in the country, while also being a major tech hub. The Really Big City near me is London, and again there are a lot of cyclists and a lot of tech.
That said, yes, nobody should suffer an abridgement of the rights just because someone else is retarded.
Ideally, no, but such an arrangement is not always practical.
Consider something like traffic laws. I'm an experienced driver, with a good car and statistically a very good safety record. There is no doubt that under various conditions I could break various technical traffic laws, for example exceeding the speed limit or passing a red light, without causing any risk or inconvenience to anyone else. And yet the limits and restrictions apply to me just as they do to everyone else, and consequently the rules are unambiguous. That means a driver who breaks them under less favourable conditions can effectively be penalised, which is beneficial to society (including me). If you consider freedom of movement a right, this is clearly a restriction on my ability to move freely, but with a "greater good" justification.
To give a more obvious example, at the risk of mentioning a bad subject on a forum with many American members, there's a lot of debate about the right to bear arms under the US Constitution, but no-one would seriously suggest that just anyone should be able to buy a WMD, even if they did know perfectly well how to handle it safely. The potential consequences of abuse by one person are too great to trust any one other person with that kind of power.
This is an underrated argument. If everything was effectively DRM'd, we would have to find solutions that weren't painful for legitimate customers or for society as a whole. There would have to be some mechanism where fair use could actually, well, be used. There would have to be some mechanism to demonstrate who a legitimate rightsholder was to qualify for the DRM, so takedown mechanisms that can be abused today wouldn't need to exist in the same way. Copyright durations would have to be sensible and there would have to be a mechanism for ensuring works were properly released when the time came. If businesses adopted subscription models and then started hiking up prices once they'd got data locked in, we would soon have laws mandating data portability to promote fair and legal competition (much as the EU is now introducing with the GDPR, albeit for a slightly different reason).
Most of the problems with DRM aren't really problems with DRM, they're problems with DRM denying customers what they legitimately paid for, DRM denying society its side of the copyright bargain, or badly implemented DRM having negative side-effects that are nothing to do with IP rights, such as creating security vulnerabilities or privacy problems.
Of course, in practice such a system would be unworkable for a variety of reasons, but it's an interesting thought experiment along the lines of "What if copyright law were actually enforced robustly?"
You gain experience by doing. The more things you're doing, the less you're doing of each.
Again, that doesn't necessarily follow. HTTP is HTTP whether you're learning about it from the client or the server side. HTML and CSS are the same wherever you render them. Basic principles of software design. Techniques and judgement for writing good code. Testing strategies. Many, many things are not so different just because of this (IMHO quite artificial) distinction between back-end and front-end development.
The differences tend to be in little things like which specific tools you use, but in the long run those are rarely the important details. Even when they are, picking up a new tool when you've used five similar ones before isn't something that takes months.
I think a person with one year would have to be pretty exceptional in some other respect to get hired over the one with five.
Sure, but in a way that's my point. The difference between someone with one year of experience using, say, React, and someone with five years of experience is unlikely to be how well they understand React itself. Both could easily understand its full API, how to write components in various ways, what the different lifecycle functions are for, and so on. The difference is going to be in other areas, like how well they design their overall system, or how clean and flexible their data models are, or their judgement about where to apply optimisations and understanding of other tools that could provide objective data to guide that process.
Many of these other concerns won't be specific to React itself, or even to front-end development. Again, to the extent that they are, it's likely to be a relatively small and quickly learned relationship. Knowing what shouldComponentUpdate is for or how to turn on React's own performance diagnostics is less important than knowing why there might be a bottleneck in the first place or being aware of the possibilities of using a profiler to guide optimisation work.
They have. It's not webscale because it uses joins.
Maybe you should use MongoDB. I hear MongoDB is web scale.
But that is their problem?
When the legalese is so long and cumbersome that it would be literally impossible for any normal person to read, understand and actively give informed consent to it, yes, I think it is their problem.
We've got into this strange situation with online services where there is this fantasy legal environment where everyone is signing up for things with these huge accompanying documents that they have supposedly read and agreed to, when those documents might contain terms that have very little to do with what the person thought they were signing up for.
Just imagine the bricks-and-mortar equivalent of what is supposedly happening with online purchases: you get to the checkout at the store with your groceries, spend a couple of minutes getting everything scanned and bagged up, and just before you tap your contactless card to conveniently pay for it in a few more seconds, you have to stop and spend an hour reading 27 printed pages of legal terms including how you may serve the beef, removing any responsibility from the store if your pack of fresh vegetables is half-rotten behind the packaging you can't see through, promising to pay the store's legal costs if anyone else who was in that day falls and hurts themselves but mentions your name while they're suing the store for damages, giving up your own right to take normal legal actions against the store in favour of some obviously not loaded at all "arbitration" process, and agreeing to let someone from the store visit your house whenever they want to check what's in your fridge and then stand in your lounge offering your whole family replacement products they think might interest you that are available from their carefully selected partners. It's absurd on so many levels.
Perhaps the greatest irony is that, at least in places with sensible legal systems, a lot of the legalese is mostly worthless anyway, because if there is something surprising and unreasonable in a standard form contract like this then it's unlikely to stand up in court anyway.
10 years experience in 4 things. So effectively only 2 to 3 in each.
That's not really how it works. You can be gaining experience with more than one thing during the same period.
Moreover, skills and understanding in related fields aren't independent. Learning one when you already have experience of another will often be faster. There will also be significant overlaps where the same knowledge or technique is relevant in multiple contexts.
It's also relevant that the learning curve for these technical fields is typically steepest at the start, with additional experience getting diminishing returns once a certain level of competence is achieved. If someone can understand the basics of a certain tool within a couple of days and master it within a couple of weeks, it doesn't matter whether they have one year or three years or five years of experience with that tool, their capability is still going to be much the same in that respect.
And bear in mind that experience decays.
To some extent yes, but mostly if you're not actively using the skills for an extended period. And even then, the underlying principles, which are the most valuable things you learn with experience, tend to last much longer than the details of some ephemeral tool.
That database you use is now two cycles out of fashion.
Unless all your understanding of relational databases and SQL have gone out of fashion as well, that's not a problem. You just learn the surface details of whichever specific database engine you need to use for your current work, and get on with the job using the rest of your skills and understanding that carried over anyway. Likewise if you've used one NoSQL database but this time your colleagues have chosen a different one, and so on.
If thats true then everyone over 40 who has been employed since they were in their 20's is a friggin unicorn... But a 'unicorn' is someone who contributes something 'unique'.
I'm not sure your preferred usage matches how most people use that word, but in any case, a lot of people who have 20+ years of professional experience and have continued their own professional development throughout certainly would qualify either way. It's difficult to do diverse work for that long and be paying attention without acquiring both a broad spread of knowledge and a lot of depth in some specialised areas.
Probably no-one is completely equal at everything they do. But it's not difficult to imagine someone with 10 years of experience who can do both front-end and back-end programming to a very high standard, and who also understands databases and infrastructure well enough to do everyday tasks themselves and to communicate intelligently with someone more specialised in those fields if necessary.
I've found so many people simply don't want to learn new things.
I agree with you, but I think that's only one part of the problem. Another part is that so many relatively inexperienced web developers today are learning the wrong new things. They buy into the hype and so focus on learning the details of one short-lived tool after another, instead of developing their more fundamental skills that will go far deeper and last far longer.
Developers often talk about needing to use tools they can take from one job to another so their careers don't stagnate, but these tools rarely last long enough in the spotlight to be valuable for more than one or two job moves anyway, and then all those skills and buzzwords are worth almost nothing.
Employers often talk about needing to hire people who can hit the ground running with Supreme Master Framework 1.7.3, but a generally competent developer with knowledge of JS can pick up a typical UI framework or library within a matter of days if not hours anyway, and then they'll still be more capable than a framework monkey.
If web developers learned more substantial development skills instead of obsessing over superficial resume-building with one trendy buzzword after another, then in the long run they'd be able to achieve far more, faster and with better quality results. And if more employers had sensible recruitment practices that focussed on those people instead of requiring silly resume padding just to get past the HR keyword scans, they'd have a much more capable workforce.
It's hard to blame the junior developers for getting caught in this trap, because I think a lot of it is driven by the buzzword bingo recruitment practices of too many employers, and the potential employees are just playing the game by the rules that have been set. But there are more enlightened employers out there too, and if you understand real development instead of just colouring by numbers with this week's framework, you also have options for branching out on your own.
As the saying goes, there is a difference between having ten years of experience and having one year of experience ten times.
A "unicorn" is mostly just someone who's been around for more than a few years and kept learning in a broad range of areas. There are plenty out there.
Some employers have trouble with wanting unicorns but only having the budget for newbies, but that's an entirely different problem.
And I agree with you in turn, but I think that also creates opportunities for smaller, more flexible organisations to do better. Corporate IT thinking it's there to be in charge is a recurring failure mode in large businesses, and they deserve everything they get if they don't fix that problem.
As I wrote before:
In this case, there is nothing so far to suggest the driver deliberately failed to act
And again, given that the driver was an Apple engineer, it would be very surprising if he were not intelligent and competent. That's not conjecture, just drawing a reasonable inference from the facts we do have.
This whole self drive thing seems way to wild wild west, where a developer goes, hey this would be cool, and adds it to the system. A system that is driving in the real world with real consequences.
Indeed. It is hard to imagine an environment where the SV mantra of "move fast and break things" is less appropriate, both literally and figuratively.
Not really. Conjecture implies guesswork and the drawing of some conclusion without reasonable evidence, like arth1's vague and entirely unsupported innuendos. In this case, there is nothing so far to suggest the driver deliberately failed to act, while there are several points known of his character and past behaviour that look inconsistent with someone who would then deliberately fail to take avoiding action in this situation. I very carefully stated that as an assumption rather than a firm conclusion, and having done so, it is logical to focus on the other possible explanations.
In any case, neither you nor arth1 (assuming you aren't the same person) is adding anything useful to this discussion, so I'm going to stop here.
Grudgingly accepted is good enough for their bottom line to be happy, sadly.
True, but the sustainability of a strategy based on grudging acceptance is always uncertain.
Of course when Adobe went to CC that was commercially good for them in the short term. They replaced intermittent revenue from customers, many of which were no longer buying every new CS update, with a more predictable subscription revenue stream. In most cases, that revenue stream was also going to work out at more money per customer even for those customers who really were updating regularly before.
However, credible alternatives for simple uses or specialist niche markets were starting to appear and steal small amounts of market share within a few years, and they are growing in number, scope and awareness. Go read any online forum visited by creative people today, and you'll find a mix of sentiment between people who view Adobe as still the industry standard/800lb gorilla and people who have made the switch to alternatives and been happy with the results. You'll find plenty of comments from those who are upset by the CC subscription pricing, and plenty of comments from people who still use CS 5/5.5/6 and refuse to upgrade. You'll find plenty of comments from people asking what has really been added in all the time since CS6 to justify the upgrade and lock-in and all the extra cost, too, but few good answers.
Adobe are very cagey about breaking down their subscriber figures, even in their official reporting. For example, consider any recent call or regulatory filing or investor literature and try to work out whether subscriber numbers in North America or Europe or Asia are trending up or down. Try to work out whether the money is coming from new customers or long-standing ones. Try to work out whether it's big institutional customers paying the bills or small agencies and freelancers. In fact, try to identify where the money and growth are coming from in the subscription revenues in any sort of detail at all. Usually the best you get is a few carefully chosen highlights.
My suspicion -- though that's all it can be, given the above-mentioned lack of hard data -- is that Adobe will continue to do OK with subscriptions for a while, but they opened the door to much more serious competition and over time that will hurt them. It's possible that this is already happening but it's being masked for now by growth outside of their traditional markets. In any case, if they don't seriously up their game and produce real extra value in CC to justify the ongoing subscriptions, sentiment could start to shift, and if the momentum in the market starts going in the wrong direction, that nice-looking stock chart could become very ugly.
There's no digging into the OS, but most people don't want to do that anyway.
This is one of the biggest concerns I have about current trends in tech. Making systems simpler, easier to use and more secure is all good, but we're also losing the ability for average users to explore and automate and make their computers into tools and not merely platforms to run software that someone else wrote.
I've seen the look on the face of someone who isn't a "programmer" but has just learned some basic scripting that let them turn a regular all-morning job into a regular ten-minute job. It's a delight. But it only works if they have the ability to write those scripts and a basic understanding of how computers work so they can see what to do.
How is the next generation going to learn what computers can really do and how to take advantage of it to achieve benefits we haven't even thought of yet, if their computer has more power than anything any of us learned with and fits in their pocket, yet has no readily available programming tools so they can experiment and learn?
Computers can do far more to help us than just accessing social networks and watching Netflix, but we're in danger of dumbing them down and locking them down so much that this is all a whole generation will see.
There was no conjecture in my original comment. I acknowledged three specific possibilities, and implied that one of them was unlikely on the evidence so far.
What we need here isn't philosophical cliches or conjecture, it's facts, or at least possible explanations that are consistent with the evidence available and worth investigating.
Comments like that really aren't helpful at this stage, and could be deeply hurtful if any of the victim's friends or family read them. Please engage your brain before posting.
Or maybe there had been warnings earlier in the drive, as Tesla's statement says, but then there was insufficient warning immediately before the fatal collision.
We simply don't know yet, based on the information released so far, and what is needed in a situation like this is facts, not speculation.
The driver was given six seconds warning to take control, which is more than ample to react to an emergency situation.
Then given that this appears to have been an intelligent driver who was also aware of potential problems with the automatic control, we have to ask why that didn't happen. If we assume the driver didn't deliberately allow an accident to happen with tragic results, then evidently either something wasn't clear enough about the situation and what needed to be done, or something interfered with the driver's ability to act accordingly.
Yes, I'm talking primarily about privacy and reliability aspects. If Windows will deploy automatic, opaque updates on its own schedule and will send arbitrary information home to the mothership, then both for me personally and also for my businesses, nothing else matters because we already have two deal-breakers.
It's all very regrettable. I appreciated a lot of what Microsoft used to make, but sadly the Microsoft of recent years has proven to be a greater risk than any external threat I have yet encountered. As long as that remains the case, we will treat Windows 10 the same as any other malware and keep it off our networks.
To be fair, what I get if I buy a standard Windows PC today will be a worse experience than what I got 6 years ago if I bought a new PC with Windows 7, regardless of any new hardware changes. I would welcome a machine that can cope with bigger and higher-resolution screens, larger and faster disks, a faster CPU with more cores, faster and more reliable networking, and so on. Maybe not everyone needs those things, but I would find all of them useful. But if the price is putting up with an unreliable, untrustworthy OS from a developer who is actively working against me, it's just not worth it.
The PC market in my office would pick up tomorrow to the tune of several new machines, if I could buy them with an updated version of Windows 7 with support for the new hardware and (real) security fixes.