I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.

As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.

Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.

Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.

I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.
As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.

Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.

Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.

Here are some good practices for developers:
1. When a bug is reported in a group project, there are 2 types of people.
1.1 Without any investigation, a developer declares that it isn't his/her problem.
1.2 A developer who assumes it might be his/her problem and starts investigating.
I certainly prefer the latter. This isn't about ego, it's about code doing its intended job.
2. Developing always creates bugs.
Prolific developers create lots of bugs.
Developers should not be judged on the number of bugs.
Instead, they should be judged on the ratio of bugs versus the amount of code they produced.
A corollary to the above is that good developers create a minimum of code for a given requirement. More code = more bugs.
Beware of developers who create complex solutions to not-so-complex problems.
3. If your ego is so fragile that you cannot handle making mistakes, you are in the wrong job.
As long as you are creating code, you will always make mistakes.
The key thing is to find techniques/procedures to avoid making the same mistake ever again.
4. Good developers assume something will go wrong in their code and put in more code to handle "unexpected" scenarios.
When something fails, it is really good to have it not fail badly.
5. Test, test and test again. Never assume anything works properly.
I have had code fail several times after many years in production.
It took all that time before the circumstances were sufficient to trigger the obscure bug.
This also ties in with point # 1 above, it is very easy after a few years of success to assume it is bug-free, when it isn't.
6. NEVER stop learning.
You can always improve.
7. With so many opportunities for self-education, learn to choose the most useful ones.
Learning the intricacies of one niche application will cause you to be good at that job, but what happens if that job ends?
A resume of widely-used skills is good for employment longevity.
8. MOST IMPORTANT.
Love what you do. Take pride in your work.
If you don't love what you do, find a new job.
You cannot pay someone to take pride in their work, but you can reward them for doing it.

The US tax code documents would seriously challenge Ms. Linda Watson.
Not because you cannot read the actual words, more because you cannot understand their meaning.
Same with most government documents from just about any government.

Instead of voting for a representative, why not use computers to allow any registered voter to directly vote on bills?
We needed representatives long ago when communications were poor.
Quality communications should make these corrupt representatives obsolete.
You could exercise your right to vote on bills that you had a strong opinion about and ignore others that you didn't care about.

I retired at 59 after almost 40 years of software development, culminating in 10 years being part of a great team of people developing an algorithmic high speed trading system on wall st. I max-ed out my 401k every year and retired fairly early with enough money to live frugally (relative to previous lifestyle).
I now live in a quiet waterfront home surrounded by farmland.
I go crabbing and have caught 1502 crabs so far this season.
I roast coffee as a loss-making hobby/business. I wrote some custom software for my coffee business that tracks everything and even is hooked via a thermocouple on my roaster to record roasting profiles.
I traded a horrible commute for the following stress-free early morning ritual. On warm mornings, I drink coffee on my dock and watch the wildlife. On cold mornings, I drink coffee in my outdoor hot tub and watch the wildlife.
I tell my kids about the tortoise and the hare: the hare (almost) never wins. Slow and steady rocks.
So this is what can happen when a programmer gets old. Persevere and good fortune will happen. Good luck to you all.

If someone alters a sign, it might trick a robot. Then again, it might trick a human too. So what's the difference?

Extrapolation of these results predicts that employees who work a 0 hour week will never take any sick days and will be extremely happy.
As a person in retirement, I can vouch for these results.

As someone who developed algorithmic and high frequency trading software, I fully agree that he is being singled out.
This guy was only doing what many of the large financial houses were and still are doing.

No pair of communications devices "has to share that information".
Data passed between my wireless mouse and my PC hopefully isn't sent to Logitech or Dell.
Data passed between my phone and my bluetooth speaker hopefully isn't sent to Bose or Verizon.
This data is sensitive enough that it should not be shared.

How can we be sure you are real and not some chatbot?

I suppose Hilary's private email server has saved her from being published by Wikileaks.
A previous poster suggested something incriminating would catapult Sanders into the DNC nomination spot.
If nothing actually incriminating is found, but something unfavorable is revealed, that would then help The Donald.

I'm glad to see iOS/2 is still alive. Then again, I suppose I am biased as I worked on OS/2 for IBM a very long time ago. I thought it looked very good versus the competition (Win3). Being a huge fan of open source, I have been using Linux for a very long time now. In fact I have always preferred Unix variants over anything else almost since I started working 45 years ago. It was a breath of fresh air versus IBM mainframes where I started.

Nor did I have sex with these emails.

Wouldn't it be nice (a naive thought) if we had a politician who:
1. We could trust
2. Put the country's best interest above his/her own
3. Wasn't in the pockets of the rich

Instead we have trump and clinton.
Maybe they should get married.
They both are the exact opposites of points 1 thru 3 above.

I wonder why people are feeling they are not represented?

It's not what you know that will necessarily get you a new job.
It's not who you know that will necessarily get you a new job.

It's both plus having the ability to communicate in a reasonable manner.

When you are "experienced" and have quite a few years of development behind you, a decent developer will have built up a list of friends from previous or current jobs. Hopefully, these friends respect your ability to develop. When it comes time to obtain a new job, hitting up those friends is an invaluable resource. I have hired several colleagues from previous encounters in this manner. I have even hired the same guy twice. Each time I moved jobs, I pulled him in behind me. I have also been hired twice thru personal references myself.

Just think about it. Do you think an interview is much more than a crapshoot? You are trying to judge the suitability of a candidate based upon a few hours of interaction. Wouldn't you rather judge someone based upon their past performance of which you (or a friend you trust) are familiar, having previously worked with them?

I'm not saying that an old dog shouldn't learn new tricks. Far from it. It's every developer's responsibility to maintain their skill set. I am extolling the virtues of building a network of past/current colleagues who might be of help to you in the future, just as you might be of help to them.