Norton wasn't in the book.
If I had started with my own list of "people who defined the microcomputer industry," I could have included a LOT of folks who had a major impact. It would have been a long list.
Not just Peter Norton (who's a major art collector now, didja know that?) but also Philippe Kahn (who would have been fun to write about -- he went on to invent the camera phone and has continued to be fascinating... and also I'm still in touch with him so would have been able to do an interview relatively easily).
But the article as-is has several tl;dr comments elsewhere, and one has to stop *sometime.* That's why I began with a pre-created list (i.e. the book), which also gave me the advantage of long interviews in which they talked about what they cared about. (For Philippe, I'd have to go back to my CompuServe BORLAND forum archives.)
Lying implies ill intent. "Wrong" does not. Or perhaps "We don't have all the facts yet and neither do they." (I have such a habit of trying to be fair....)
FYI, If you know that your battery has plenty of juice left, there's a fix available. Sort of. The #5 item in Fixing Five Common Windows 7 Annoyances is "the undead battery." One way to know if it's necessary:
To see if your battery problems are likely to come from this conflict between Windows 7 and your hardware run the powercfg -energy command from a command prompt. If the result is that Windows was unable to determine the battery’s capacity, sooner or later you will see the misleading error messages or have the laptop shutdown prematurely.
Yeah, we wimmin shouldn't oughta write about tech stuff. It just remind youze guys how much smarter than you we iz. And makes youze cry.::Removing tongue from cheek with prybar::
I agree with cream wobbly that it's good prototype code but bad release code. On the other hand it's okay with me that you explained the difficulty in the comments because that fulfills the purpose: You're communicating with the next developer who looks at the code.
If you managed to get it to work (you think, anyhow), it may still be buggy; and the "Well, I THINK so..." in the comments will be an arrow to "probable source of application meltdown" for someone who comes in to debug.
There's a difference between writing a good explanation that happens to be long, and a rambling list of excuses. Yours sounds like the former. IMHO.
I think the one page resume comes from the days in which people typically worked at one company for most of their lives. Or at least for 10-15 years.
Not that it'd be easy to summarize 15 years of experience in a paragraph or two, either, but in most cases it'd be the most recent accomplishments you'd want to talk about anyhow.
So I don't think that it's an issue of being boring but rather that our society has changed.
I think most hiring managers will read past the first page... assuming that they didn't get 100 resumes in response to a single job ad. But in a lot of companies, HR people exist to eliminate candidates more than they work to find the right ones. So they perform a kind of triage, looking for the reasons to dump your resume immediately (which I wrote about at Javaworld in How to Make HR Dump A Programmer's Resume and they are attracted by some strangely shiny things like keywords What HR Professionals Look For in a Programmer's Resume).
Mostly, the idea is to get past the HR department and get to the hiring manager -- the person to whom you'd report, ideally. But if she has a stack of 100 resumes to fill an open position, you need to capture her attention immediately and shout I have the background you need. That's among the reasons that it's a good idea to include FOSS experience, which is what I wrote in the first part of that blog post.
Not particularly. My post was meant as constructive criticism, which is not tied to news events. I still don't see how some people can read, "This could use improvement" as "I think this sucks."
First, as I said -- the purpose of my post was to identify problems (including perceptions) so that they can be addressed. I have the silly idea that it's a good idea to know why people say No; that lets you find out what you would have to change to make them say Yes instead. (It's up to you to decide if you want to do those things; but you can't get that far unless you know what the objections are.)
Also, I started research on this question several weeks ago.
And, oh yeah, I've been writing about open source and software development for about a decade.
I think most "journalist" are so busy and have such tight deadlines, that they over rely on people that are paid to speak to the press. Open source, by its nature is a low-cost, high quality grass-roots effort. Even the most successful FOSS companies are tiny and have tighter margins than the for profits. Free software is customer driven (requested not sold) and doesn't have the money or staff to generate press releases or provide a pretty marketing type to spoon feed a story.
If we rely overmuch on PR people (including PR people for the larger FOSS projects and organizations), perhaps it's because the FOSS developers don't respond to our queries?
Often, we very much want input from Real Developers. But if you are all saying, "I'm too busy, someone else will have to respond" (even when your project wants more public attention, which is a tacit requirement for any of this conversation), then all the requests in this thread that journalists "take the time to research" are meaningless. I can't interview you if you won't talk to me.
Case in point. I'm working on a feature story about open source right now, about a process that goes on in FOSS communities -- not about the technology involved in any project in particular. I've posted a note on www.helpareporterout.com and I posted a Question on LinkedIn. Happily, I've gotten some great responses from FOSS projects (large and small, well known and just-emerging) so I'm not worried that I won't have enough input. However, if YOUR project would like to be mentioned as something cool to be involved with (and incidentally attract a few more developers to contribute), then you won't know I'm even asking.
When I'm writing an article about, say, open source database trends, or new scripting languages, I can make a list of FOSS projects, do a bunch of reading, and then maybe find the right communities to contact. (Half of which, I've learned from experience, will ignore my requests.) But I often ask questions (I like to think they're good questions) that apply to the FOSS development process or community. It's not easy to find a venue in which to ask these questions where I can be sure I'll get a good cross section of FOSS developers who do have time to answer.
--Esther (who's happy to share my current question-list by email)
It had never occurred to me that my ID had street cred. Would this give me anything valuable? Like, say, free dark chocolate? (I have my priorities.)
It's one of the things I didn't go into in the blog post but yes, sometimes your prose doesn't make it into the article. Or an attribution ("...who is senior developer at FooBaz Inc") is streamlined. Or -- well, any number of other things that mean, "I did not copy and paste your entire email message to me into my article."
The reasons are long and detailed and I'm not sure that most people care... though I'd be happy to share them if I thought others share your interest. If they do, cool; I'll do a follow-up. If not, I'll be happy to respond privately.
In my case, the most likely scenario is that I had too many people expressing the same sentiment, and I didn't want to be repetitive. I often have 30+ people giving me input for a 2000 word article. (This is called "over reporting," a longtime weakness of mine.) And while it's good to have consensus among the responses, nobody wants to read a whole article that says, "Me too."
I usually do find a way to include the quotes that are funny, though.:-)
...Consider the project contributors may all be volunteers contributing coding time as a hobby. If the project is still worth writing something about, that isn't changed by the situation where none of the programmers have decided the limited time they contribute will also include PR tasks.
But sometimes it's not the project that's the focus of the article. I don't need to know everything about your software; but I expect that you do.
The article may be about something closely related to open source, such as my article, How to sponsor an open source sprint). In that case, I didn't particularly care which projects I quoted; I just wanted to represent several. People from Plone and Drupal stepped forward, when I asked (broadly) for input. Your project didn't. They got the visibility; yours didn't.
I like to think that (assuming your project has sprints and works with corporate sponsors) you might have had useful advice to share, too. We both missed out, because you were too busy.
And sometimes the article isn't about open source at all. Developer Tools You Don't Use, and Why You Don't Use Them was about programming tools in general. But one of the people who responded (via Help a Reporter Out) was a woman who had several worthwhile points to offer regarding her use of FOSS developer tools. (A few of the comments landed on the cutting room floor, because that feature was already twice as long as I promised, but I appreciated her input.) Her project is mentioned, in passing, because that was the relevant affiliation.
In other words: It's not always about whether I'm technically savvy enough to understand everything in your release notes. Often, I don't care what's in your release notes. But I might care what the community is doing and how it's participating in the larger universe.
If you (the reporter) has decided the open source project is news worthy, you should have a basic idea on what it is about and why it matters already. Include questions don't have the answer to in your initial email. Make your own screenshots while you're playing around with the software. To put it bluntly, quoting from a press page and including screenshots from the site hardly seems like the methods of a competent tech reporter.
If I can't figure out what the project is, then it won't be worthy.
That applies to users and developers just as much as it does to the press. Whether or not you care about press attention (and really, it's fine with me if you don't), please do take a step back and look at your site as though you've never seen it before. If you didn't know what this software did, how long would it take for you to learn?
And frankly -- yes, I need you to send me a screen shot of the app doing something that demonstrates its capabilities (or at least looks pretty). If all I'm going to do is give you two paragraphs of attention (which is what I did in that Computerworld article about upcoming apps), I am not necessarily going to download, install, and configure each one, as well as any underlying software they rely on. All to take a screen shot? You have it working; you know it; you, its proud momma and poppa, can give me something that'll show it off.
Again: sample screen shots that demonstrate functionality are useful to users and developers, too. Not everyone has the time to download and install everything that looks like it might be interesting. A quick glance can let me (as a user) determine if this is worth further inquiry.
I'm tech oriented. I can understand the reasons that a developer might get excited by a new compiler feature, and I can grok the problems caused by a misconfigured e-mail server (MX-record-talk does not make my eyes glaze over), and I can follow a debate between two people arguing the merits of an Agile practice. I know something about most areas of technology, and more-than-something about some of them. But I will not know everything about everything.
Unless I am personally involved in a narrow niche (such as "I write only about CMSs") I will not understand your software in as much depth as you do. That's fine. Because that's why I'm asking you about it.
Most of the time, I truly do not need to know your project in depth to understand what is important about it. But I rely on you to know -- and to express -- its importance.
I'm not sure if it's reassuring, but in my experience your bad scene is not representative of the press in general, and the trade press in particular. Every journalist I know is very concerned about ethics. And I don't mean "don't be caught" but "do the right thing."
That's why I made the point about understanding whether a reporter is working on a news article (Quick! Oracle bought Sun, let's get MySQL developer responses to the news) or a feature story, or a how-to story, or whatever. It makes a difference in the time frame, and also in the answer you give me.
Believe me, we do want to gather good information. That's one of the reasons I wrote that post -- because it helps everybody to know how the system works. If you weren't aware that "time is of the essence" for me to do my job effectively, then, well, now you know. Maybe that can help us work together better.
The amount of research necessary for an article varies considerably. A news-response story (e.g. what do FOSS developers think of this acquisition?) is anecdotal, and its readiness is primarily an issue of "How many people can I get to tell me what they think, how soon?" (As I said, I rarely write news.)
A feature story is longer and takes longer; for me, these start with a question to which I want to know the answer ("What are the important open source projects with major releases expected Real Soon Now?" or "What do developers need to know to do a code review right?" or "What are the essential things that the CIO ought to understand about software development requirements, but doesn't?") In these cases, it's rarely a question of me reaching One Right Person (though if I need to ask Mark Shuttleworth his opinion, I know how to contact his PR guy). Rather, I ask in likely places for input from those who have the expertise to share. If you (or someone from your project) answers in time with information that helps answer my question, you'll be included. If you don't, you don't.
My time is limited. Whether I'm on staff or a freelancer, I have a finite amount of time in which to do an article. (I'm good at my job to the degree that I can deliver accurately, well-written, and on-time.) If you want your project to be mentioned, then you have to respond in the time I have to work with.
Which is why I (and apparently you) are frustrated when we know someone could have something useful to add to this article, but there's no time to wait for the answer.
The point of example #3 is that your fellow players/DMs might be equal to you today. But tomorrow they may be a Hiring Manager.
I can't speak to you working with backstabbers. That sucks. But I'm just the DM; I'm not there.
Well getting hired as the result of playing D&D (by the 1st->5th level illusionist) does sort of require that the guy who owns the business is also the DM. But he was... and as I said, D&D does let people see how you cope with problems and which problems you volunteer for.
Another day-job I got from playing D&D was really more the result of people networking. Someone else playing the game was also involved in Phoenix Mensa (this was a monthly Mensa D&D game, which sort of highlighted the wisdom/intelligence matter discussed elsewhere... any member could play, though of course the game had its regulars). After hanging out with 'em for a while I was asked to serve on a temporary board position, which led to someone recommending me for my first professional programming position. Straight out of programming school.
The third gig was also from another D&D player. She was a semi-regular in the D&D group, but we also socialized separately (she ran the monthly general Games Night, which is how I learned to play Mah Jongg). Mind you, neither of us were in the computer industry at that point; I was in school, and she was working as a part-time tech writer while raising two little kids. We became friends, stayed in touch, and now she runs a well known company in the computer industry. A "Hey, I'm looking for work..." note in 2002 got me a writing gig 24 hours later, and that gig has continued (a few times a year) ever since.
So yes. Be nice to people. You never know where they -- or you -- will end up.
As usual, though, the book is better. The Pirates of Silicon Valley is based on Fire in the Valley: The Making of The Personal Computer by Paul Freiberger and Michael Swaine. It's out of print but your library probably has a copy. It's a very fun book.
The movie focuses on Gates/Jobs (because, hey, movies have to do things like that) and... well, not exactly "stereotypes" them, but certainly streamlines the personae. It also underplays the Digital Research history, for one thing.
But one of the illuminating facts a reader will glean from Fire in the Valley is that there were so many strong personalities vying for attention. Sure, geeks were geeks (and proud of it, dammit!), but you had lots of innovators full of confidence and dreams and the belief that these small computers can change the world. That makes me nostalgic, and I wish for more such "personalities." Only Philippe and Ellison could hold a candle to those guys.
Maybe it's just because I'm an old fart now, and I remember most of those events. (I also wrote for Computer Shopper way back when, for some of the best editors in the business, and I think Stan Veit is a mensch. I used to describe writing for Shopper as similar to writing for Playboy. They paid great, and it was a lot of fun, but who looked at the articles?)
What's nice is to know that the spirit is still alive... or at least it's trying to be. I assume y'all know about the upcoming Rebooting Computing summit, which aims to put the magic back into our field.
>>This is reminiscent of the 100 monkeys in a room with typewriters eventually being able yo produce the works of Shakespeare.
Thanks to the Internet, we have demonstrated that this is not true.
Slashdot Mirror
Norton wasn't in the book. If I had started with my own list of "people who defined the microcomputer industry," I could have included a LOT of folks who had a major impact. It would have been a long list. Not just Peter Norton (who's a major art collector now, didja know that?) but also Philippe Kahn (who would have been fun to write about -- he went on to invent the camera phone and has continued to be fascinating... and also I'm still in touch with him so would have been able to do an interview relatively easily). But the article as-is has several tl;dr comments elsewhere, and one has to stop *sometime.* That's why I began with a pre-created list (i.e. the book), which also gave me the advantage of long interviews in which they talked about what they cared about. (For Philippe, I'd have to go back to my CompuServe BORLAND forum archives.)
Lying implies ill intent. "Wrong" does not. Or perhaps "We don't have all the facts yet and neither do they." (I have such a habit of trying to be fair....)
Let's just say that I don't think the end of the tale has been reached yet.
FYI, If you know that your battery has plenty of juice left, there's a fix available. Sort of. The #5 item in Fixing Five Common Windows 7 Annoyances is "the undead battery." One way to know if it's necessary:
Yeah, we wimmin shouldn't oughta write about tech stuff. It just remind youze guys how much smarter than you we iz. And makes youze cry. ::Removing tongue from cheek with prybar::
I agree with cream wobbly that it's good prototype code but bad release code. On the other hand it's okay with me that you explained the difficulty in the comments because that fulfills the purpose: You're communicating with the next developer who looks at the code.
If you managed to get it to work (you think, anyhow), it may still be buggy; and the "Well, I THINK so..." in the comments will be an arrow to "probable source of application meltdown" for someone who comes in to debug.
There's a difference between writing a good explanation that happens to be long, and a rambling list of excuses. Yours sounds like the former. IMHO.
I think the one page resume comes from the days in which people typically worked at one company for most of their lives. Or at least for 10-15 years.
Not that it'd be easy to summarize 15 years of experience in a paragraph or two, either, but in most cases it'd be the most recent accomplishments you'd want to talk about anyhow.
So I don't think that it's an issue of being boring but rather that our society has changed.
I think most hiring managers will read past the first page... assuming that they didn't get 100 resumes in response to a single job ad. But in a lot of companies, HR people exist to eliminate candidates more than they work to find the right ones. So they perform a kind of triage, looking for the reasons to dump your resume immediately (which I wrote about at Javaworld in How to Make HR Dump A Programmer's Resume and they are attracted by some strangely shiny things like keywords What HR Professionals Look For in a Programmer's Resume).
Mostly, the idea is to get past the HR department and get to the hiring manager -- the person to whom you'd report, ideally. But if she has a stack of 100 resumes to fill an open position, you need to capture her attention immediately and shout I have the background you need. That's among the reasons that it's a good idea to include FOSS experience, which is what I wrote in the first part of that blog post.
Not particularly. My post was meant as constructive criticism, which is not tied to news events. I still don't see how some people can read, "This could use improvement" as "I think this sucks."
First, as I said -- the purpose of my post was to identify problems (including perceptions) so that they can be addressed. I have the silly idea that it's a good idea to know why people say No; that lets you find out what you would have to change to make them say Yes instead. (It's up to you to decide if you want to do those things; but you can't get that far unless you know what the objections are.)
Also, I started research on this question several weeks ago.
And, oh yeah, I've been writing about open source and software development for about a decade.
I think most "journalist" are so busy and have such tight deadlines, that they over rely on people that are paid to speak to the press. Open source, by its nature is a low-cost, high quality grass-roots effort. Even the most successful FOSS companies are tiny and have tighter margins than the for profits. Free software is customer driven (requested not sold) and doesn't have the money or staff to generate press releases or provide a pretty marketing type to spoon feed a story.
If we rely overmuch on PR people (including PR people for the larger FOSS projects and organizations), perhaps it's because the FOSS developers don't respond to our queries?
Often, we very much want input from Real Developers. But if you are all saying, "I'm too busy, someone else will have to respond" (even when your project wants more public attention, which is a tacit requirement for any of this conversation), then all the requests in this thread that journalists "take the time to research" are meaningless. I can't interview you if you won't talk to me.
Case in point. I'm working on a feature story about open source right now, about a process that goes on in FOSS communities -- not about the technology involved in any project in particular. I've posted a note on www.helpareporterout.com and I posted a Question on LinkedIn. Happily, I've gotten some great responses from FOSS projects (large and small, well known and just-emerging) so I'm not worried that I won't have enough input. However, if YOUR project would like to be mentioned as something cool to be involved with (and incidentally attract a few more developers to contribute), then you won't know I'm even asking.
When I'm writing an article about, say, open source database trends, or new scripting languages, I can make a list of FOSS projects, do a bunch of reading, and then maybe find the right communities to contact. (Half of which, I've learned from experience, will ignore my requests.) But I often ask questions (I like to think they're good questions) that apply to the FOSS development process or community. It's not easy to find a venue in which to ask these questions where I can be sure I'll get a good cross section of FOSS developers who do have time to answer.
--Esther (who's happy to share my current question-list by email)
It had never occurred to me that my ID had street cred. Would this give me anything valuable? Like, say, free dark chocolate? (I have my priorities.)
It's one of the things I didn't go into in the blog post but yes, sometimes your prose doesn't make it into the article. Or an attribution ("...who is senior developer at FooBaz Inc") is streamlined. Or -- well, any number of other things that mean, "I did not copy and paste your entire email message to me into my article."
The reasons are long and detailed and I'm not sure that most people care... though I'd be happy to share them if I thought others share your interest. If they do, cool; I'll do a follow-up. If not, I'll be happy to respond privately.
In my case, the most likely scenario is that I had too many people expressing the same sentiment, and I didn't want to be repetitive. I often have 30+ people giving me input for a 2000 word article. (This is called "over reporting," a longtime weakness of mine.) And while it's good to have consensus among the responses, nobody wants to read a whole article that says, "Me too."
I usually do find a way to include the quotes that are funny, though. :-)
...Consider the project contributors may all be volunteers contributing coding time as a hobby. If the project is still worth writing something about, that isn't changed by the situation where none of the programmers have decided the limited time they contribute will also include PR tasks.
But sometimes it's not the project that's the focus of the article. I don't need to know everything about your software; but I expect that you do.
The article may be about something closely related to open source, such as my article, How to sponsor an open source sprint). In that case, I didn't particularly care which projects I quoted; I just wanted to represent several. People from Plone and Drupal stepped forward, when I asked (broadly) for input. Your project didn't. They got the visibility; yours didn't.
I like to think that (assuming your project has sprints and works with corporate sponsors) you might have had useful advice to share, too. We both missed out, because you were too busy.
And sometimes the article isn't about open source at all. Developer Tools You Don't Use, and Why You Don't Use Them was about programming tools in general. But one of the people who responded (via Help a Reporter Out) was a woman who had several worthwhile points to offer regarding her use of FOSS developer tools. (A few of the comments landed on the cutting room floor, because that feature was already twice as long as I promised, but I appreciated her input.) Her project is mentioned, in passing, because that was the relevant affiliation.
In other words: It's not always about whether I'm technically savvy enough to understand everything in your release notes. Often, I don't care what's in your release notes. But I might care what the community is doing and how it's participating in the larger universe.
If you (the reporter) has decided the open source project is news worthy, you should have a basic idea on what it is about and why it matters already. Include questions don't have the answer to in your initial email. Make your own screenshots while you're playing around with the software. To put it bluntly, quoting from a press page and including screenshots from the site hardly seems like the methods of a competent tech reporter.
If I can't figure out what the project is, then it won't be worthy.
That applies to users and developers just as much as it does to the press. Whether or not you care about press attention (and really, it's fine with me if you don't), please do take a step back and look at your site as though you've never seen it before. If you didn't know what this software did, how long would it take for you to learn?
And frankly -- yes, I need you to send me a screen shot of the app doing something that demonstrates its capabilities (or at least looks pretty). If all I'm going to do is give you two paragraphs of attention (which is what I did in that Computerworld article about upcoming apps), I am not necessarily going to download, install, and configure each one, as well as any underlying software they rely on. All to take a screen shot? You have it working; you know it; you, its proud momma and poppa, can give me something that'll show it off.
Again: sample screen shots that demonstrate functionality are useful to users and developers, too. Not everyone has the time to download and install everything that looks like it might be interesting. A quick glance can let me (as a user) determine if this is worth further inquiry.
I ask lots of people questions, Steve. I ask in lots of places, too. But we aren't always at the same place at the same time. :-)
Define "tech oriented."
I'm tech oriented. I can understand the reasons that a developer might get excited by a new compiler feature, and I can grok the problems caused by a misconfigured e-mail server (MX-record-talk does not make my eyes glaze over), and I can follow a debate between two people arguing the merits of an Agile practice. I know something about most areas of technology, and more-than-something about some of them. But I will not know everything about everything.
Unless I am personally involved in a narrow niche (such as "I write only about CMSs") I will not understand your software in as much depth as you do. That's fine. Because that's why I'm asking you about it.
Most of the time, I truly do not need to know your project in depth to understand what is important about it. But I rely on you to know -- and to express -- its importance.
I'm not sure if it's reassuring, but in my experience your bad scene is not representative of the press in general, and the trade press in particular. Every journalist I know is very concerned about ethics. And I don't mean "don't be caught" but "do the right thing."
That's why I made the point about understanding whether a reporter is working on a news article (Quick! Oracle bought Sun, let's get MySQL developer responses to the news) or a feature story, or a how-to story, or whatever. It makes a difference in the time frame, and also in the answer you give me.
Believe me, we do want to gather good information. That's one of the reasons I wrote that post -- because it helps everybody to know how the system works. If you weren't aware that "time is of the essence" for me to do my job effectively, then, well, now you know. Maybe that can help us work together better.
The amount of research necessary for an article varies considerably. A news-response story (e.g. what do FOSS developers think of this acquisition?) is anecdotal, and its readiness is primarily an issue of "How many people can I get to tell me what they think, how soon?" (As I said, I rarely write news.)
A feature story is longer and takes longer; for me, these start with a question to which I want to know the answer ("What are the important open source projects with major releases expected Real Soon Now?" or "What do developers need to know to do a code review right?" or "What are the essential things that the CIO ought to understand about software development requirements, but doesn't?") In these cases, it's rarely a question of me reaching One Right Person (though if I need to ask Mark Shuttleworth his opinion, I know how to contact his PR guy). Rather, I ask in likely places for input from those who have the expertise to share. If you (or someone from your project) answers in time with information that helps answer my question, you'll be included. If you don't, you don't.
My time is limited. Whether I'm on staff or a freelancer, I have a finite amount of time in which to do an article. (I'm good at my job to the degree that I can deliver accurately, well-written, and on-time.) If you want your project to be mentioned, then you have to respond in the time I have to work with.
Exactly.
Which is why I (and apparently you) are frustrated when we know someone could have something useful to add to this article, but there's no time to wait for the answer.
Because English is not a compiled language.
People do not throw exceptions when English is used incorrectly. They throw other people.
At Ramada Inns, it was "go broke in 24 hours." I was quoting. From memory, granted, but the real number they used in the early 80s.
I hate when I do that... sigh. ::clicking on EDIT::
The point of example #3 is that your fellow players/DMs might be equal to you today. But tomorrow they may be a Hiring Manager. I can't speak to you working with backstabbers. That sucks. But I'm just the DM; I'm not there.
Well getting hired as the result of playing D&D (by the 1st->5th level illusionist) does sort of require that the guy who owns the business is also the DM. But he was... and as I said, D&D does let people see how you cope with problems and which problems you volunteer for.
Another day-job I got from playing D&D was really more the result of people networking. Someone else playing the game was also involved in Phoenix Mensa (this was a monthly Mensa D&D game, which sort of highlighted the wisdom/intelligence matter discussed elsewhere... any member could play, though of course the game had its regulars). After hanging out with 'em for a while I was asked to serve on a temporary board position, which led to someone recommending me for my first professional programming position. Straight out of programming school.
The third gig was also from another D&D player. She was a semi-regular in the D&D group, but we also socialized separately (she ran the monthly general Games Night, which is how I learned to play Mah Jongg). Mind you, neither of us were in the computer industry at that point; I was in school, and she was working as a part-time tech writer while raising two little kids. We became friends, stayed in touch, and now she runs a well known company in the computer industry. A "Hey, I'm looking for work..." note in 2002 got me a writing gig 24 hours later, and that gig has continued (a few times a year) ever since.
So yes. Be nice to people. You never know where they -- or you -- will end up.
As usual, though, the book is better. The Pirates of Silicon Valley is based on Fire in the Valley: The Making of The Personal Computer by Paul Freiberger and Michael Swaine. It's out of print but your library probably has a copy. It's a very fun book.
The movie focuses on Gates/Jobs (because, hey, movies have to do things like that) and... well, not exactly "stereotypes" them, but certainly streamlines the personae. It also underplays the Digital Research history, for one thing.
But one of the illuminating facts a reader will glean from Fire in the Valley is that there were so many strong personalities vying for attention. Sure, geeks were geeks (and proud of it, dammit!), but you had lots of innovators full of confidence and dreams and the belief that these small computers can change the world. That makes me nostalgic, and I wish for more such "personalities." Only Philippe and Ellison could hold a candle to those guys.
Maybe it's just because I'm an old fart now, and I remember most of those events. (I also wrote for Computer Shopper way back when, for some of the best editors in the business, and I think Stan Veit is a mensch. I used to describe writing for Shopper as similar to writing for Playboy. They paid great, and it was a lot of fun, but who looked at the articles?)
What's nice is to know that the spirit is still alive... or at least it's trying to be. I assume y'all know about the upcoming Rebooting Computing summit, which aims to put the magic back into our field.
>>This is reminiscent of the 100 monkeys in a room with typewriters eventually being able yo produce the works of Shakespeare. Thanks to the Internet, we have demonstrated that this is not true.