I agree that the medical research might be more worthwhile to support, but AFAIK there are only Wintel clients available. (Case in point, United Devices and even your own link to Intel.)
That leaves an awful lot of non-intel boxes, and even non-windows intel boxes with spare cycles that can't participate. Until they have the option to do so, I anticipate a lot of cycles going to 'less worthy' causes...
The best compromise between the 'fortress of solitude' attitude that single person offices cultivates, and the complete lack of privacy that most cube farms generates, is the 2-3 person office.
You still get a more private environment, you have a door you can close, if you all agree in tastes, you can play music without headphones. But you're not isolated... you can still easily ask questions or pair program or have another pair of eyes debug with you. In a pinch, you can squeeze in a small team for team meetings when all the conference rooms are filled.
It may not be as ego boosting as having single offices, but in my experience, it's a far better arrangement. Especially when you can drop a whole team into a couple of adjacent offices... you make it easy to find people, and you get some team building for free (as long as you can live with your officemates).
On the other hand, if you have the math background, there are a lot of places where algorithm design can use that expertise. Often, it's the non-intuitive, mathematically based algorithms that perform the best, rather than the intuitive (sometimes brute force) algorithms those without the background are likely to design. Take quicksort for an example!
Java is easier to learn. Hence you can push out more graduates from Compsci courses with it. Unfortunately, you can't apply those guys to say, kernel programming or embedded systems work because they are clueless w.r.t memory management and the guts of the machine.
But you know what, school is a place to learn!
When I got my CS degree, Java wasn't around, and C++ was just starting to be taught... often with the concept that OO would make it easier to learn. And you know what? The C and C++ I learned in school did very little to prepare me for how the languages were really used in industry.
Even if a student had the best, most industry oriented schooling available, I doubt they could go immediately into kernel programming or embedded systems work and be productive the first day... And a lot of schools will acknowledge that fact.
Schools are there to give you a solid understanding of how languages work, how to build the basic underpinnings of software, not the detailed knowledge of how software is applied in industry. Especially since that changes for every domain that is out there. As long as they know one language, it becomes simpler to pick up another, and to learn the nuances of that new language.
And there are major java projects that aren't even J2EE, just J2SE.
For one, I'm developing/supporting a satellite scheduling system for a commercial imaging satellite, in Java. And as it evolves, it'll be replacing other code written in C and C++.
To claim that all major systems are still C based is ridiculous...
And as an earlier post mentioned, an OSX for Unix/Linux users would be great! Include things like "How do I do task Y now that/etc/Z isn't there?" and how unix/linux configs map into NetInfo.
And the big ones I'm really, really waiting for are some more Mac OS X programming books. A few have trickled out, but we need more.
For example, Learning Cocoa was interesting, but I'm really looking for using Java instead of Objective-C. The only reference I've found is Wrox's Early Adopter's book, and there's no way I'm going to chip out $35 for a book less than 1/2" thick (and it's the same price as many of their 2" thick books!), especially when only half of it is coding, and it's pretty likely to be obsolete very quickly.
And she loves her iMac. But that's not necessarily the truth for all artists. In this case, I think it's mainly brand loyalty, but it's loyalty based on ease of use. (And she has used Wintels, but she always complains about them being non-intuitive.)
Her favorite periperal is an Wacom Intuos tablet. She thinks that most artists that also work outside of a digital medium would really appreciate the translation of pen strokes to a paint/drawing program. Make sure the platform you choose has the capability to support a tablet.
And her favorite art program is Photoshop. I've tried to get her using GIMP and OSX, but Photoshop is too ingrained in her past and she doesn't want to relearn everything. And since Photoshop won't run natively on OSX, it's hard to get her to leave MacOS 9. But if you've got a $1000 price limit, you're probably not going to get Photoshop, unless you already have a copy, or you have a separate software budget.
Perhaps the most important thing to consider is if the artist in question has a OS preference... if they've used something before, and a loathe to relearn day to day tasks, a lot of your choice is already made for you. And make sure you don't miss any of those "forgotten" requirements... like "But I really wanted Photoshop!"
I got an Iomega HipZip as a gift last spring, and I haven't had any problems sharing between my macs at home and my win2k at work.
It uses 40MB PocketZip disks, which can be a little limiting, but the media is cheaper by the MB, and it allows you to swap disks with other users easily.
You can still find them at your friendly neighborhood comic store, though the real gems are the first 12 issues, not the later runs with different writers / artists.
Obviously, you're not going to be friends with everyone you work with. But it certainly is possible. One definite advantage is a work environment that encourages having fun.
For example, a bunch of us from my first job still share a yahoo groups email list and get together every few months. Why? Because we had so much fun at work. (Our shared office was even nicknamed "Slack Central" and we all became known as "Slackers". In this case, slacker was a badge of honor, for a slacking attitude, not an indication of a slacking work ethic.) In fact we're getting together for a Xmas event with all the spouses and children included.
And another place I worked, with just a handful of people, we had beers and board games every friday after 4:30 or so ("Beer-thirty"). Family were welcome to stop by and join in. And a number of us still get together for lunch and occasional poker nights.
And the biggest reason to make friends at work is so that you can network with them the next time there's a recession and you get laid off.
My main point was that ObjectSpace provides the toolkits for doing multithreading and communications I/O.
For example (IIRC), you can instantiate threads like this:
Thread t1 = new Thread("WorkerThread", &MyWorkerClass::run);
And things like sockets also have a nice OO abstraction that hides the platform (or posix) details.
I haven't used Qt, so I didn't know about the container classes, however, the other uses of ObjectSpace seem to fit the needs of this project quite nicely. Though, if no STL was going to be used anywhere else, this would add quite a bit of overhead.
ObjectSpace provides a good, cross platform STL implementation, with toolkits that build upon it. ObjectSpace's C++ Toolkits cover multithreading with mutexes, semaphores, reference counting, communication with streams, pipes, sockets and files. They also provide some useful tools in terms of time and regexp.
It's been a few years since I've used them, but I used them on solaris and hpux with both the proprietary compilers and gcc, and I know their headers had provisions for the MS compiler.
You probably don't have the idea yet but believe me, it is funny (Could some of you other Aussies back me up here before the karma police lock me up?)
I'll back you up, and I'm not even an Aussie. I'm from the US, but I was working over the pond for a month a few years ago. And this commercial had me rolling on the floor of my hotel room laughing, not just once, but at least the first 5 or 6 times I saw it. And it still cracks me up...
I didn't have too many problems getting through school, but I will encourage you to stick it out and try working for a while afterward. School and work are completely different environments. Here's some points to consider:
Not all jobs are mindless, boring, and riddled with bad middle management. CS people in the real world aren't doing the same things as CS people in academia. They apply what they know to widely varying domains of problems. Look for a job in an intersting domain, and check it out.
If you have a liking for aerospace, look at defense contracting companies, or satellite imaging companies. Lots of potential for interesting work there! Some people have a knack for telecom and working with low level hardware. If you've got a background in other sciences, there's a wealth of possibilities there... biotech, computational chemistry, genome work, all of these are highly dependant on specialized software.
Avoid things like "Enterprise Application Integration" unless you really are in to middleware and writing glue code. Some people like this, but I find it gets very repetitious and boring quickly.
If you don't know what you want to work with, a consulting company can get you exposure to a lot of domains and technologies. But they can also wear you down with mind numbing projects that you don't care about.
I guess my big point is that academic projects bear little relation to projects in the real world. It's completely different. Beyond your basic skills, and knowledge of design/development process, everything you learn at a job will be new. And very little of it falls into that "grading bucket" where someone looks at it once and puts it in a filing cabinet.
Right now, you should just look at school as a stepping stone... something to be passed through on the way to a more interesting application of what you've learned.
Grad school will break you out of the its-been-done rut you seem to be in.
My experience was pretty much the opposite. I remember my undergrad days being a lot more interesting/fun than grad school. Grad school had more depth, less breadth, and more academics who scoffed at industry trends instead of looking for innovative ways to apply or improve them.
Though, I was also going to grad school part time while working in the industry...
My position on the matter is that the industry and academia have very little overlap. While I needed the academic base to start in industry, very little of what I learned in school (undergrad or grad) was immediately applicable to industry. And I've found working much more rewarding than school... real problems, real solutions, real users. While they do bring their own load of misery, it's better than reinventing basic data structures to prove you understood a lecture.
And if it turns out that you can't face the industry, then you've earned some cash to pay for grad school.
One of my former coworkers had a relatively accurate method of predicting schedules using a Magic 8 Ball. For example:
"Will this project be done in 8 weeks?"
shake "Outlook not good"
"OK, how about 12 weeks?"
shake "Maybe"
"Hmmm. Let's make it 15 to be sure..."
shake "Yes"
"Yep, this project will take 15 weeks."
And it really annoys managers when they discover that you used a Magic 8 Ball, and then it confounds them when it is right...
That's exactly the sort of attitude that has caused the sort of spectactular failures of software projects to be accepted as the norm. Software Engineering is *not* "hacking" or "coding" or "programming", it's *engineering*, like building a bridge or a skyscraper. Yes, those projects go over time and budget too sometimes, but they are the exception rather than the rule.
I wish I had the text book I used for "Intro to Software Engineering" handy, because there was a great analogy to refute this point. I think you'll find, if you look at any reference that is written from within the Software Engineering domain (instead of observing the domain from some other branch of engineering), that the problem domain in Software Engineering is unlike any other kind of engineering.
The biggest difference is the difference in requirements. For any other engineering discipline, the requirements are well known, fixed, and known before construction begins. With Software Engineering, the requirements are often vague and continually changing (whether from customer requirements or environment requirements), and software and software development are expected to be flexible enough to handle these difficulties.
I believe the analogy in my textbook goes something like this: Imagine building a skyscraper, when you begin, you only know it's tall, and has elevators. Don't worry about testing the tensile strength of the girders, they're the latest alloy, and the seller says they're stronger than steel. After you begin construction, the customer tells you it needs to be 100 stories tall, and also include stairs. It's still early (only 20 stories have been built), so that can be handled. After 50 stories are up, it's determined that you need a couple basement levels. It's an obvious addition to the original plan, so just add 10% more time. At about 90 stories, the customer changes the requirements for how it looks, (make the outside glass instead of concrete, and tack on another 10 stories). But once it's done, you aren't finished. The next release of the skyscaper needs a helipad on the roof, and a balcony at floor 87. It doesn't matter that it's not in the original design, your skyscraper must still be malleable. And don't forget that 3 years later, the city is going to change the underlying support structure, and that concrete foundation must be replaced with one made of the latest MS-ferro-ceramic substance (TM). Never done it before? That's OK, it's just a skyscraper. And remember, minimal downtime is allowed when you slip the new version in place of the old one.
That's why Software Engineering is unlike any other engineering field. If bridges had to be as malleable as software is, we'd never be able to drive across them because they'd always be down for repairs.
I'm not saying that estimations can never be better, they can. But it will require an environment more like that enjoyed by other engineering disciplines. The problem must be known completely before giving requirements to the builders. The requirements can't be changed in the middle of construction. Allow for the fact that anytime a fundamental change is made, the entire structure may require modifications to support the new components. And ensure there is enough time to test it completely... You would never build a bridge with new, untested materials and expect it to be safe enough for the public to use, especially after racing to complete it in time for the ribbon cutting ceremony that was scheduled before construction began.
I agree that a call shortly after the interview is annoying.
But when there are 200 candidates, a phone call a week or so later might be just the thing to refresh the hiring manager's memory. And if there's been a weekly hiring meeting to review the interviews, you might be able to find out whether you've made the cut so far.
I'd rather know I didn't make it now, so I can focus on other interviews, rather than wait for weeks to hear anything from the company. And if I'm reassured that I'm still in the running, I know I should pay attention to what's going on, and keep them informed of other offers.
Of course, it could be at the level of phone screening 200 people out of the 1000 resumes they received. I certainly hope they aren't holding 200 in person interviews for just 3 positions.
And if they are, it seems like this company has some major problems with handling logistics. Be sure that this kind of wasted effort wouldn't affect the management in your area as well...
Being on both sides of the interview fence, I find that those that are a clear cut above the rest get the offer, and soon. The decision is usually made the day of the interview. I've never waited more than 12 hours for a positive response.
I've been on both sides of that fence as well, and I can easily disagree with that 12 hour window. Especially now that the tech market has had its downturn.
I know I've recommended a person highly after their interview, and had management and HR drag their feet so long that a week later the candidate calls back saying that they've gotten other offers, are we really going to make one or not? Sometimes it's that huge pile of resumes bogging them down, and sometimes they just drop the ball for no good reason.
And even for my current position, the company told me they'd make me an offer, and it took about 2 weeks to get something on paper. Every time I talked with them, the process get held up by budget reallocations, hiring freezes, etc. Finally everything broke loose, and once I had the offer, it took less than a day to finalize it.
Again, a lot of these problems are caused by the downturn... when it's an employer's market, they don't feel much pressure to hurry the process.
LinuxPPC used to be a good platform. I had it running on my B&W G3 for quite a while as a student. But since I finished off my degree I hadn't had a burning need to boot linux.
Armed with a few spare hours last weekend, I decided to give it a boot and see how it compared with my new installation of 10.1... And I couldn't boot. I figured that this was a sign to go get the latest distro and install a 2.4 kernel. But lo and behold, I seemed to already have the latest version of LinuxPPC (2000). And half the links on their pages were broken.
Has LinuxPPC really stalled out completely? Is anybody out there still working on the distro?
Freedom of speech is *harmed* by spam; it is harder and harder to talk to people, because more and more of them need a variety of local blacklists, buggy procmail rules, or other harsh filters, just to use their mailboxes *at all*. My friend can't email her dad, because the first time he checked his mailbox, he had a thousand pieces of spam.
I agree with you, but at the same time, this is a very tricky issue that impacts someone negatively no matter what you do. For a counter example, my dad can't email me at my work from his work, because my company uses a blacklist, and his work's clueless company has an open relay.
In general, I support the idea of getting people to close their relays, but there just doesn't seem to be much of a "helpful" attitude to getting them closed. All my dad knew was that sending email to me at work was "broken"... the small note inserted in the headers didn't tell him anything meaningful, and they didn't tell him to refer the problem to the postmaster. It was only after he forwarded me a bounced message (at another provider) that I diagnosed his trouble and told him to see his admins.
It seems that this approach to preserving free speech for some is limiting speech for others, even when they aren't directly responsible for the behavior that is being blocked in the first place. Maybe the strongarm is what is needed to effect a change, but there seems to be little help offered to the offending parties before they get blacklisted.
I've been a Qwest.net user for a long time. I'm finally moving my accounts elsewhere because I refuse to use MSN.
This requirement is probably derived from the fact that the Qwest.net infrastructure is POP3 only. Thus, since you're going to be using MSN via the Qwest.net infrastructure, you're stuck with POP3 until Qwest upgrades.
Slashdot Mirror
Has anyone who's seen the preview comment on IPSec?
Do we get a lickable Cocoa interface, or is it dependent on the command line?
I agree that the medical research might be more worthwhile to support, but AFAIK there are only Wintel clients available. (Case in point, United Devices and even your own link to Intel.)
That leaves an awful lot of non-intel boxes, and even non-windows intel boxes with spare cycles that can't participate. Until they have the option to do so, I anticipate a lot of cycles going to 'less worthy' causes...
The best compromise between the 'fortress of solitude' attitude that single person offices cultivates, and the complete lack of privacy that most cube farms generates, is the 2-3 person office.
You still get a more private environment, you have a door you can close, if you all agree in tastes, you can play music without headphones. But you're not isolated... you can still easily ask questions or pair program or have another pair of eyes debug with you. In a pinch, you can squeeze in a small team for team meetings when all the conference rooms are filled.
It may not be as ego boosting as having single offices, but in my experience, it's a far better arrangement. Especially when you can drop a whole team into a couple of adjacent offices... you make it easy to find people, and you get some team building for free (as long as you can live with your officemates).
On the other hand, if you have the math background, there are a lot of places where algorithm design can use that expertise. Often, it's the non-intuitive, mathematically based algorithms that perform the best, rather than the intuitive (sometimes brute force) algorithms those without the background are likely to design. Take quicksort for an example!
Java is easier to learn. Hence you can push out more graduates from Compsci courses with it. Unfortunately, you can't apply those guys to say, kernel programming or embedded systems work because they are clueless w.r.t memory management and the guts of the machine.
But you know what, school is a place to learn!
When I got my CS degree, Java wasn't around, and C++ was just starting to be taught... often with the concept that OO would make it easier to learn. And you know what? The C and C++ I learned in school did very little to prepare me for how the languages were really used in industry.
Even if a student had the best, most industry oriented schooling available, I doubt they could go immediately into kernel programming or embedded systems work and be productive the first day... And a lot of schools will acknowledge that fact.
Schools are there to give you a solid understanding of how languages work, how to build the basic underpinnings of software, not the detailed knowledge of how software is applied in industry. Especially since that changes for every domain that is out there. As long as they know one language, it becomes simpler to pick up another, and to learn the nuances of that new language.
And there are major java projects that aren't even J2EE, just J2SE.
For one, I'm developing/supporting a satellite scheduling system for a commercial imaging satellite, in Java. And as it evolves, it'll be replacing other code written in C and C++.
To claim that all major systems are still C based is ridiculous...
And as an earlier post mentioned, an OSX for Unix/Linux users would be great! Include things like "How do I do task Y now that /etc/Z isn't there?" and how unix/linux configs map into NetInfo.
And the big ones I'm really, really waiting for are some more Mac OS X programming books. A few have trickled out, but we need more.
For example, Learning Cocoa was interesting, but I'm really looking for using Java instead of Objective-C. The only reference I've found is Wrox's Early Adopter's book, and there's no way I'm going to chip out $35 for a book less than 1/2" thick (and it's the same price as many of their 2" thick books!), especially when only half of it is coding, and it's pretty likely to be obsolete very quickly.
Some people already have drilled holes in the side...
Check out the BlueIce G4
And overclocking is just a matter of jumper settings for many machines. Surf over to XLR8YourMac for more information
And she loves her iMac. But that's not necessarily the truth for all artists. In this case, I think it's mainly brand loyalty, but it's loyalty based on ease of use. (And she has used Wintels, but she always complains about them being non-intuitive.)
Her favorite periperal is an Wacom Intuos tablet. She thinks that most artists that also work outside of a digital medium would really appreciate the translation of pen strokes to a paint/drawing program. Make sure the platform you choose has the capability to support a tablet.
And her favorite art program is Photoshop. I've tried to get her using GIMP and OSX, but Photoshop is too ingrained in her past and she doesn't want to relearn everything. And since Photoshop won't run natively on OSX, it's hard to get her to leave MacOS 9. But if you've got a $1000 price limit, you're probably not going to get Photoshop, unless you already have a copy, or you have a separate software budget.
Perhaps the most important thing to consider is if the artist in question has a OS preference... if they've used something before, and a loathe to relearn day to day tasks, a lot of your choice is already made for you. And make sure you don't miss any of those "forgotten" requirements... like "But I really wanted Photoshop!"
I got an Iomega HipZip as a gift last spring, and I haven't had any problems sharing between my macs at home and my win2k at work.
It uses 40MB PocketZip disks, which can be a little limiting, but the media is cheaper by the MB, and it allows you to swap disks with other users easily.
You can still find them at your friendly neighborhood comic store, though the real gems are the first 12 issues, not the later runs with different writers / artists.
Or you can order them from the distributor (New England Comics) directly.
Obviously, you're not going to be friends with everyone you work with. But it certainly is possible. One definite advantage is a work environment that encourages having fun.
For example, a bunch of us from my first job still share a yahoo groups email list and get together every few months. Why? Because we had so much fun at work. (Our shared office was even nicknamed "Slack Central" and we all became known as "Slackers". In this case, slacker was a badge of honor, for a slacking attitude, not an indication of a slacking work ethic.) In fact we're getting together for a Xmas event with all the spouses and children included.
And another place I worked, with just a handful of people, we had beers and board games every friday after 4:30 or so ("Beer-thirty"). Family were welcome to stop by and join in. And a number of us still get together for lunch and occasional poker nights.
And the biggest reason to make friends at work is so that you can network with them the next time there's a recession and you get laid off.
My main point was that ObjectSpace provides the toolkits for doing multithreading and communications I/O.
For example (IIRC), you can instantiate threads like this:
Thread t1 = new Thread("WorkerThread", &MyWorkerClass::run);
And things like sockets also have a nice OO abstraction that hides the platform (or posix) details.
I haven't used Qt, so I didn't know about the container classes, however, the other uses of ObjectSpace seem to fit the needs of this project quite nicely. Though, if no STL was going to be used anywhere else, this would add quite a bit of overhead.
ObjectSpace provides a good, cross platform STL implementation, with toolkits that build upon it. ObjectSpace's C++ Toolkits cover multithreading with mutexes, semaphores, reference counting, communication with streams, pipes, sockets and files. They also provide some useful tools in terms of time and regexp.
It's been a few years since I've used them, but I used them on solaris and hpux with both the proprietary compilers and gcc, and I know their headers had provisions for the MS compiler.
You probably don't have the idea yet but believe me, it is funny (Could some of you other Aussies back me up here before the karma police lock me up?)
I'll back you up, and I'm not even an Aussie. I'm from the US, but I was working over the pond for a month a few years ago. And this commercial had me rolling on the floor of my hotel room laughing, not just once, but at least the first 5 or 6 times I saw it. And it still cracks me up...
Cheers!
I didn't have too many problems getting through school, but I will encourage you to stick it out and try working for a while afterward. School and work are completely different environments. Here's some points to consider:
Not all jobs are mindless, boring, and riddled with bad middle management. CS people in the real world aren't doing the same things as CS people in academia. They apply what they know to widely varying domains of problems. Look for a job in an intersting domain, and check it out.
If you have a liking for aerospace, look at defense contracting companies, or satellite imaging companies. Lots of potential for interesting work there! Some people have a knack for telecom and working with low level hardware. If you've got a background in other sciences, there's a wealth of possibilities there... biotech, computational chemistry, genome work, all of these are highly dependant on specialized software.
Avoid things like "Enterprise Application Integration" unless you really are in to middleware and writing glue code. Some people like this, but I find it gets very repetitious and boring quickly.
If you don't know what you want to work with, a consulting company can get you exposure to a lot of domains and technologies. But they can also wear you down with mind numbing projects that you don't care about.
I guess my big point is that academic projects bear little relation to projects in the real world. It's completely different. Beyond your basic skills, and knowledge of design/development process, everything you learn at a job will be new. And very little of it falls into that "grading bucket" where someone looks at it once and puts it in a filing cabinet.
Right now, you should just look at school as a stepping stone... something to be passed through on the way to a more interesting application of what you've learned.
Grad school will break you out of the its-been-done rut you seem to be in.
My experience was pretty much the opposite. I remember my undergrad days being a lot more interesting/fun than grad school. Grad school had more depth, less breadth, and more academics who scoffed at industry trends instead of looking for innovative ways to apply or improve them.
Though, I was also going to grad school part time while working in the industry...
My position on the matter is that the industry and academia have very little overlap. While I needed the academic base to start in industry, very little of what I learned in school (undergrad or grad) was immediately applicable to industry. And I've found working much more rewarding than school... real problems, real solutions, real users. While they do bring their own load of misery, it's better than reinventing basic data structures to prove you understood a lecture.
And if it turns out that you can't face the industry, then you've earned some cash to pay for grad school.
One of my former coworkers had a relatively accurate method of predicting schedules using a Magic 8 Ball. For example:
"Will this project be done in 8 weeks?"
shake "Outlook not good"
"OK, how about 12 weeks?"
shake "Maybe"
"Hmmm. Let's make it 15 to be sure..."
shake "Yes"
"Yep, this project will take 15 weeks."
And it really annoys managers when they discover that you used a Magic 8 Ball, and then it confounds them when it is right...
That's exactly the sort of attitude that has caused the sort of spectactular failures of software projects to be accepted as the norm. Software Engineering is *not* "hacking" or "coding" or "programming", it's *engineering*, like building a bridge or a skyscraper. Yes, those projects go over time and budget too sometimes, but they are the exception rather than the rule.
I wish I had the text book I used for "Intro to Software Engineering" handy, because there was a great analogy to refute this point. I think you'll find, if you look at any reference that is written from within the Software Engineering domain (instead of observing the domain from some other branch of engineering), that the problem domain in Software Engineering is unlike any other kind of engineering.
The biggest difference is the difference in requirements. For any other engineering discipline, the requirements are well known, fixed, and known before construction begins. With Software Engineering, the requirements are often vague and continually changing (whether from customer requirements or environment requirements), and software and software development are expected to be flexible enough to handle these difficulties.
I believe the analogy in my textbook goes something like this: Imagine building a skyscraper, when you begin, you only know it's tall, and has elevators. Don't worry about testing the tensile strength of the girders, they're the latest alloy, and the seller says they're stronger than steel. After you begin construction, the customer tells you it needs to be 100 stories tall, and also include stairs. It's still early (only 20 stories have been built), so that can be handled. After 50 stories are up, it's determined that you need a couple basement levels. It's an obvious addition to the original plan, so just add 10% more time. At about 90 stories, the customer changes the requirements for how it looks, (make the outside glass instead of concrete, and tack on another 10 stories). But once it's done, you aren't finished. The next release of the skyscaper needs a helipad on the roof, and a balcony at floor 87. It doesn't matter that it's not in the original design, your skyscraper must still be malleable. And don't forget that 3 years later, the city is going to change the underlying support structure, and that concrete foundation must be replaced with one made of the latest MS-ferro-ceramic substance (TM). Never done it before? That's OK, it's just a skyscraper. And remember, minimal downtime is allowed when you slip the new version in place of the old one.
That's why Software Engineering is unlike any other engineering field. If bridges had to be as malleable as software is, we'd never be able to drive across them because they'd always be down for repairs.
I'm not saying that estimations can never be better, they can. But it will require an environment more like that enjoyed by other engineering disciplines. The problem must be known completely before giving requirements to the builders. The requirements can't be changed in the middle of construction. Allow for the fact that anytime a fundamental change is made, the entire structure may require modifications to support the new components. And ensure there is enough time to test it completely... You would never build a bridge with new, untested materials and expect it to be safe enough for the public to use, especially after racing to complete it in time for the ribbon cutting ceremony that was scheduled before construction began.
I agree that a call shortly after the interview is annoying.
But when there are 200 candidates, a phone call a week or so later might be just the thing to refresh the hiring manager's memory. And if there's been a weekly hiring meeting to review the interviews, you might be able to find out whether you've made the cut so far.
I'd rather know I didn't make it now, so I can focus on other interviews, rather than wait for weeks to hear anything from the company. And if I'm reassured that I'm still in the running, I know I should pay attention to what's going on, and keep them informed of other offers.
Of course, it could be at the level of phone screening 200 people out of the 1000 resumes they received. I certainly hope they aren't holding 200 in person interviews for just 3 positions.
And if they are, it seems like this company has some major problems with handling logistics. Be sure that this kind of wasted effort wouldn't affect the management in your area as well...
Being on both sides of the interview fence, I find that those that are a clear cut above the rest get the offer, and soon. The decision is usually made the day of the interview. I've never waited more than 12 hours for a positive response.
I've been on both sides of that fence as well, and I can easily disagree with that 12 hour window. Especially now that the tech market has had its downturn.
I know I've recommended a person highly after their interview, and had management and HR drag their feet so long that a week later the candidate calls back saying that they've gotten other offers, are we really going to make one or not? Sometimes it's that huge pile of resumes bogging them down, and sometimes they just drop the ball for no good reason.
And even for my current position, the company told me they'd make me an offer, and it took about 2 weeks to get something on paper. Every time I talked with them, the process get held up by budget reallocations, hiring freezes, etc. Finally everything broke loose, and once I had the offer, it took less than a day to finalize it.
Again, a lot of these problems are caused by the downturn... when it's an employer's market, they don't feel much pressure to hurry the process.
LinuxPPC used to be a good platform. I had it running on my B&W G3 for quite a while as a student. But since I finished off my degree I hadn't had a burning need to boot linux.
Armed with a few spare hours last weekend, I decided to give it a boot and see how it compared with my new installation of 10.1... And I couldn't boot. I figured that this was a sign to go get the latest distro and install a 2.4 kernel. But lo and behold, I seemed to already have the latest version of LinuxPPC (2000). And half the links on their pages were broken.
Has LinuxPPC really stalled out completely? Is anybody out there still working on the distro?
Freedom of speech is *harmed* by spam; it is harder and harder to talk to people, because more and more of them need a variety of local blacklists, buggy procmail rules, or other harsh filters, just to use their mailboxes *at all*. My friend can't email her dad, because the first time he checked his mailbox, he had a thousand pieces of spam.
I agree with you, but at the same time, this is a very tricky issue that impacts someone negatively no matter what you do. For a counter example, my dad can't email me at my work from his work, because my company uses a blacklist, and his work's clueless company has an open relay.
In general, I support the idea of getting people to close their relays, but there just doesn't seem to be much of a "helpful" attitude to getting them closed. All my dad knew was that sending email to me at work was "broken"... the small note inserted in the headers didn't tell him anything meaningful, and they didn't tell him to refer the problem to the postmaster. It was only after he forwarded me a bounced message (at another provider) that I diagnosed his trouble and told him to see his admins.
It seems that this approach to preserving free speech for some is limiting speech for others, even when they aren't directly responsible for the behavior that is being blocked in the first place. Maybe the strongarm is what is needed to effect a change, but there seems to be little help offered to the offending parties before they get blacklisted.
Just my $0.02.
I've been a Qwest.net user for a long time. I'm finally moving my accounts elsewhere because I refuse to use MSN.
This requirement is probably derived from the fact that the Qwest.net infrastructure is POP3 only. Thus, since you're going to be using MSN via the Qwest.net infrastructure, you're stuck with POP3 until Qwest upgrades.