He was fired, essentially. Kicking someone upstairs to a window office (where they do nothing, and can't do any more damage) is a way to save face in Japanese corporate culture. In the US the individual would quit "to spend more time with the family" or some other malarky.
RTFA. Or rather, the paper. The attack in question takes advantage of weaknesses in the "API" to the hardware crypto.
One reason that good security is so hard is that people think it's easy. Add to this a room full of old guard types who insist that *their* system hasn't been cracked in the 20 (or 30 or 40) years since it was first cobbled-up on punch-card-eatin' mainframes and you have a security disaster in the making.
If Gary had been on the ball technically (instead of being self-absorbed and not seeming to worry about the company's long-term prospects) then utter disasters like GEM would never have happened.
DRI became technically irrelevant around 1986. They could have saved things, they could have hired better people, done some decent UI design, gotten some apps together, done some decent technology, but they just pissed the opportunity away.
Microsofties might have been arrogant, but at least they were willing to cut you some slack once they realized you knew what you were doing. The DRI folks never got past arrogance and a high-falutin' "we can't possibly be wrong" attitude. Found a bug in the linker, or CP/M, or GEMDOS? You had to prove it six different ways, then they'd fix it WRONG. (My apologies to the (few) DRI people who treated my team like human beings).
If Killdall had seen the level at which his people were operating, if he'd seen how his company was being screwed up at its roots (quality of code, of design, of customer interaction) then DRI might have survived. They had their chance and blew it, and I don't miss them.
I've used an iPod. I have a Zune. They're both fine players. I had no problem setting up the Zune software on three different machines, I have had no trouble with the player or downloading music to it, and I love the built in FM stereo (why couldn't the iPod have had this years ago?)
If the iPod and iTunes were to come out today, I really wonder what this journalist would have to say about them.
Okay, so now you've got a thingumy in your living room with a !!!Cell Processor!!! and !!!Blu Ray!!! and um, well . . . now what? It's not like you're going to be programming the damned thing (and, let's face it, you don't exactly need Blu Ray to do a home video of your life).
"But I've got a ***C*E*L*L**P*R*O*C*E*S*S*O*R*** a-an-and --"
Realization dawns. It doesn't matter if there are magic sex-starved nympho computation fairies pushing the electrons around inside. Once again you've bought something because someone else said, "Shiny!" and you didn't know why it was important, or even if it was. Sure, you can run Linux on it, but you can do a better job of that for hundreds of dollars less. You weigh the controller experimentally in your hands. [You know that the mounting points for the rumble motors are still in there? Yup.]
Whatever steps you pick in/your/ real-world scenario, don't forget the bit about "running out of funding" the week before you ship. [Yay, no final?]
And at least one sales type who goes out into the field and comes back with, "I promised the customer X. We can do X, can't we? Can we have X working by, um, Tuesday?" Where X is something like "a financial planner" and your company does real-time messaging software for PDAs.
A-a-and the cross-dressing halfway-through-the-(ahem)-process wacko cow-orker who decides to write everything in Oberon ("It's soooo cool!"), smells bad, is/really/ into guns [look, I understand that there is *good* "into guns" and there is *bad* "into guns," and *then* there is this person's relationship with firearms that is best left unexplored in a public forum], and everyone is like, "Do we fire this gurl, or just secretly move the company overnight and not tell hier?" only the person lives in a van in the company parking lot, and even has the company's name on the van's vanity license plate.
Finally, the CEO who is a fanatic Beavis and Butthead fan, and looks nearly identical and sounds almost exactly the same as Beavis. "How come we have so much trouble getting funding?"
I was working for Apple in the early 90s. I had no idea what products were what. Hell, I was doing systems software, and I couldn't keep track of all the machines that Apple was making. A relative would call me up and ask "What should I buy?" and I'd have to go to ComputerWare or some place to find out.
One internal reason why Apple's "OS" sucked was that they kept coming out with half-baked APIs to stuff that was really tough for developers to use. Color chooser? Give me a break. One of my efforts was a HyperCard XCMD that let you mount network volumes. That should have been a system service; instead, developers had to depend on something that was not officially supported, while systems software went off and did more crappy UI components with no abstractions underneath them.
In short: Very, very poorly designed services.
Then Microsoft got its act together with respect to tools (Visual Studio 1.0 / 1.1) and in the mid 90s NT was a perfectly acceptable development environment. A workstation that didn't crash? Whoa, what a concept.
<sarcasm> Heck, games are just pushing pixels onto a screen and handling user input, what's so hard about that? For online games you just sprinkle some packet handling in there. Should take you like half an hour to do all that.
I mean, operating systems just use standard hardware (e.g., paging and protection) and some standard protocols (e.g., SATA, USB), and what's so hard about them? Compilers? I wrote three last week, and didn't even stoop to use a parser generator. This afternoon I think I'll do a browser, and maybe an MPEG-4 decoder after supper. It's just mundane, standard stuff, innit? </sarcasm>
It's really easy to dismiss this stuff as easy. Sir (or Madam), you have no idea what you're talking about.
... obSnideAside: Or if think you do, maybe you work for Sony:-)
Wrod. If you know that a particular database has your answer (Wikipedia, MSDN and online manuals) it's crazy to use a general purpose engine.
I started using MSN Search about ten months ago. For the non-DB-specific searches that I do, I haven't missed Google at all (used it maybe once a month).
Search engines are a commodity. Anyone who thinks they can keep an empire going on search is dreaming.
"Come on, just crank up that old ectoplasmic typewriter and shoot 'em another one. Herbert is catching up fast, and when Jordan, McCaffrey and Anthony get here, you've got to be wayyy ahead of 'em or you'll never get any respect."
"I thought you were in Hell. Aren't you supposed to be dancing on lava or something?"
"You kidding? My literary agents took care of all that."
Who needs a study? The "positive impact" this kind of legislation is intended to generate is re-election, not any societal improvement. The research consists of polling numbers and how much bigger the money piles get.
(Insert some famous quote along the lines of "When men were studying bats, bats had an unparalleled opportunity to study Man.")
If they're dunderheads and can't ask good questions, don't go. REALLY don't sign up. I did that once, it sucked true and hard, and I bailed in five months even though the CEO was in tears [yup] during my exit interview with him, begging me to stay. I still tell stories about that place, like the time they brought in a head-shrinker [yup] to interview the whole engineering staff to find out what was wrong with their development practices. ("My mother? Let me tell you about my mother...") No real mystery to me: With a couple of exceptions the engineers they had hired were god-awful.
My fault for going there. I let a salary distract me from what made me happy: Working with good people and shipping.
On the bright side of things, an experience like that can be good for building a network. The good people stand out. "Man, we're all in this together, right? You, me, and the oxygen-waster undead out there who are probably still (shudder) putting more syntax errors into tonight's release..." I still keep in touch with the three people I respected from that dunderhead company.
One good touchstone for interviewing those aged, hoary old engineers with 20+ years of experience: See how they are keeping up with stuff in the industry. What have they read recently? What technical resources do they use? Are they an ACM or IEEE member, do they read papers or newsgroups with decent technical content? [At 27 years since my first paying job -- hacking C on V6 Unix -- I know that if you're not continually upgrading your skills and knowledge that you're basically toast within a few years. It's really easy to get behind the curve].
If you plan, and you adhere slavishly to the plan (BUFD / waterfall / etc.) , you are screwed. You'll have an unworkable plan, and a mess, because you didn't know what you were doing.
But if you don't plan (pure agile / "verbal documentation" / just hacking away), you are also screwed. You'll have an unworkable mess because you didn't know what you were doing.
The common thread I've seen is: Successful systems are done by smart people who know what they are doing. How did they come to know that? They failed a lot, and studied at the feet of masters (who similarly failed).
Around the third or fourth time I do something, it's pretty damned good. Initial efforts usually suck. Brooks again: "Plan to throw one away. You will anyway."
Put on roller-skates, all your winter clothing, welding goggles, motorcycle helmet, then strap on fifty pound bags of cement until you can barely walk, and crossing the street is dangerous.
While I have a great deal of respect for the people who fly the thing -- astronauts, controllers, all -- the shuttle is a set of fatal compromises driven by budget and politics. The shuttle has done more to hold space travel back than any other spaceflight program. It needs to go.
I'm hoping for a dropped wrench in the VAB -- no lives lost, but we lose another shuttle to something mildly spectacular. That would put a thankful end to the program, whereupon we could start spending the money where it counts: Unmanned programs, and launch vehicles that don't suck.
(I used to be a big shuttle fan until I realized how much it was costing us).
The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs. Want to add a parameter? You break a bunch of existing clients. These problems dog you everywhere you turn: In development (changing the IDL usually means a complete rebuild), in testing (got all your client versions lined up?) and especially deployment to outside customers. IDL based technology just sucks rocks when you're shipping real applications.
SOAP is a step in the right direction, but its overblown, bloated syntax and lack of a concise binary representation makes it look more like a practical joke gone out of control. ("Oops, they believed it!"). COM got around this by making it easy to version interfaces (but you still have to decide when to assassinate the old versions).
I was part of a start-up in the mid 90s that had most of these things solved. A 166Mhz server could easily keep up with several thousand clients (we were limited by the efficiency of the host's TCP stack). These days, the thought of having to parse XML in order to forward a message is only a little less horrifying than the tower of OMG-how-much-more-complex-can-this-possibly-get that CORBA was . . . shudder.
People hate APIs. Complex syntax or calls that you have to totally understand in order to get your job done will mean that the software in question will sit on the shelf. Simplicity is where it's at. This is CORBA's fundamental reason for failure.
The original "Gauntlet" was actually my roommates MIT thesis (you don't *have* to do a thesis as an undergrad, but he did). It was called Dandy, it ran on the Atari 400/800 computers, and it let up to four players play using the four joystick ports. Finished in the fall of 1982 or so, before he joined Atari.
Atari coin-op loved the game, and shamelessly ripped it. When Jack objected, he settled for a copy of the coin-op Gauntlet (which, being a roommate, I had to help schlep from apartment to apartment for a while, until he just brought it into work).
The line was out the door at the retailer where I had reserved my DS-lite. When I finally got to the front, the guy running the register looked up, saw that the line hadn't shrunk at all, and remarked, "Oh no, they keep re-spawning!"
They had like 70 units and 60 on reserve, and a few people were taking advantage of that to buy more than one. "For a friend." Yeah.
1) Strunk and White; 2) A mentor who wouldn't let me write any code (and I mean/any/ code) until I had the documentation for my projects correct, including spelling and grammar. I had to fix contorted phraseology, remove cutesy-pie attempts at hacker humor, and generally had to be professional about things; 3) Reading lots of/good/ documentation; 4) A decade or so of practice.
I can't stress #4 enough.:-)
Also, never underestimate the value of bad documentation ("Sheesh, I can do better than this...") or a lousy teacher ("This guy is dead wrong about...").
... probably nothing can beat baked clay tablets buried in sand, or maybe cuneiform similarly embedded in clay balls and lost in the desert. Of course, the access latency *stinks*:-)
Runners-up: Acid-free paper printed with bar codes, properly stored, and maybe parchment.
I'm 44. I'm still a great programmer. Seriously. I've just done some of the best work that I've ever done, and I'm moving onto a new project at work that looks like it's going to be Really Hard, and I'm looking forward to it.
True, the young turks do come in and do amazing things. It's hard not to be jealous of a younger person's energy, including the ability to work 80+ hours a week (my own record, ten years ago: six back-to-back 100 hour weeks, followed by two weeks of collapse) and lack of a family (with a 1 year old child, things are rather busy at home).
I've seen other programmers get old and drop out. Usually what they did wrong was to not keep their skills up. Read, read, read. Read other people's code, read books on new programming languages, read articles far outside your field (e.g., if you write, say, A/V pipelines all day long, do some reading on VLSI design or the latest stuff in cmoputation biology). Go wide, go deep when you can afford to. Don't spend too many years doing one single thing.
I've worked on: Games, text editors, operating systems, compilers, linkers, networking all the way from ethernet controller registers to application frameworks, database engines, garbage collected language runtimes, debuggers, security and crypto, I could go on. As Robert Heinlein says, "Specialization is for insects."
My father in law was a productive programmer until he retired at age 73. I know of some well respected engineers at my company who are still slinging damned good code in their 50s and 60s. You can do it, but it takes discipline.
For one thing, utterly scratch UML In a Nutshell; the 2.0 version is much, much better, the first edition is one of the worst computer-related books I've ever read. I'm not kidding. (I also tend to stay away from most Sams books, and stuff like "Learn Foobar in 32 Milliseconds.")
Next, add Structure and Interpretation of Computer Programs. I try to re-read this every five years or so. Once you get over the fact that the book is based on Scheme (and a little math-heavy), the abstraction and design techniques it teaches are well worth it, and applicable in most languages (even Microsoft ones:-) ). Mention it in an interview with me (along with some intelligent commentary) and that's an extra point in your favor.
Finally, I can't recommend strongly enough joining the ACM and taking advantage of its online reference library. This will be the best money -- the equivalent of two or three textbooks a year these days -- that you'll ever spend keeping your "library" and your skills up to date.
When I went through the weed-out courses in college, all I can say is "Thank God they were there."
I was working at the time. A co-worker of mine attending the same college would approach me around the end of every semester and ask for "a little help with an assignment." Usually it was several assignments, two of which were late and the last of which was the final "hard" project that was due in a couple of days, and the cow-orker was completely lost. It wasn't a "little help," it was "please do my work for me." I would give broad hints, but not any code. Three or four semesters of this, and the person was gone.
If I was working with that person today . . . *shudder*. I have worked with some folks who apparently skated through coursework and managed to get hired anyway, and it can be pretty miserable. [Hint: You want your 'A' people to hire more 'A' people. Not 'B' people. 'B' people hire 'C' people and then you are totally screwed and you might as well toss in the hand-grenade and start another company.]
I took all the CS theory I could in school. I coupled this with hands-on experience as a co-op at a local company (bonus: The job helped pay for school, and having access to the computing resources at work didn't hurt, either).
Jobs are great at teaching you everyday mechanics and social stuff (how to check in code, how to negotiate compromises in products and actually ship stuff). CS is for making you a good problem solver. Don't expect anything lasting out of the "Sams" courses -- for instance, once you've taken a good course on compilers, you'll be able to pick up (say) VB in a few days (assuming you want to at that point).
Slashdot Mirror
He was fired, essentially. Kicking someone upstairs to a window office (where they do nothing, and can't do any more damage) is a way to save face in Japanese corporate culture. In the US the individual would quit "to spend more time with the family" or some other malarky.
RTFA. Or rather, the paper. The attack in question takes advantage of weaknesses in the "API" to the hardware crypto.
One reason that good security is so hard is that people think it's easy. Add to this a room full of old guard types who insist that *their* system hasn't been cracked in the 20 (or 30 or 40) years since it was first cobbled-up on punch-card-eatin' mainframes and you have a security disaster in the making.
If Gary had been on the ball technically (instead of being self-absorbed and not seeming to worry about the company's long-term prospects) then utter disasters like GEM would never have happened.
DRI became technically irrelevant around 1986. They could have saved things, they could have hired better people, done some decent UI design, gotten some apps together, done some decent technology, but they just pissed the opportunity away.
Microsofties might have been arrogant, but at least they were willing to cut you some slack once they realized you knew what you were doing. The DRI folks never got past arrogance and a high-falutin' "we can't possibly be wrong" attitude. Found a bug in the linker, or CP/M, or GEMDOS? You had to prove it six different ways, then they'd fix it WRONG. (My apologies to the (few) DRI people who treated my team like human beings).
If Killdall had seen the level at which his people were operating, if he'd seen how his company was being screwed up at its roots (quality of code, of design, of customer interaction) then DRI might have survived. They had their chance and blew it, and I don't miss them.
I've used an iPod. I have a Zune. They're both fine players. I had no problem setting up the Zune software on three different machines, I have had no trouble with the player or downloading music to it, and I love the built in FM stereo (why couldn't the iPod have had this years ago?)
If the iPod and iTunes were to come out today, I really wonder what this journalist would have to say about them.
Okay, so now you've got a thingumy in your living room with a !!!Cell Processor!!! and !!!Blu Ray!!! and um, well . . . now what? It's not like you're going to be programming the damned thing (and, let's face it, you don't exactly need Blu Ray to do a home video of your life).
"But I've got a ***C*E*L*L**P*R*O*C*E*S*S*O*R*** a-an-and --"
Realization dawns. It doesn't matter if there are magic sex-starved nympho computation fairies pushing the electrons around inside. Once again you've bought something because someone else said, "Shiny!" and you didn't know why it was important, or even if it was. Sure, you can run Linux on it, but you can do a better job of that for hundreds of dollars less. You weigh the controller experimentally in your hands. [You know that the mounting points for the rumble motors are still in there? Yup.]
"Oh sh8t, I've gotta unload this on eBay..."
"What's that?" I asked the computer store owner. It was a green box in a bin by the door.
"Dunno. It's yours if you want it."
It had USB connectors, and video out, and a modem jack. Why not? I took it home. Yup, it's one of these OLPC things.
WinCE something-or-other, 20G hard disk, nobody seemed to care...
Whatever steps you pick in /your/ real-world scenario, don't forget the bit about "running out of funding" the week before you ship. [Yay, no final?]
/really/ into guns [look, I understand that there is *good* "into guns" and there is *bad* "into guns," and *then* there is this person's relationship with firearms that is best left unexplored in a public forum], and everyone is like, "Do we fire this gurl, or just secretly move the company overnight and not tell hier?" only the person lives in a van in the company parking lot, and even has the company's name on the van's vanity license plate.
And at least one sales type who goes out into the field and comes back with, "I promised the customer X. We can do X, can't we? Can we have X working by, um, Tuesday?" Where X is something like "a financial planner" and your company does real-time messaging software for PDAs.
A-a-and the cross-dressing halfway-through-the-(ahem)-process wacko cow-orker who decides to write everything in Oberon ("It's soooo cool!"), smells bad, is
Finally, the CEO who is a fanatic Beavis and Butthead fan, and looks nearly identical and sounds almost exactly the same as Beavis. "How come we have so much trouble getting funding?"
I wish to god I had made this up.
I was working for Apple in the early 90s. I had no idea what products were what. Hell, I was doing systems software, and I couldn't keep track of all the machines that Apple was making. A relative would call me up and ask "What should I buy?" and I'd have to go to ComputerWare or some place to find out.
One internal reason why Apple's "OS" sucked was that they kept coming out with half-baked APIs to stuff that was really tough for developers to use. Color chooser? Give me a break. One of my efforts was a HyperCard XCMD that let you mount network volumes. That should have been a system service; instead, developers had to depend on something that was not officially supported, while systems software went off and did more crappy UI components with no abstractions underneath them.
In short: Very, very poorly designed services.
Then Microsoft got its act together with respect to tools (Visual Studio 1.0 / 1.1) and in the mid 90s NT was a perfectly acceptable development environment. A workstation that didn't crash? Whoa, what a concept.
Troll.
<sarcasm> Heck, games are just pushing pixels onto a screen and handling user input, what's so hard about that? For online games you just sprinkle some packet handling in there. Should take you like half an hour to do all that.
I mean, operating systems just use standard hardware (e.g., paging and protection) and some standard protocols (e.g., SATA, USB), and what's so hard about them? Compilers? I wrote three last week, and didn't even stoop to use a parser generator. This afternoon I think I'll do a browser, and maybe an MPEG-4 decoder after supper. It's just mundane, standard stuff, innit? </sarcasm>
It's really easy to dismiss this stuff as easy. Sir (or Madam), you have no idea what you're talking about.
... obSnideAside: Or if think you do, maybe you work for Sony :-)
I would definitely include this classic by Terry Bisson.
http://www.terrybisson.com/meat.html/
"Omigod. So what does this meat have in mind?"
"First it wants to talk to us. Then I imagine it wants to explore the Universe, contact other sentiences, swap ideas and information. The usual."
"We're supposed to talk to meat."
Wrod. If you know that a particular database has your answer (Wikipedia, MSDN and online manuals) it's crazy to use a general purpose engine.
I started using MSN Search about ten months ago. For the non-DB-specific searches that I do, I haven't missed Google at all (used it maybe once a month).
Search engines are a commodity. Anyone who thinks they can keep an empire going on search is dreaming.
I know; Hubbard just keeps egging Tolkien on.
"Come on, just crank up that old ectoplasmic typewriter and shoot 'em another one. Herbert is catching up fast, and when Jordan, McCaffrey and Anthony get here, you've got to be wayyy ahead of 'em or you'll never get any respect."
"I thought you were in Hell. Aren't you supposed to be dancing on lava or something?"
"You kidding? My literary agents took care of all that."
Who needs a study? The "positive impact" this kind of legislation is intended to generate is re-election, not any societal improvement. The research consists of polling numbers and how much bigger the money piles get.
(Insert some famous quote along the lines of "When men were studying bats, bats had an unparalleled opportunity to study Man.")
If they're dunderheads and can't ask good questions, don't go. REALLY don't sign up. I did that once, it sucked true and hard, and I bailed in five months even though the CEO was in tears [yup] during my exit interview with him, begging me to stay. I still tell stories about that place, like the time they brought in a head-shrinker [yup] to interview the whole engineering staff to find out what was wrong with their development practices. ("My mother? Let me tell you about my mother...") No real mystery to me: With a couple of exceptions the engineers they had hired were god-awful.
My fault for going there. I let a salary distract me from what made me happy: Working with good people and shipping.
On the bright side of things, an experience like that can be good for building a network. The good people stand out. "Man, we're all in this together, right? You, me, and the oxygen-waster undead out there who are probably still (shudder) putting more syntax errors into tonight's release..." I still keep in touch with the three people I respected from that dunderhead company.
One good touchstone for interviewing those aged, hoary old engineers with 20+ years of experience: See how they are keeping up with stuff in the industry. What have they read recently? What technical resources do they use? Are they an ACM or IEEE member, do they read papers or newsgroups with decent technical content? [At 27 years since my first paying job -- hacking C on V6 Unix -- I know that if you're not continually upgrading your skills and knowledge that you're basically toast within a few years. It's really easy to get behind the curve].
If you plan, and you adhere slavishly to the plan (BUFD / waterfall / etc.) , you are screwed. You'll have an unworkable plan, and a mess, because you didn't know what you were doing.
But if you don't plan (pure agile / "verbal documentation" / just hacking away), you are also screwed. You'll have an unworkable mess because you didn't know what you were doing.
The common thread I've seen is: Successful systems are done by smart people who know what they are doing. How did they come to know that? They failed a lot, and studied at the feet of masters (who similarly failed).
Around the third or fourth time I do something, it's pretty damned good. Initial efforts usually suck. Brooks again: "Plan to throw one away. You will anyway."
"Space exploration is dangerous"
Put on roller-skates, all your winter clothing, welding goggles, motorcycle helmet, then strap on fifty pound bags of cement until you can barely walk, and crossing the street is dangerous.
While I have a great deal of respect for the people who fly the thing -- astronauts, controllers, all -- the shuttle is a set of fatal compromises driven by budget and politics. The shuttle has done more to hold space travel back than any other spaceflight program. It needs to go.
I'm hoping for a dropped wrench in the VAB -- no lives lost, but we lose another shuttle to something mildly spectacular. That would put a thankful end to the program, whereupon we could start spending the money where it counts: Unmanned programs, and launch vehicles that don't suck.
(I used to be a big shuttle fan until I realized how much it was costing us).
The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs. Want to add a parameter? You break a bunch of existing clients. These problems dog you everywhere you turn: In development (changing the IDL usually means a complete rebuild), in testing (got all your client versions lined up?) and especially deployment to outside customers. IDL based technology just sucks rocks when you're shipping real applications.
SOAP is a step in the right direction, but its overblown, bloated syntax and lack of a concise binary representation makes it look more like a practical joke gone out of control. ("Oops, they believed it!"). COM got around this by making it easy to version interfaces (but you still have to decide when to assassinate the old versions).
I was part of a start-up in the mid 90s that had most of these things solved. A 166Mhz server could easily keep up with several thousand clients (we were limited by the efficiency of the host's TCP stack). These days, the thought of having to parse XML in order to forward a message is only a little less horrifying than the tower of OMG-how-much-more-complex-can-this-possibly-get that CORBA was . . . shudder.
People hate APIs. Complex syntax or calls that you have to totally understand in order to get your job done will mean that the software in question will sit on the shelf. Simplicity is where it's at. This is CORBA's fundamental reason for failure.
The original "Gauntlet" was actually my roommates MIT thesis (you don't *have* to do a thesis as an undergrad, but he did). It was called Dandy, it ran on the Atari 400/800 computers, and it let up to four players play using the four joystick ports. Finished in the fall of 1982 or so, before he joined Atari.
Atari coin-op loved the game, and shamelessly ripped it. When Jack objected, he settled for a copy of the coin-op Gauntlet (which, being a roommate, I had to help schlep from apartment to apartment for a while, until he just brought it into work).
The line was out the door at the retailer where I had reserved my DS-lite. When I finally got to the front, the guy running the register looked up, saw that the line hadn't shrunk at all, and remarked, "Oh no, they keep re-spawning!"
They had like 70 units and 60 on reserve, and a few people were taking advantage of that to buy more than one. "For a friend." Yeah.
How I learned to write -
/any/ code) until I had the documentation for my projects correct, including spelling and grammar. I had to fix contorted phraseology, remove cutesy-pie attempts at hacker humor, and generally had to be professional about things; /good/ documentation;
:-)
1) Strunk and White;
2) A mentor who wouldn't let me write any code (and I mean
3) Reading lots of
4) A decade or so of practice.
I can't stress #4 enough.
Also, never underestimate the value of bad documentation ("Sheesh, I can do better than this...") or a lousy teacher ("This guy is dead wrong about...").
... probably nothing can beat baked clay tablets buried in sand, or maybe cuneiform similarly embedded in clay balls and lost in the desert. Of course, the access latency *stinks* :-)
Runners-up: Acid-free paper printed with bar codes, properly stored, and maybe parchment.
I'm 44. I'm still a great programmer. Seriously. I've just done some of the best work that I've ever done, and I'm moving onto a new project at work that looks like it's going to be Really Hard, and I'm looking forward to it.
True, the young turks do come in and do amazing things. It's hard not to be jealous of a younger person's energy, including the ability to work 80+ hours a week (my own record, ten years ago: six back-to-back 100 hour weeks, followed by two weeks of collapse) and lack of a family (with a 1 year old child, things are rather busy at home).
I've seen other programmers get old and drop out. Usually what they did wrong was to not keep their skills up. Read, read, read. Read other people's code, read books on new programming languages, read articles far outside your field (e.g., if you write, say, A/V pipelines all day long, do some reading on VLSI design or the latest stuff in cmoputation biology). Go wide, go deep when you can afford to. Don't spend too many years doing one single thing.
I've worked on: Games, text editors, operating systems, compilers, linkers, networking all the way from ethernet controller registers to application frameworks, database engines, garbage collected language runtimes, debuggers, security and crypto, I could go on. As Robert Heinlein says, "Specialization is for insects."
My father in law was a productive programmer until he retired at age 73. I know of some well respected engineers at my company who are still slinging damned good code in their 50s and 60s. You can do it, but it takes discipline.
For one thing, utterly scratch UML In a Nutshell; the 2.0 version is much, much better, the first edition is one of the worst computer-related books I've ever read. I'm not kidding. (I also tend to stay away from most Sams books, and stuff like "Learn Foobar in 32 Milliseconds.")
Next, add Structure and Interpretation of Computer Programs. I try to re-read this every five years or so. Once you get over the fact that the book is based on Scheme (and a little math-heavy), the abstraction and design techniques it teaches are well worth it, and applicable in most languages (even Microsoft ones :-) ). Mention it in an interview with me (along with some intelligent commentary) and that's an extra point in your favor.
Finally, I can't recommend strongly enough joining the ACM and taking advantage of its online reference library. This will be the best money -- the equivalent of two or three textbooks a year these days -- that you'll ever spend keeping your "library" and your skills up to date.
When I went through the weed-out courses in college, all I can say is "Thank God they were there."
I was working at the time. A co-worker of mine attending the same college would approach me around the end of every semester and ask for "a little help with an assignment." Usually it was several assignments, two of which were late and the last of which was the final "hard" project that was due in a couple of days, and the cow-orker was completely lost. It wasn't a "little help," it was "please do my work for me." I would give broad hints, but not any code. Three or four semesters of this, and the person was gone.
If I was working with that person today . . . *shudder*. I have worked with some folks who apparently skated through coursework and managed to get hired anyway, and it can be pretty miserable. [Hint: You want your 'A' people to hire more 'A' people. Not 'B' people. 'B' people hire 'C' people and then you are totally screwed and you might as well toss in the hand-grenade and start another company.]
I took all the CS theory I could in school. I coupled this with hands-on experience as a co-op at a local company (bonus: The job helped pay for school, and having access to the computing resources at work didn't hurt, either).
Jobs are great at teaching you everyday mechanics and social stuff (how to check in code, how to negotiate compromises in products and actually ship stuff). CS is for making you a good problem solver. Don't expect anything lasting out of the "Sams" courses -- for instance, once you've taken a good course on compilers, you'll be able to pick up (say) VB in a few days (assuming you want to at that point).