I haven't seen the movie, but the book is one of my favorites. One of the things that worries me is that the book is one of those rare, so self-contained and complete pieces of art that it seems anything added or deleted -- even a single word -- could spoil it.
...in a personal sense, that is. I go out of my way to avoid offending others on very personal topics like religion. Not because I'm afraid, but because I want to be a nice guy:) As a citizen of a republic, however, I support the right of free speech, even offensive speech. In fact, offensive or unpopular speech in particular needs to be protected: there's neither need nor reason to protect the speech people want to hear.
In my experience, a huge fraction of the marketing surrounding any IT fad is the promise that it will magically erase or prevent technical debt. This is attractive because in many ways technical debt is THE great unsolved problem of software engineering. TL;DR there is no magic bullet; the only solutions are craftsmanship and paying the technical debt up front. Unless management understands this, no IT fad will ever solve the problem.
and similar publications like Computer Language, the (old-school) Byte, etc., I would likely not be a programmer today. I feel as though a mentor had passed on.
I live in a small town / large village, and I would love to do without a car, but it's just not practical. The town is at an uncomfortable size where it's too large to walk to many places, but too small to make public transit feasible. What would help the most, I think, is some kind of "lane management." It's too dangerous to use the highways as they are now configured with bicycles, motor-scooters, or motor-carts -- though these would suffice for most tasks. If this were made safer, it would be more feasible to rely only on rental cars for longer trips. The city council has taken steps to add bike lanes, and has just approved the use of electric motor carts. These are steps in the right direction, but we've got a ways to go. Still, I like the idea of being able to give up owning a car -- and not just for some green / altruistic reason -- I just don't want the bother.
For a while I lived in Florida and traveled back and forth to "the Bay Area" (at company expense). My take:
I wish I could LIVE in the Bay Area but pay housing and taxes based on the costs in Florida. So I'd advise you to decide what's most important to you: 1) your current lifestyle or 2) putting money aside. There is also a up/downside professionally. The opportunities for professional networking and continuing education are greater in the Bay Area. On the other hand, the competition is a lot stiffer. I think if I could get the pay, adjusted for region, to within about 25%, I'd probably take the Bay Area, but life is what you make it wherever you decide to make it.
According to people like Freud and Campbell, every "technology-out-of-control" fear from Frankenstein on down is just a reflection of the male's fear of his own offspring.
Whenever the toilet backs up, I always think of the rising water scene in the Sorcerer's Apprentice. There's something primordial about watching the water rise up, and realizing you're the one who summoned it, that makes you chant “stop, stop, stop...” as it rises towards the rim and begins to cascade over.
And then you run for the mop and plunger.
It's the same old story, except technology just keeps making the toilet bigger and bigger.
Yep, the problem is not in you *should* do, it's what you *have* to do to actually take care of people. Imagine being a programmer making half or less the effective hourly rate of other average engineers. Having to master dozens of APIs. Working 60 hours a week at random. Filling out paperwork in addition to engineering tasks.
And if you code just one bug, you may be toast. Not the program, *you*, you're toast.
That's what the nurses I know tell me their job is like.
I'm sure there are incompetent nurses, but the working conditions tax the competence of even the best,
that the downfall of our race was caused by our absolute insistence on basing everything: human relationships, law, economics, etc. on passive entertainment. Maybe this really is (as some have asserted) SETI's great cosmic filter.
The most important thing about Watson is what is least understood by the non-technical press: standards like the UIMA that allow disparate analysis applications to be developed independently and run in parallel. Picture a city full of nice shops and houses connected by muddy, weed-choked trails; that's what Watson would be without framework standards.
I can second this. I have some experience with the Kynect product. There were (and still are), a few glitches, but these seem to be relatively minor. One key factor in the success was training and supporting "Kynect-ors" in helping people use the site. These "Kynect-ors" had also had priority access to varying levels of technical support to help iron out glitches when they did occur. Nothing's ever perfect in politics, healthcare, or programming, and I'm sure there are a few "horror stories," but overall, the Kynect roll-out was very impressive.
I would have studied more about the history of computers and computer science. It would have kept me from re-making so many mistakes and re-inventing so many wheels.
Oddly enough, I can agree with ALL the comments above. I did eventually take a management role, to fill a void after a manager quit. As a manager, I did try to make my role that of smoothing things out and enabling the remaining engineers to work more effectively. And yes, I disliked it and got back into engineering as quickly as possible. Seeing all those engineers working day after day made me jealous, and I just had to get back to hands-on work. We ended up hiring a top-notch ex-engineer from another company who had moved into management and liked it. He was probably the best, but toughest, manager I ever worked with.
I once worked for a boss who repeatedly said: "We need to get you into management so I can pay you more." The odd thing was, he said this because he liked me, and really did want to pay me more. Yet since he owned the company, he could have paid me any salary he wanted, regardless of my job title. He just had this fixed idea that no engineer should be paid more than any manager who supervised multiple engineers.
...could eliminated by removing copy and paste. Most of my bugs seem to happen when a block of code is not quite DRY-able, I copy-paste-modify the block, and then miss some small detail. (Of course, eliminating copy and paste would also reduce my coding speed by about 90%, so I guess it all evens out.)
I tend to work on two sets of code. The first set is the code currently under formal development. The second set is the code that will actually be needed at the end of the project when every figures out what we were really trying to build in the first place. I can stay ahead of the game on this second set because I skip all the usual formal cruft. Then, four-fifths of the way through the project, when the formal development goes pear-shaped, I pull out the second set of code and say “let's use this.” Sure it drives my hourly rate down and means some weekend work for free, but I have more fun, learn more, and have a better portfolio to point to. (FWIW, I didn't originate this technique, one of my very early coding mentors apprenticed me in using it. We used to say: “there are four plans: plan A is the spec, plan B is what management thinks we're doing, plan C is what we're actually doing, but plan Z is what we know really needs to get done and what we'll do on the side for when it all hits the fan.”)
His books educated more than one generation of programmers and computer scientists. I can remember the decision, while I was a grad student, to part with a sizeable fraction of my net worth to buy my first Tanenbaum textbook. No regrets.
"A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it."
Marvin Minsky, ``Why Programming Is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas''
When confronted with a complex problem -- often one involving data structures -- I'll often sit down and think it through. There does come a "wall" at about the five to fifteen minute mark where it becomes increasingly difficult to keep focus and keep thoughts ordered. But it's only by going through that wall that you get to the point where you can really clear your mind and focus on the problem. I suspect in the modern world of distractions, people haven't had enough experience of this or practice at it.
Slashdot Mirror
The case should be dismissed on the grounds that the school has no governing authority. This is clearly a case for the Department of Underage Magic.
Laziness makes for great software developers. Great developers will slave for hours, days, lifetimes even, just trying find easier ways to do things.
I haven't seen the movie, but the book is one of my favorites. One of the things that worries me is that the book is one of those rare, so self-contained and complete pieces of art that it seems anything added or deleted -- even a single word -- could spoil it.
Probably inevitable, but sad nonetheless. Some of my fondest memories of my Dad are of visiting Radio Shack with him.
...in a personal sense, that is. I go out of my way to avoid offending others on very personal topics like religion. Not because I'm afraid, but because I want to be a nice guy :)
As a citizen of a republic, however, I support the right of free speech, even offensive speech. In fact, offensive or unpopular speech in particular needs to be protected: there's neither need nor reason to protect the speech people want to hear.
In my experience, a huge fraction of the marketing surrounding any IT fad is the promise that it will magically erase or prevent technical debt. This is attractive because in many ways technical debt is THE great unsolved problem of software engineering. TL;DR there is no magic bullet; the only solutions are craftsmanship and paying the technical debt up front. Unless management understands this, no IT fad will ever solve the problem.
and similar publications like Computer Language, the (old-school) Byte, etc., I would likely not be a programmer today. I feel as though a mentor had passed on.
I live in a small town / large village, and I would love to do without a car, but it's just not practical. The town is at an uncomfortable size where it's too large to walk to many places, but too small to make public transit feasible. What would help the most, I think, is some kind of "lane management." It's too dangerous to use the highways as they are now configured with bicycles, motor-scooters, or motor-carts -- though these would suffice for most tasks. If this were made safer, it would be more feasible to rely only on rental cars for longer trips. The city council has taken steps to add bike lanes, and has just approved the use of electric motor carts. These are steps in the right direction, but we've got a ways to go. Still, I like the idea of being able to give up owning a car -- and not just for some green / altruistic reason -- I just don't want the bother.
For a while I lived in Florida and traveled back and forth to "the Bay Area" (at company expense). My take:
I wish I could LIVE in the Bay Area but pay housing and taxes based on the costs in Florida. So I'd advise you to decide what's most important to you: 1) your current lifestyle or 2) putting money aside. There is also a up/downside professionally. The opportunities for professional networking and continuing education are greater in the Bay Area. On the other hand, the competition is a lot stiffer. I think if I could get the pay, adjusted for region, to within about 25%, I'd probably take the Bay Area, but life is what you make it wherever you decide to make it.
According to people like Freud and Campbell, every "technology-out-of-control" fear from Frankenstein on down is just a reflection of the male's fear of his own offspring.
Whenever the toilet backs up, I always think of the rising water scene in the Sorcerer's Apprentice. There's something primordial about watching the water rise up, and realizing you're the one who summoned it, that makes you chant “stop, stop, stop...” as it rises towards the rim and begins to cascade over.
And then you run for the mop and plunger.
It's the same old story, except technology just keeps making the toilet bigger and bigger.
Yep, the problem is not in you *should* do, it's what you *have* to do to actually take care of people. Imagine being a programmer making half or less the effective hourly rate of other average engineers. Having to master dozens of APIs. Working 60 hours a week at random. Filling out paperwork in addition to engineering tasks.
And if you code just one bug, you may be toast. Not the program, *you*, you're toast.
That's what the nurses I know tell me their job is like.
I'm sure there are incompetent nurses, but the working conditions tax the competence of even the best,
"If I ever accidentally make something that seems to gain traction, I’ll probably abandon it immediately."
I'm neither rich nor wildly successful and there are days when I feel like this.
that the downfall of our race was caused by our absolute insistence on basing everything: human relationships, law, economics, etc. on passive entertainment. Maybe this really is (as some have asserted) SETI's great cosmic filter.
The most important thing about Watson is what is least understood by the non-technical press: standards like the UIMA that allow disparate analysis applications to be developed independently and run in parallel. Picture a city full of nice shops and houses connected by muddy, weed-choked trails; that's what Watson would be without framework standards.
I can second this. I have some experience with the Kynect product. There were (and still are), a few glitches, but these seem to be relatively minor. One key factor in the success was training and supporting "Kynect-ors" in helping people use the site. These "Kynect-ors" had also had priority access to varying levels of technical support to help iron out glitches when they did occur. Nothing's ever perfect in politics, healthcare, or programming, and I'm sure there are a few "horror stories," but overall, the Kynect roll-out was very impressive.
I would have studied more about the history of computers and computer science. It would have kept me from re-making so many mistakes and re-inventing so many wheels.
Oddly enough, I can agree with ALL the comments above. I did eventually take a management role, to fill a void after a manager quit. As a manager, I did try to make my role that of smoothing things out and enabling the remaining engineers to work more effectively. And yes, I disliked it and got back into engineering as quickly as possible. Seeing all those engineers working day after day made me jealous, and I just had to get back to hands-on work. We ended up hiring a top-notch ex-engineer from another company who had moved into management and liked it. He was probably the best, but toughest, manager I ever worked with.
I once worked for a boss who repeatedly said: "We need to get you into management so I can pay you more." The odd thing was, he said this because he liked me, and really did want to pay me more. Yet since he owned the company, he could have paid me any salary he wanted, regardless of my job title. He just had this fixed idea that no engineer should be paid more than any manager who supervised multiple engineers.
...could eliminated by removing copy and paste. Most of my bugs seem to happen when a block of code is not quite DRY-able, I copy-paste-modify the block, and then miss some small detail. (Of course, eliminating copy and paste would also reduce my coding speed by about 90%, so I guess it all evens out.)
I tend to work on two sets of code. The first set is the code currently under formal development. The second set is the code that will actually be needed at the end of the project when every figures out what we were really trying to build in the first place. I can stay ahead of the game on this second set because I skip all the usual formal cruft. Then, four-fifths of the way through the project, when the formal development goes pear-shaped, I pull out the second set of code and say “let's use this.” Sure it drives my hourly rate down and means some weekend work for free, but I have more fun, learn more, and have a better portfolio to point to. (FWIW, I didn't originate this technique, one of my very early coding mentors apprenticed me in using it. We used to say: “there are four plans: plan A is the spec, plan B is what management thinks we're doing, plan C is what we're actually doing, but plan Z is what we know really needs to get done and what we'll do on the side for when it all hits the fan.”)
His books educated more than one generation of programmers and computer scientists. I can remember the decision, while I was a grad student, to part with a sizeable fraction of my net worth to buy my first Tanenbaum textbook. No regrets.
"A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it." Marvin Minsky, ``Why Programming Is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas''
When confronted with a complex problem -- often one involving data structures -- I'll often sit down and think it through. There does come a "wall" at about the five to fifteen minute mark where it becomes increasingly difficult to keep focus and keep thoughts ordered. But it's only by going through that wall that you get to the point where you can really clear your mind and focus on the problem. I suspect in the modern world of distractions, people haven't had enough experience of this or practice at it.
"The Timeless Way of Building" by Christopher Alexander.