Get to be known (in a good way) by dorm staffers. I knew a guy in college who had his locked room looted because an imposter told one of the dimmer RAs that he was my friend and had been locked out by his roommate. RA opened door, not knowing friend by sight, and imposter ran off with everything.
And get a strong bolt for your bike. If there's room, keep it in your room. Crooks sometimes have bolt cutters.
By all means, enjoy an evening walk. Just don't habitually do it at 4 in the morning. Campuses still have crime, and some major universities are located in the wrong part of town.
If the coffee doesn't kill you....
on
Death by Coffee?
·
· Score: 1
...then your acquaintances will. Get that much caffeine in you, you're definitely gonna be at your twitchiest. And twitchy people tend to get on one's nerves. Therefore, it's best not to try this experiment while attending the local gun & knife show.
First of all, making your grievances known is the first step. Maybe they'll change their ways or show this is definitely short term. However, if their response is, "shut up and type, baby", then they deserve everything they get. Some things to consider before making ultimatums: (1) Do you have a skill that is hard to fill in your market (i.e. obscure programming language)? (2) Is there even another place for you to go (i.e. obscure programming language)? (3) If you're saying EVERYBODY is on board, then make sure of that before approaching management. Management only has to get to one weak-willed, ambitious, backstabbing weasel to break your alliance. If there's ONE guy on your team that can do you all in, I suggest planting something on his computer and ratting him out. (4) How long would it take for management to train your replacement, and how much would that cost them? Do they have in huge projects/clients in the works? If you're working on pre-existing software, it can take quite a wall to learn all the back alleys and be productive. If you and your teammates are horrible documenters (and coders), so much the better for you on this point.
I work at a Catholic hospital, so that whole "vow of poverty" thing doesn't just apply to the clergy.
I did get a blanket from the nuns for giving blood this year, though. And we'll probably get a certificate for a free turkey again. I don't have a big family locally, so I just get the bird and anonymously give it to somebody less fortunate in my church.
Who did you enjoy more in the sack: the blonde yeoman chick from Star Trek or Adrian Zmed?
Flack from others associated with Star Trek.
on
Ask William Shatner
·
· Score: 1
I've seen and read multiple comments from you about Star Trek. What's the most angry and/or surprising response you've gotten from anyone else associated with the various series?
Code reviews are fine as long as you have somebody looking for bugs and quality of code and not some anal retentive jerk who thinks their way is the only way. I agree that code reviews can help eliminate errors by newbie programmers, but that tend to cause general disgruntlement among those who know what they're doing. The reduction in cost for bug fixes can be offset by the increase in cost from your experienced people sitting around angry.
No matter how much testing you do, the best testers are customers. I've worked on projects that passed testing by myself and three other levels, only to have it go squirrely at the customer site, usually because somebody doesn't know what they're doing, or that particular customer is the one company in the industry to do things just a little bit differently. Real customer data is sometimes the only thing that will cause a bug. For those of you in support, think of the number of times you've had to work for a week to replicate a bug reported by a customer.
There's also the definition of "bug". If a programmer gets a requirement document, and his code does what the document said, then erroneous results are due to the "garbage in, garbage out" rule, not due to faulty code. This was all too common at my last job. We did insurance software (some still do), and between all the tech folks and the customers was a thin layer of insurance professionals who knew NOTHING about software and refused to learn. It's hard to get good code without good requirements gathering, and it's hard to get good requirements gathering without people who understand the importance of it.
At my last (final?) programming job, we had the misfortune of being "led" by people with more business knowledge than computer knowledge and the inability to understand that knowing one thing doesn't necessarily mean you know everything. Thus, in addition to writing comments regarding functionality, I had to start writing comments to cover my butt.
The last thing a programmer wants is for a programming manager to do a difference check on something he has checked in, see the changed code, and then come by asking why he intentionally wrecked the program. Every time we checked a program out, we were required to make a change management comment at the beginning. On one memorable occasion I had to put the finger on one of our managers for ordering me to make some changes that were irresponsible (hard-coded variables, etc) and basically set the stage for us doing some free future programming fixes.
One thing I realized after working a couple of years is that you need to make signposts to help protect your professional reputation. Your face may be forgotten, but people 10 years down the road will know you by the code you have written. Ideally we have the time to completely rewrite bad code so that we can make our own elegant solution, but sometimes you only have 4 hours, and providing a work-around is the only way to do it. Do you want people later on thinking that you're a dumb, lazy bastard? No. If you're in a town with relatively few job oppportunities, you don't want the grapevine to start producing sour fruit with your name on it just because you've been told to do something cheesy, shady, stupid, etc.
Did I get away with putting the manager's name and directive in my comments? Not entirely, but everybody knew afterwards that I wasn't the ignoramus responsible for what I had just done.
My first job out of college was writing code (in QBASIC, no lie) for a pawn shop management package. I realized early on that I was writing code to help the shady take advantage of the disadvantages and stupid, but I could live with that. It was when I started learning the laws governing the pawn shop industry, and started writing/changing code so as to prevent our shadier customers from breaking those laws, that I started having ethical dilemmas. I was told on more than one occasion by my boss, the owner, that we were going to do whatever the customer wanted, and not do anything that wouldn't let the customer do what they wanted.
Considering myself a Christian, and trying to be a good one, I had to bail out in favor of keeping a clean soul and conscience. Sticking around and fighting wasn't really an option because (a) it was my first job, and I didn't want to get fired and earn a label, and (b) the boss was a megalomaniacal little punk who wouldn't agree it was day time if he could see the sun.
When I was in school, it was easy to know where a server or Sun station was, depending on it's theme. I haven't been in school in six years, and I still remember that Dune characters were in the EE building, Disney characters were in the grad student computer lab, band instruments in the main lab, etc.
Think of it in terms of outlining. Put everything that goes together in one theme. Admittedly newbies might have a hard time, but a cheat sheet is easy, and they'll learn it all soon enough.
If you make the names have some kind of association, that might help the learning curves. Joe's Deli - sandwhich names: club, reuben,tunamelt US Midget Association - Sneezy, Dopey, Doc etc, etc.
Assuming that customer is right, which they're not, then the vendor should get a cut of increased net profit resulting from the use of the software. Ask them what they think of that.
I've worked as a vendor, and as a consumer for a large hospital. The beta-testing is a symbiotic relationship. The user gets free, advanced release software and the ability to offer input on product development, and the vendor gets testing by real users in real situations, thereby increasing product quality, which is what both groups want.
At my current job, we are effectively a beta tester. We pay for the software, but we get it first, they listen to our input, and we get preferential treatment. That they listen to our input is obvious from the latest product release. During the implementation of this product, we found where there was A LOT of waste and undercharging for our services occurring. Does the vendor get a cut of those savings? Hell no!
We received one of these letters shortly after some Microsoft vendor reps came by for a "demonstration." Never, ever, ever, ever trust anyone that has anything to do with Microsoft. I work for a Catholic hospital (nonprofit). These guys don't care if you work for the Pope or not.
Our Technical Systems Manager, who's in charge of the hospital's network, large server room, etc, was something like 3 courses short of his CS degree when he quit school. No degree, but a cushy manager's position. CS is definitely something that you can get ahead at without a degree.
If your goal is management on the enterprise level, then maybe get the degree as a springboard for an MBA.
I don't know about gaming, but I have had a couple of programming jobs. I've noticed that the best guys around are the guys who like goofing around with stuff on there own, starting at high school. At my first job out of college (CS degree), I was quickly humbled by our alpha geek, an 18 year old kid who had not even graduated high school yet.
A good way to gain some experience in school is to get in the good graces of a professor/researcher who is doing something like you want to do. If there is an engineering research center where they're doing some work on high-end computing, or if there are professors who's specialty is graphics/imaging, then you might want to check into that.
In a nutshell, here's what I will look for if I ever start my own software company:
(1) Degrees are fine for coders, but I'd rather take the 18 year-old high school kid with experience and the lust for bytes than the guy with the Masters in CS.
(2) Programmers who take it personally when their code breaks are valuable! I'd rather have a guy who turns something in 2 days late with no obvious bugs than a guy who turns something in 2 days early and leaves a pile of bugs. Bugs aren't as easy to find in general QA as you think, and gamers are notoriously cranky when they buy a buggy game.
(3) People with other interests. Coding should be how you make the money to lead your life, not your life itself. Outside interests keep your brain fresh, and they can help contribute to creativity.
Slashdot Mirror
Get to be known (in a good way) by dorm staffers. I knew a guy in college who had his locked room looted because an imposter told one of the dimmer RAs that he was my friend and had been locked out by his roommate. RA opened door, not knowing friend by sight, and imposter ran off with everything.
And get a strong bolt for your bike. If there's room, keep it in your room. Crooks sometimes have bolt cutters.
By all means, enjoy an evening walk. Just don't habitually do it at 4 in the morning. Campuses still have crime, and some major universities are located in the wrong part of town.
...then your acquaintances will. Get that much caffeine in you, you're definitely gonna be at your twitchiest. And twitchy people tend to get on one's nerves. Therefore, it's best not to try this experiment while attending the local gun & knife show.
First of all, making your grievances known is the first step. Maybe they'll change their ways or show this is definitely short term. However, if their response is, "shut up and type, baby", then they deserve everything they get. Some things to consider before making ultimatums:
(1) Do you have a skill that is hard to fill in your market (i.e. obscure programming language)?
(2) Is there even another place for you to go (i.e. obscure programming language)?
(3) If you're saying EVERYBODY is on board, then make sure of that before approaching management. Management only has to get to one weak-willed, ambitious, backstabbing weasel to break your alliance. If there's ONE guy on your team that can do you all in, I suggest planting something on his computer and ratting him out.
(4) How long would it take for management to train your replacement, and how much would that cost them? Do they have in huge projects/clients in the works? If you're working on pre-existing software, it can take quite a wall to learn all the back alleys and be productive. If you and your teammates are horrible documenters (and coders), so much the better for you on this point.
Dave, why did you hide all those ballots in Florida during the last presidential election, and how much did "W" pay you?
I work at a Catholic hospital, so that whole "vow of poverty" thing doesn't just apply to the clergy.
I did get a blanket from the nuns for giving blood this year, though. And we'll probably get a certificate for a free turkey again. I don't have a big family locally, so I just get the bird and anonymously give it to somebody less fortunate in my church.
Who did you enjoy more in the sack: the blonde yeoman chick from Star Trek or Adrian Zmed?
I've seen and read multiple comments from you about Star Trek. What's the most angry and/or surprising response you've gotten from anyone else associated with the various series?
Code reviews are fine as long as you have somebody looking for bugs and quality of code and not some anal retentive jerk who thinks their way is the only way. I agree that code reviews can help eliminate errors by newbie programmers, but that tend to cause general disgruntlement among those who know what they're doing. The reduction in cost for bug fixes can be offset by the increase in cost from your experienced people sitting around angry.
No matter how much testing you do, the best testers are customers. I've worked on projects that passed testing by myself and three other levels, only to have it go squirrely at the customer site, usually because somebody doesn't know what they're doing, or that particular customer is the one company in the industry to do things just a little bit differently. Real customer data is sometimes the only thing that will cause a bug. For those of you in support, think of the number of times you've had to work for a week to replicate a bug reported by a customer.
There's also the definition of "bug". If a programmer gets a requirement document, and his code does what the document said, then erroneous results are due to the "garbage in, garbage out" rule, not due to faulty code. This was all too common at my last job. We did insurance software (some still do), and between all the tech folks and the customers was a thin layer of insurance professionals who knew NOTHING about software and refused to learn. It's hard to get good code without good requirements gathering, and it's hard to get good requirements gathering without people who understand the importance of it.
At my last (final?) programming job, we had the misfortune of being "led" by people with more business knowledge than computer knowledge and the inability to understand that knowing one thing doesn't necessarily mean you know everything. Thus, in addition to writing comments regarding functionality, I had to start writing comments to cover my butt.
The last thing a programmer wants is for a programming manager to do a difference check on something he has checked in, see the changed code, and then come by asking why he intentionally wrecked the program. Every time we checked a program out, we were required to make a change management comment at the beginning. On one memorable occasion I had to put the finger on one of our managers for ordering me to make some changes that were irresponsible (hard-coded variables, etc) and basically set the stage for us doing some free future programming fixes.
One thing I realized after working a couple of years is that you need to make signposts to help protect your professional reputation. Your face may be forgotten, but people 10 years down the road will know you by the code you have written. Ideally we have the time to completely rewrite bad code so that we can make our own elegant solution, but sometimes you only have 4 hours, and providing a work-around is the only way to do it. Do you want people later on thinking that you're a dumb, lazy bastard? No. If you're in a town with relatively few job oppportunities, you don't want the grapevine to start producing sour fruit with your name on it just because you've been told to do something cheesy, shady, stupid, etc.
Did I get away with putting the manager's name and directive in my comments? Not entirely, but everybody knew afterwards that I wasn't the ignoramus responsible for what I had just done.
My first job out of college was writing code (in QBASIC, no lie) for a pawn shop management package. I realized early on that I was writing code to help the shady take advantage of the disadvantages and stupid, but I could live with that. It was when I started learning the laws governing the pawn shop industry, and started writing/changing code so as to prevent our shadier customers from breaking those laws, that I started having ethical dilemmas. I was told on more than one occasion by my boss, the owner, that we were going to do whatever the customer wanted, and not do anything that wouldn't let the customer do what they wanted.
Considering myself a Christian, and trying to be a good one, I had to bail out in favor of keeping a clean soul and conscience. Sticking around and fighting wasn't really an option because (a) it was my first job, and I didn't want to get fired and earn a label, and (b) the boss was a megalomaniacal little punk who wouldn't agree it was day time if he could see the sun.
When I was in school, it was easy to know where a server or Sun station was, depending on it's theme. I haven't been in school in six years, and I still remember that Dune characters were in the EE building, Disney characters were in the grad student computer lab, band instruments in the main lab, etc.
Think of it in terms of outlining. Put everything that goes together in one theme. Admittedly newbies might have a hard time, but a cheat sheet is easy, and they'll learn it all soon enough.
If you make the names have some kind of association, that might help the learning curves.
Joe's Deli - sandwhich names: club, reuben,tunamelt
US Midget Association - Sneezy, Dopey, Doc
etc, etc.
Assuming that customer is right, which they're not, then the vendor should get a cut of increased net profit resulting from the use of the software. Ask them what they think of that.
I've worked as a vendor, and as a consumer for a large hospital. The beta-testing is a symbiotic relationship. The user gets free, advanced release software and the ability to offer input on product development, and the vendor gets testing by real users in real situations, thereby increasing product quality, which is what both groups want.
At my current job, we are effectively a beta tester. We pay for the software, but we get it first, they listen to our input, and we get preferential treatment. That they listen to our input is obvious from the latest product release. During the implementation of this product, we found where there was A LOT of waste and undercharging for our services occurring. Does the vendor get a cut of those savings? Hell no!
We received one of these letters shortly after some Microsoft vendor reps came by for a "demonstration." Never, ever, ever, ever trust anyone that has anything to do with Microsoft. I work for a Catholic hospital (nonprofit). These guys don't care if you work for the Pope or not.
Our Technical Systems Manager, who's in charge of the hospital's network, large server room, etc, was something like 3 courses short of his CS degree when he quit school. No degree, but a cushy manager's position. CS is definitely something that you can get ahead at without a degree.
If your goal is management on the enterprise level, then maybe get the degree as a springboard for an MBA.
(1) At least we don't have an intergalactic cheerleader always "feeling" something on the bridge.
(2) I didn't realize Vulcan chicks had such large....assets...in proportion to their height.
(3) To be fair to the southern engineering guy, nobody else knows what they're doing, either.
I don't know about gaming, but I have had a couple of programming jobs. I've noticed that the best guys around are the guys who like goofing around with stuff on there own, starting at high school. At my first job out of college (CS degree), I was quickly humbled by our alpha geek, an 18 year old kid who had not even graduated high school yet. A good way to gain some experience in school is to get in the good graces of a professor/researcher who is doing something like you want to do. If there is an engineering research center where they're doing some work on high-end computing, or if there are professors who's specialty is graphics/imaging, then you might want to check into that. In a nutshell, here's what I will look for if I ever start my own software company: (1) Degrees are fine for coders, but I'd rather take the 18 year-old high school kid with experience and the lust for bytes than the guy with the Masters in CS. (2) Programmers who take it personally when their code breaks are valuable! I'd rather have a guy who turns something in 2 days late with no obvious bugs than a guy who turns something in 2 days early and leaves a pile of bugs. Bugs aren't as easy to find in general QA as you think, and gamers are notoriously cranky when they buy a buggy game. (3) People with other interests. Coding should be how you make the money to lead your life, not your life itself. Outside interests keep your brain fresh, and they can help contribute to creativity.