Tell those interviewers that you've intentionally decided not to be a "people manager," because you are an outstanding individual contributor, passionate about the technology.
On the flip side, leadership skills (as opposed to people-management skills) are indeed important to software developers. You have to know how and when to:
- Push back against questionable requirements from a client (tactfully) - Advocate your point of view - Not wilt in the face of authority - Rally the other members of your dev team around an idea - Speak your mind in the middle of a heated meeting
While NYC was at fault here, why sleep with a potential wake-up-machine next to you? Next time it won't be an Amber alert, but a drunk buddy who's lost track of the time. Why risk it?
Google Glass will be yet another form of distraction for drivers. By and large, people cannot attend to a close-up display and a far-off traffic situation at the same time. It's a limitation of human attention. The more Google Glass on the road, the more death.
In the late 1980s, I was the sysadmin of a large Unix server at a well-known university, when suddenly the server stopped accepting logins. It seems that the password file (/etc/password) had gotten corrupted. The reason? A well-meaning graduate student had suspected a security flaw and decided to "try it out" to confirm it and then report it. His heart was in the right place, but his judgment was total stupidity: he corrupted a running server used by dozens of scientists "to see if it would work." If he had just stopped by my office and ASKED (we knew each other well), we could have checked for the flaw safely.
So I have a little sympathy for Mr. Al-Khabaz, but he did exercise very poor judgment in running Acunetix.
The best motivation for a hacker is the respect of more experienced/legendary hackers in the company. When some IT God stops by my cube, looks at my work and says, "Holy sh*t, that's amazing: how did you do it?" that feeling beats 1000 "cake days."
We've lost the basic ability to store and process email. Back when we all used terminals connected to one big computer (Unix, etc.), it was clear where your mail lived: in specific files. You could access it from anywhere (via modem), and you could process it with tools (grep, sed, etc.), use "tar" to back it up, encrypt it with PGP, or basically do whatever you wanted with it, effortlessly. It was YOURS.
Nowadays, half your email lives on a remote IMAP server: accessible from anywhere, but inaccessible to your local tools, and if your mail provider ever gets shut down, you could lose it all. The other half lives in local mailboxes on your desktop or laptop, accessible only when you're physically next to the machine. Or worse, if you use two desktops (one at work, the other at home), you might have local mailboxes on each, making it impossible to do a full search of your email. Some people work around this by carrying a thumbdrive and putting all local mail folders on it... but then you have to back up the thumbdrive, etc.
This is why I download all email from my ISP to a Linux machine at home (via fetchmail), access it via OpenSSH, and read it in emacs, or run a local IMAP server. This provides all the benefits of the old "terminals" model. The downside is you have to be a computer wizard to set it up.
Google is your friend. You have the name of the scientist. Go check out the papers and read 'em!
As for your claim, "In real life, the majority of people WILL stop talking if they need to concentrate for a busy intersection / dangerous road and if there's an "OH SHIT!" situation, they won't keep holding the phone".... You've missed the point entirely. If you enter an "oh shit" situation while on the phone, you will NOTICE THIS MORE SLOWLY. That is what the research says: your reactions are delayed due to distraction. And then it's too late to drop your phone.
That's a fine opinion, but look at the research. The data don't agree with you. Driving while talking on a cell phone turns out worse than all the things you mention, when actually measured. There seems to be something special about the way the brain handles a phone conversation that impairs the ability to multitask more severely.
I'd love to see this happen. Just yesterday, I watched the driver in front of me smash his car through a fence into someone's backyard. He'd been on the phone. If someone had been in the way at the time, they'd be dead.
Unfortunately, the same corporate CEO's who make calls in their cars also buy congresspeople, so I think the odds are slim this kind of legislation would pass.
Digital photos and music organized in simple folders/directories: photos by date, music by artist & album
Computer files (25 years' worth) organized into directories on Linux PC by topic. Nightly cron job does "find ~ -print > ~/ALLFILES" so I can find any filename with a quick grep. Backups to two 2 TB portable drives, swapped monthly into a safety deposit box.
Job stuff organized in Outlook Calendar at work... and kept at work. Don't bring the job home at night if you can help it.
Social calendar kept by spouse.:-)
Truly important stuff kept in safety deposit box.
That's basically it. No "smart phone", no iWhatever gadgets, no portable electronics. I prefer my machines to sit in one place so I can walk away from them.
This isn't addiction, any more than watching too much TV is addiction.
I've been using the Internet daily for decades but can (and do) walk away from it, completely, for vacations etc., without any difficulty. It's actually nice to get away.
Calling something an "addiction" takes away personal responsibility. That's appropriate for truly addictive substances (when you're chemically dependent) but not for sitting on your ass in front of a computer.
>"...after all linear algebra is no help when building database driven websites...."
Unless the web site is totally trivial, you definitely want math skills. Any programmer who can't estimate the runtime of an algorithm (say, several interacting, nested loops) doesn't get a place on my project. And combinatorics & graph theory are a very good idea for any interesting web software. And how the heck can you build a data structure of any complexity without understanding how fast you can insert, delete, and find members?
I'm sure there are thousands of mediocre developers who don't think about these issues and just build stuff that seems to work.
No matter which provider you choose, never depend on them for backups. Keep your originals locally and copy them to the webserver. Rsync is a great, effortless tool for this kind of synchronization. If you're maintaining SQL databases on the webserver, back them up at least daily with cron and download the backups. A few simple scripts will work wonders for your protection and your sanity.
This was clear copying, all the way down to the comments. Literally 100% identical code.
There are various ways to proceed in this case, but the parent article's claim (a sufficiently harsh punishment is all you need) isn't one of them.
It wasn't a "difficult case." I was merely responding to the parent article, which claimed that a sufficiently harsh punishment solves the problem. I was presenting a counterexample.
You're saying that a different approach solves this particular case. That's true, but not what I was writing about.
It's not quite that easy (speaking as a long time CS teacher). For example, once I found that two of my students had turned in the identical assignment. They did not know each other, so one clearly swiped the other's work. Neither would admit wrongdoing, they both understood the code, and there were no timestamps to check. With an expulsion policy, what do you do? Either expel them both (not fair, you're punishing an innocent person) or break your own policy (looking inconsistent, which weakens the policy).
The hard part about dealing with cheating is the borderline cases.
Squeezeboxes are AMAZING. I have 7 of them in my home, and with a few button-presses, they can all be synchronized for whole-house audio. Also the server is open-source (Perl) and you can create your own plug-ins. I'm using plug-ins for faster search, logging of all tracks played, and creation of sync groups (so with one press, you can, say, set all your upstairs squeezeboxes to play one tune and all the downstairs ones another tune).
Some squeezeboxes have built-in speakers (the Boom) and others require a stereo system. I have never regretted buying them.
For the ultimate in space-efficiency, you can connect a speakerless squeezebox (e.g., the Classic) to a tiny in-wall amplifier (www.wireless-experts.com) that fits into a lightswitch box, connected to wall-mounted speakers. All people see is the squeezebox, the speakers, and a volume knob on the wall. Nice.
Slashdot Mirror
Them: "Mind if I yak on my cellphone in this enclosed space?"
You: "Mind if I fart?"
Tell those interviewers that you've intentionally decided not to be a "people manager," because you are an outstanding individual contributor, passionate about the technology.
On the flip side, leadership skills (as opposed to people-management skills) are indeed important to software developers. You have to know how and when to:
- Push back against questionable requirements from a client (tactfully)
- Advocate your point of view
- Not wilt in the face of authority
- Rally the other members of your dev team around an idea
- Speak your mind in the middle of a heated meeting
While NYC was at fault here, why sleep with a potential wake-up-machine next to you? Next time it won't be an Amber alert, but a drunk buddy who's lost track of the time. Why risk it?
Google Glass will be yet another form of distraction for drivers. By and large, people cannot attend to a close-up display and a far-off traffic situation at the same time. It's a limitation of human attention. The more Google Glass on the road, the more death.
In the late 1980s, I was the sysadmin of a large Unix server at a well-known university, when suddenly the server stopped accepting logins. It seems that the password file (/etc/password) had gotten corrupted. The reason? A well-meaning graduate student had suspected a security flaw and decided to "try it out" to confirm it and then report it. His heart was in the right place, but his judgment was total stupidity: he corrupted a running server used by dozens of scientists "to see if it would work." If he had just stopped by my office and ASKED (we knew each other well), we could have checked for the flaw safely.
So I have a little sympathy for Mr. Al-Khabaz, but he did exercise very poor judgment in running Acunetix.
The best motivation for a hacker is the respect of more experienced/legendary hackers in the company. When some IT God stops by my cube, looks at my work and says, "Holy sh*t, that's amazing: how did you do it?" that feeling beats 1000 "cake days."
We've lost the basic ability to store and process email. Back when we all used terminals connected to one big computer (Unix, etc.), it was clear where your mail lived: in specific files. You could access it from anywhere (via modem), and you could process it with tools (grep, sed, etc.), use "tar" to back it up, encrypt it with PGP, or basically do whatever you wanted with it, effortlessly. It was YOURS.
Nowadays, half your email lives on a remote IMAP server: accessible from anywhere, but inaccessible to your local tools, and if your mail provider ever gets shut down, you could lose it all. The other half lives in local mailboxes on your desktop or laptop, accessible only when you're physically next to the machine. Or worse, if you use two desktops (one at work, the other at home), you might have local mailboxes on each, making it impossible to do a full search of your email. Some people work around this by carrying a thumbdrive and putting all local mail folders on it... but then you have to back up the thumbdrive, etc.
This is why I download all email from my ISP to a Linux machine at home (via fetchmail), access it via OpenSSH, and read it in emacs, or run a local IMAP server. This provides all the benefits of the old "terminals" model. The downside is you have to be a computer wizard to set it up.
Anyone building a new house, who doesn't wire it with CAT-6 or similar while the walls are open, is nuts.
I wired my existing house (built in 1899) and have never regretted the expense. (When's the last time you ever heard, "Shit, the wired is down"?)
Google is your friend. You have the name of the scientist. Go check out the papers and read 'em!
As for your claim, "In real life, the majority of people WILL stop talking if they need to concentrate for a busy intersection / dangerous road and if there's an "OH SHIT!" situation, they won't keep holding the phone".... You've missed the point entirely. If you enter an "oh shit" situation while on the phone, you will NOTICE THIS MORE SLOWLY. That is what the research says: your reactions are delayed due to distraction. And then it's too late to drop your phone.
That's a fine opinion, but look at the research. The data don't agree with you. Driving while talking on a cell phone turns out worse than all the things you mention, when actually measured. There seems to be something special about the way the brain handles a phone conversation that impairs the ability to multitask more severely.
Don't take my word for it. Read the research.
Talking on a cell phone while driving increases your risk of an accident by 400%.
http://www.psych.utah.edu/lab/appliedcognition/
This isn't about some individual reckless drivers talking on the cell phone. It's a limitation of our brains.
No, but they're the only ones who can afford to buy congresspeople. :-)
Let X = the number of people who are captured in the car.
Let Y = the number of accidents caused by cell phone distraction.
Do you really think X is higher than Y? I'll bet Y is two orders of magnitude higher than X, at least.
The data show that your risk of an accident increases while 4x when you're on the phone.
http://www.psych.utah.edu/lab/appliedcognition/
This has nothing to do with "misuse." It's a human limitation.
Just pull over, stop the car, and make the call. That's what I did in the "crash through the fence" incident I described.
I'd love to see this happen. Just yesterday, I watched the driver in front of me smash his car through a fence into someone's backyard. He'd been on the phone. If someone had been in the way at the time, they'd be dead.
Unfortunately, the same corporate CEO's who make calls in their cars also buy congresspeople, so I think the odds are slim this kind of legislation would pass.
That's basically it. No "smart phone", no iWhatever gadgets, no portable electronics. I prefer my machines to sit in one place so I can walk away from them.
This isn't addiction, any more than watching too much TV is addiction. I've been using the Internet daily for decades but can (and do) walk away from it, completely, for vacations etc., without any difficulty. It's actually nice to get away. Calling something an "addiction" takes away personal responsibility. That's appropriate for truly addictive substances (when you're chemically dependent) but not for sitting on your ass in front of a computer.
Unless the web site is totally trivial, you definitely want math skills. Any programmer who can't estimate the runtime of an algorithm (say, several interacting, nested loops) doesn't get a place on my project. And combinatorics & graph theory are a very good idea for any interesting web software. And how the heck can you build a data structure of any complexity without understanding how fast you can insert, delete, and find members?
I'm sure there are thousands of mediocre developers who don't think about these issues and just build stuff that seems to work.
No matter which provider you choose, never depend on them for backups. Keep your originals locally and copy them to the webserver. Rsync is a great, effortless tool for this kind of synchronization. If you're maintaining SQL databases on the webserver, back them up at least daily with cron and download the backups. A few simple scripts will work wonders for your protection and your sanity.
This was clear copying, all the way down to the comments. Literally 100% identical code. There are various ways to proceed in this case, but the parent article's claim (a sufficiently harsh punishment is all you need) isn't one of them.
It wasn't a "difficult case." I was merely responding to the parent article, which claimed that a sufficiently harsh punishment solves the problem. I was presenting a counterexample. You're saying that a different approach solves this particular case. That's true, but not what I was writing about.
If your students were so lazy that they didn't read the assignment & notes carefully, shouldn't they get an A?
It's not quite that easy (speaking as a long time CS teacher). For example, once I found that two of my students had turned in the identical assignment. They did not know each other, so one clearly swiped the other's work. Neither would admit wrongdoing, they both understood the code, and there were no timestamps to check. With an expulsion policy, what do you do? Either expel them both (not fair, you're punishing an innocent person) or break your own policy (looking inconsistent, which weakens the policy). The hard part about dealing with cheating is the borderline cases.
Squeezeboxes are AMAZING. I have 7 of them in my home, and with a few button-presses, they can all be synchronized for whole-house audio. Also the server is open-source (Perl) and you can create your own plug-ins. I'm using plug-ins for faster search, logging of all tracks played, and creation of sync groups (so with one press, you can, say, set all your upstairs squeezeboxes to play one tune and all the downstairs ones another tune). Some squeezeboxes have built-in speakers (the Boom) and others require a stereo system. I have never regretted buying them. For the ultimate in space-efficiency, you can connect a speakerless squeezebox (e.g., the Classic) to a tiny in-wall amplifier (www.wireless-experts.com) that fits into a lightswitch box, connected to wall-mounted speakers. All people see is the squeezebox, the speakers, and a volume knob on the wall. Nice.