Exactly how many IT workers do you know who will need Social Security when in all likelihood they've been in IT their whole lives making IT money? I don't know about you but by the time I turn 65 I plan to have some kind of nest egg built up. If you're in IT you're not exactly hurting for money (or you're doing it wrong).
It's possible I've used the wrong word here, but when I talk about being passionate about your job I'm not talking about being "emotional" about your job.
What I'm talking about is going above and beyond the minimum required effort. The absolute minimum required effort is usually that the software works, it satisfies the client's requirements, it comes in under or at budget (this is obviously more at the project level and then individual developer level), and that it can be maintained. Above and beyond is about craftsmanship. It is about TDD, refactoring until you have made your best effort to get the code clean, and pushing back on ridiculous requirement to get to the true business need. It's about taking the time to learn new technologies off the clock, it's about giving back to the community that has given you so much (Do you, for even one moment, imagine that you got where you are because you learned and worked in a vaccum?). Whether this giving back mean you contribute to open source project, you maintain a blog, attend or present at user group meetings, etc is up to you, but if you're going to work with me I want to see that you're active and you give a shit.
don't think that I care more about your projects than my family or my personal obligations
As a family man myself I completely understand your sentiment. There is certainly a balance to be held. I spend time with my family and love my children, but I also know that nobody, noboby owes me a free ride and it is up to me to excel and continue to learn and grow as a developer outside of the 9-5. Clients almost never pay me to learn on their dime, and when I talk about being passionate I'm talking about understanding that you need to give enough of a shit to grow on your own and give back. I want to work with developers who are on that wave length and do more than clock in, write their 500 LOC/day, clock out and promptly forget about programming until 9AM the next day.
No problem, it is always nice to have a good conversation, not to mention being pleasantly surprised by a thoughtful and polite AC:-). Good luck in your career!
If you're in it purely for the money you're in it for purely the wrong reason. Passion is is not stupid, or a sign of weakness. Passion is caring about the work that you do, and therefore about the work that others do because ultimately their work is what matters. IT is not an end unto itself, it is a means to accomplish other things. Being passionate shows you care about the quality of your work and the quality of others' work. If you come to the table and you can't show passion about your work and your overriding value is money then hit the road. There are thousands of others just like you who would love the chance to show they can do the job, and they may or may not charge your rate.
if my best code I've written is proprietary, how can I show that to you?
This is why I look for recommendations and blog posts. I'm in the same boat that you're in, which is that my best code is proprietary. The solutions is to have others recommend your work and by writing about the things you learn. By this I don't mean that you post specifics about your code as it is the implementation of the concept or technique you have learned (not to mention posting chunks of proprietary code will get you fired or sued). It isn't the specific code that matters, it is showing that you have the skills, knowledge, ability to learn and care enough to share these things for the benefit of others.
Makes me be the question: you want someone who just puts stuff online to show off, or do you want someone with a track record of getting the job done?
So first of all you're looking at this the wrong way. You're not "showing off" per se. You're selling your services in most honest manner you can. You have to get over the idea that you shouldn't talk about yourself. You're in business, and in business no one will sell for you. You have to be your own champion, and that means being willing to put yourself out there, talk about what you've learned and show people why they should hire you.
To answer you question "getting the job done" is obviously the important thing. The trick is showing people who have no idea who you are or what you've done that you can, in fact, get the job done. When they are interviewing you they are trying to determine if it is a "safe bet" to hire you on, and make no mistake it is a bet. Chances are neither they nor you will know if it is a good fit until after the fact, but you can help them make that decision and put them somewhat at ease by talking about yourself and sharing your experience ahead of the conversation.
My job as the technical interviewer is to determine if the things you say you know and have done matches up to reality. You'll make my job easier if you can show me that concretely, and therefore make it more likely that I'll recommend you to continue in the hiring process.
I pay scant attention to resumes, except as a starting point and a way to see if you can string words together in a syntactically correct manner. Not having an online presence won't hurt you necessarily. After the receiving a resume the first thing I'll do is to google you to see if you have:
Public code contributions (Github, BitBucket, SourceForge, Launchpad, etc). This is probably the most important bullet on this list. I want to see that you're passionate about software development, and that you're taking the time to grow and learn outside of your day job.
Any kind of technical blog. I don't care about your blog about your love of spaghetti, I want to see if you are capable of communicating technical ideas, and more importantly that you see the value of sharing your knowledge with others. I'm not interested in working with introverts or knowledge hoarders, I want to work with people who are interested in building others up, making an impact on the lives of others, and helping other developers to grow.
Recommendations on LinkedIn. I don't care about endorsements; they're essentially worthless as the endorser doesn't need to put any thought into the skill being endorsed and how well the individual actually performed that skill. They simply click the endorse button and move on. Recommendations are different as they require some thought on the part of the recommender and show that the work that you did actually mattered to someone. It also also fairly easy to weed out the true recommendations from the "cookie-cutter" recommendations.
A low profile on Facebook, or failing that a "clean" public profile. Twitter is fine, with the same caveat that the profile is clean. Technologists who don't know how to manage their public interactions make me wonder how they manage their professional interactions.
I use this information to prepare for the technical interview, and make notes to call you out on your experience and listed skills. If you walk the walk it will show through in your online presence, face-to-face and pairing interview.
Not having these things is not necessarily a bad thing, especially if you're fresh out of college, but having them lets you tell your story. Not to mention that if you have any length of experience I'd be suspicious if you didn't engage in at least some of these activities.
Non-critical doesn't mean trivial or unimportant. Simply because he doesn't see the changes at the same level of criticality (is that a word?) doesn't mean that they're not important to someone. The message he sent out on the mailing list goes on to say:
Anyway, the rc5 changes are pretty much all over: pretty much exactly
half are drivers (networking, usb, gpu, mmc, sound..), with the other
half being various other subsystems. Some arch updates: MIPS, arm,
smattering of ia64, microblaze, s390 and some x86. And networking
(non-driver), xfs, fuse, gfs2, jfs..
I don't know about you, but none of those things sound unimportant to me. How long have people been bitching about driver and network support in the kernel? And he's complaining that that stuff is getting fixed? Please. The fact of the matter is that he's annoyed because he refuses the let got of the reins and let someone else help out. If he is the gatekeeper than this is what he should expect.
So, the great thing about an Open Source project is that developers have the ability to say "Hey, I think we can do this better." and then go off and actually fix it. They are not beholden to a corporate IT overlord that says "Thou shalt not commit code that is directly related with the task in front of you!" Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.
As far as Torvalds getting pissed off (as a feint or not) and talking smack about how when a developer's mother sat round the house she sat around the house he's brought this on himself as the gatekeeper for the project. This is simply the nature of an Open Source project. Furthermore there is nothing that says he can't simply reject a pull request and declare the RC closed for anything but direct bug fixes (which is what he is actually doing I suppose).
FWIW I don't disagree with you exactly, I just think it is important to keep in mind what kind of project and what kind of developers we're talking about.
Seriously though, who the hell cares if the RC is bigger than the one before it, or whether the changes are scattered everywhere? If there were any number of concerns that needed to be addressed before the next release then it wasn't ready to go in the first place. Just test the hell out of everything, make sure nothing is broken, and make sure that each change was necessary and correct. In short calm your tits and keep coding.
Yes, Ken Schwaber basically said this at Path to Agility on Thursday. I think his exact words were "it was just a word that we thought was clever, but it probably has more of an impact than if we had used 'rigid', or some other word."
At the end of the day the Manifesto really says they support collaboration and getting things done over planning and following a process. It doesn't say a thing about any of the practices that have been implemented in Agile's name.
There's also a lot of gaps in Agile and IMO while Stories are great they are not a substitute for fully defined requirements analysis.
I hate to break it to you but "fully defined requirements analysis" is a pipe dream filled with rainbows and unicorns. I have never, not once, seen a requirements document that accurately captures exactly what the system will do. Even if it did it would be true for all of 5 minutes before the product owner/user changed their mind and redefined what they want. The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want. I know what you're going to say next: "If they keep changing their minds then how does it ever get done?" Simple, you make it extremely clear that continuously changing their mind directly equates to more time and money spent and prevent other functionality from being implemented.
The key stakeholders either don't pay attention or louder voices who have really no relative bearing to the project somehow get suddenly important. These are often folks with something to gain by holding things up or creating confusion. That is always the problem in all projects but it seems more acute in Agile because "hey, we have a process that can allow for these changes."
You're right, this is true on all projects. Stakeholder involvement has to be managed just like any other aspect of a project. As for "we have a process..."; if you think Agile is about processes then you really don't get it. Agile isn't about processes, it really is about adapting to change and doing what works. If what works is having a daily stand-up and holding team members accountable for for their work then so be it. If it means not pair-programming, then do that too. There are no hard and fast rules.
You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.
Don't bitch about the quality of the code (manager or academic) in the real world because there are almost no programmers in the corporate world that sit around thinking in O notation and figuring out the best and worst case scenario for every line of code. They bang out 500 lines in a few hours and then hit compile and hope to god it works on the first go.
That's reality people -- you don't have the time, the resources, and if you took the academic attitude to work with you, you'd be cut up and used as shark food by everyone else for being so damn slow and pragmatic when they need things working tonight so they can go home after being there for 15 effing hours to make the latest milestone.
You're working with the wrong programmers then. See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone. By the way if you're working 15 hour days it means you're mismanaging your manager and their expectations (and/or you suck at your job).
Water is wet, the sky is (perceived as) blue, the world *did not* end, etc.
On a more serious note I wouldn't describe any of the code examples I encountered in school as perfect or "well-thought-out" specimens." Nearly every one of them was a trivial case which ignored most error cases and expected the client human/system/software to be well-behaved. I've often thought that Comp. Sci. students (3rd or 4th year) should be forced to pick up someone else's code and refactor it into something workable. I'm not talking about the disgustingly huge and unmaintainable messes that we work with out in the real world, but something big enough to give them an inkling of the kind of scope they'll be expected to deal with.
I also think that if you're not learning TDD in school these days you're not getting your money's worth, and you'd actually be jeopardizing your career by not learning this early, as it is a life-saver out in the real world.
I was in and out in about 20 minutes, so my experience was fairly quick. There was a Somali lady in front of me who might have had a more interesting time of it however. I made some small talk with her, and she told me it was her first time voting, as she had just married her husband, an American. I asked her if this was the "F - K" line and she nervously told me that yes it was, but kept repeating "This is the line, be careful, be careful!" as though they wouldn't let me vote if I accidentally got in the wrong line. She was both proud and afraid of the whole process. The interesting bit of this is that when her time came there was some activity, and I made out that she couldn't read the ballot, and wanted to know if her husband (who was also in line) could read it for her. I didn't hear the rest though, as it was quickly my turn at the polling station.
I haven't had a chance to look up the pertinent law regarding whether someone else is allowed to read the ballot or not, but I would imagine this same scenario has played out many times over (This isn't an argument for or against ballots in multiple languages, just an account of a polling incident).
Congratulations! You're in the process of joining the human race by displaying a sense of self-awareness and an awareness of other's feelings! You've already solved half the problem simply by noticing that you're acting like an arrogant jerk. Next step: When you notice you're about to say or do something arrogant or jerk-like just invoke Wheaton's Law.
Where does it come from: As for where it comes from it is pretty easy to see. Most hardcore nerds spent their youth getting picked and teased for being hardcore nerds. Get them into a field in which most people still regard as Voodoo/High Wizardry (Come on, you have to admit that even though people in general are more familiar with tech now most of them are fairly ignorant of how anything tech-related actually works. This is not a dig against anyone, it is simply a statement that most individuals don't know or care how a given piece of tech works, just that it does.) and it is easy to see how a level of arrogance might develop.
Rectifying it (Issue status - Won't Fix): Luckily this is a self-rectifying problem. Once said arrogant jerks get out into the real world most of them will go through the post-grad school of hard knocks. No one wants to work with an arrogant jerk. A lot of them will either self-correct their behavior and try to play nice with their co-workers, family, friends, etc. The rest won't have enough self-awareness to see what is causing the problem in the first place and will quickly either be out of a job, spouse, friends, etc. Problem solved either way. I've seen both scenarios play out.
Are you working in an environment in which you're the only developer working on your particular piece of code and everyone else has their own little fiefdom as well, or are you working in a more collaborative environment, such as an Agile/Scrum/whatever environment that practices paired-programming, collective code ownership, and TDD? I've worked in both (I'm currently in an Agile environment and never plan to go back to the "old" way of doing things in case you're wondering where my bias lays.), and I gotta say the need for code reviews seems a lot stronger in your typical Waterfall shop than it it in the Agile shop.
In the waterfall scenario my experience was everyone worked on their own module and there wasn't much in the way of oversight or another pair of eyes until a formal code review was held. You could get away with writing some really bad code and unless a code review was held on a regular enough basis (and they weren't) it would ship as long as it worked.
In the paired-programming scenario you always have a second pair of eyes to check the code being written, and if your pairing partner is effective they'll stop you when they see a better way of solving the current problem and vice versa. Paired-programming is essentially a continuous code review if it is done properly. Couple this with switching partners often enough and you get a team that thoroughly knows the codebase and can generally make more informed design decisions. Add in TDD and you'll (hopefully) have enough code coverage and quality tests to keep your code clean and maintainable.
Now, I'm not trying to say practicing Agile completely eliminates the need for code reviews, but it lessens that need greatly. It is still entirely possible for a lot of terrible code to get written in an Agile environment, especially if two clueless developers are pairing, but if you're working with clueless developers you'll have that problem no matter if you're on a Waterfall or Agile project.
Forgot all that prose from Kotaku. Doom 2 with the Army of Darkness mod said it much more succinctly. I spent my days making demons howl and die amid shouts of "Come get some!" and "This is my BOOMSTICK!" Man I miss games like that.
If the school has any number of gullible/inexperienced Comp. Sci. tutors then it may be very easy. I tutored Comp. Sci. for a while and there was no lack of students who thought they could get me to do their homework for them. It always started off with "I have this assignment and I'm confused about this part of it.... can you help me?" Of course most of them understood when I only gave generalized answers that didn't have anything to do with the assignment, but there were always a few that thought I was simply being unhelpful. I know some Comp. Sci. tutors though that simply went along with the students and practically did their assignments for them, but it didn't really bother me because I knew the cheaters would either get caught in school or (worse) it would come out in their work if they ever got hired somewhere.
I find it hard to believe that oil would have any worth to aliens, as a fuel source or otherwise. Aside from plastics and lubricants oil really only has value to us as a fuel source, and if they have the ability to reach Earth via interstellar travel it is highly unlikely that that would consider it valuable as fuel.
We gotta consider the possibility, that any extraterrestrials close enough to hear our signals in any reasonable amount of time, and with the sophistication to pinpoint us....
Might have the technology and desire to invade earth.
E.g. Consider earth itself... fast forward a few dozen generations...... massive overpopulation, lack of resources, land, severe overcrowding.
Extreme desire for another habitable place to live.
You're making the awfully large assumption that Earth would be considered habitable for another species. It is just as likely that an nitrogen and oxygen rich atmosphere would be poisonous or even acidic to them (more likely?) than breathable. We also need to consider possible differences in mass and gravity, not to mention that any extraterrestrial that sets foot on Earth would have to contend with a diverse and aggressive ecosystem (I'm thinking bacteria and viruses that have lived here for millions of years).
As far as the Earth having massive resources, what could we possibly have that couldn't be obtained more easily from one of the (thousands/millions) of other mostly uninhabited other planets in the galaxy? Further, why go to the possibly enormous effort of coming to a world which is already inhabited in the first place (assuming the reason is not for the sake of anthropology or scientific curiosity), especially considering that if they are that advanced they could find other suitable worlds whose indigenous species is less hostile (and lets face it, we ARE a rather hostile species, even if we aren't that technologically advanced).
No, I find it far more likely that if another species did contact us it would not out of aggression or need for resources, but for scientific purposes... or worse, a need to spread their particular religious beliefs to all non-believers.
Then again, the universe is pretty big place, and there could be any number of space-faring species that might be tempted by Earth. Who knows.
There's another reality: it's really, really hard to manage projects remotely. I have tried this for a number of projects, and have learned the following things:
A day before the deadline, John will ask for more time
Halfway through the project, John will ask for more money
John will not give the source, as was agreed
John will not use unit tests, or Subversion, as was agreed
John cannot be bothered to provide an estimate or a planning
John will take on other projects and give priority to those before yours
John actually has a day job and just does projects on the side
John will tell you he takes a holiday for three weeks, starting tomorrow
John has a wedding of a brother, a pregnant sister, a sick father, etc and cannot make the planning
John will ask for more money at the end of the project
John cannot be reached because he lost his mobile
John cannot be reached because his mobile was stolen
John cannot be reached because his mobile its battery is empty
John cannot be reached because the e-mail server is down
John cannot be reached because the internet is down
Not that I disagree entirely that it may be more difficult to manage someone in India, and I've certainly heard horror stories, but come on. These could all be applied to just about any remote contractor who isn't worth their salt. I have worked with/currently work with plenty of Indians who really knew/know their stuff.
Slashdot Mirror
I feel this way about the current codebase I'm working on right now, but they only give me the nerf-type of weapons, so no one needs to worry.
Ruby and Cucumber (at least for your test code)?
Who's going to really whip the Llama's ass now?
Exactly how many IT workers do you know who will need Social Security when in all likelihood they've been in IT their whole lives making IT money? I don't know about you but by the time I turn 65 I plan to have some kind of nest egg built up. If you're in IT you're not exactly hurting for money (or you're doing it wrong).
It's possible I've used the wrong word here, but when I talk about being passionate about your job I'm not talking about being "emotional" about your job.
What I'm talking about is going above and beyond the minimum required effort. The absolute minimum required effort is usually that the software works, it satisfies the client's requirements, it comes in under or at budget (this is obviously more at the project level and then individual developer level), and that it can be maintained. Above and beyond is about craftsmanship. It is about TDD, refactoring until you have made your best effort to get the code clean, and pushing back on ridiculous requirement to get to the true business need. It's about taking the time to learn new technologies off the clock, it's about giving back to the community that has given you so much (Do you, for even one moment, imagine that you got where you are because you learned and worked in a vaccum?). Whether this giving back mean you contribute to open source project, you maintain a blog, attend or present at user group meetings, etc is up to you, but if you're going to work with me I want to see that you're active and you give a shit.
As a family man myself I completely understand your sentiment. There is certainly a balance to be held. I spend time with my family and love my children, but I also know that nobody, noboby owes me a free ride and it is up to me to excel and continue to learn and grow as a developer outside of the 9-5. Clients almost never pay me to learn on their dime, and when I talk about being passionate I'm talking about understanding that you need to give enough of a shit to grow on your own and give back. I want to work with developers who are on that wave length and do more than clock in, write their 500 LOC/day, clock out and promptly forget about programming until 9AM the next day.
No problem, it is always nice to have a good conversation, not to mention being pleasantly surprised by a thoughtful and polite AC :-). Good luck in your career!
Not with an attitude like that we're not.
If you're in it purely for the money you're in it for purely the wrong reason. Passion is is not stupid, or a sign of weakness. Passion is caring about the work that you do, and therefore about the work that others do because ultimately their work is what matters. IT is not an end unto itself, it is a means to accomplish other things. Being passionate shows you care about the quality of your work and the quality of others' work. If you come to the table and you can't show passion about your work and your overriding value is money then hit the road. There are thousands of others just like you who would love the chance to show they can do the job, and they may or may not charge your rate.
This is why I look for recommendations and blog posts. I'm in the same boat that you're in, which is that my best code is proprietary. The solutions is to have others recommend your work and by writing about the things you learn. By this I don't mean that you post specifics about your code as it is the implementation of the concept or technique you have learned (not to mention posting chunks of proprietary code will get you fired or sued). It isn't the specific code that matters, it is showing that you have the skills, knowledge, ability to learn and care enough to share these things for the benefit of others.
So first of all you're looking at this the wrong way. You're not "showing off" per se. You're selling your services in most honest manner you can. You have to get over the idea that you shouldn't talk about yourself. You're in business, and in business no one will sell for you. You have to be your own champion, and that means being willing to put yourself out there, talk about what you've learned and show people why they should hire you.
To answer you question "getting the job done" is obviously the important thing. The trick is showing people who have no idea who you are or what you've done that you can, in fact, get the job done. When they are interviewing you they are trying to determine if it is a "safe bet" to hire you on, and make no mistake it is a bet. Chances are neither they nor you will know if it is a good fit until after the fact, but you can help them make that decision and put them somewhat at ease by talking about yourself and sharing your experience ahead of the conversation.
My job as the technical interviewer is to determine if the things you say you know and have done matches up to reality. You'll make my job easier if you can show me that concretely, and therefore make it more likely that I'll recommend you to continue in the hiring process.
I pay scant attention to resumes, except as a starting point and a way to see if you can string words together in a syntactically correct manner. Not having an online presence won't hurt you necessarily. After the receiving a resume the first thing I'll do is to google you to see if you have:
I use this information to prepare for the technical interview, and make notes to call you out on your experience and listed skills. If you walk the walk it will show through in your online presence, face-to-face and pairing interview.
Not having these things is not necessarily a bad thing, especially if you're fresh out of college, but having them lets you tell your story. Not to mention that if you have any length of experience I'd be suspicious if you didn't engage in at least some of these activities.
Non-critical doesn't mean trivial or unimportant. Simply because he doesn't see the changes at the same level of criticality (is that a word?) doesn't mean that they're not important to someone. The message he sent out on the mailing list goes on to say:
I don't know about you, but none of those things sound unimportant to me. How long have people been bitching about driver and network support in the kernel? And he's complaining that that stuff is getting fixed? Please. The fact of the matter is that he's annoyed because he refuses the let got of the reins and let someone else help out. If he is the gatekeeper than this is what he should expect.
So, the great thing about an Open Source project is that developers have the ability to say "Hey, I think we can do this better." and then go off and actually fix it. They are not beholden to a corporate IT overlord that says "Thou shalt not commit code that is directly related with the task in front of you!" Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.
As far as Torvalds getting pissed off (as a feint or not) and talking smack about how when a developer's mother sat round the house she sat around the house he's brought this on himself as the gatekeeper for the project. This is simply the nature of an Open Source project. Furthermore there is nothing that says he can't simply reject a pull request and declare the RC closed for anything but direct bug fixes (which is what he is actually doing I suppose).
FWIW I don't disagree with you exactly, I just think it is important to keep in mind what kind of project and what kind of developers we're talking about.
Everyone has to have a hobby, right?
Seriously though, who the hell cares if the RC is bigger than the one before it, or whether the changes are scattered everywhere? If there were any number of concerns that needed to be addressed before the next release then it wasn't ready to go in the first place. Just test the hell out of everything, make sure nothing is broken, and make sure that each change was necessary and correct. In short calm your tits and keep coding.
Yes, Ken Schwaber basically said this at Path to Agility on Thursday. I think his exact words were "it was just a word that we thought was clever, but it probably has more of an impact than if we had used 'rigid', or some other word."
At the end of the day the Manifesto really says they support collaboration and getting things done over planning and following a process. It doesn't say a thing about any of the practices that have been implemented in Agile's name.
I hate to break it to you but "fully defined requirements analysis" is a pipe dream filled with rainbows and unicorns. I have never, not once, seen a requirements document that accurately captures exactly what the system will do. Even if it did it would be true for all of 5 minutes before the product owner/user changed their mind and redefined what they want. The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want. I know what you're going to say next: "If they keep changing their minds then how does it ever get done?" Simple, you make it extremely clear that continuously changing their mind directly equates to more time and money spent and prevent other functionality from being implemented.
You're right, this is true on all projects. Stakeholder involvement has to be managed just like any other aspect of a project. As for "we have a process..."; if you think Agile is about processes then you really don't get it. Agile isn't about processes, it really is about adapting to change and doing what works. If what works is having a daily stand-up and holding team members accountable for for their work then so be it. If it means not pair-programming, then do that too. There are no hard and fast rules.
You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.
Don't bitch about the quality of the code (manager or academic) in the real world because there are almost no programmers in the corporate world that sit around thinking in O notation and figuring out the best and worst case scenario for every line of code. They bang out 500 lines in a few hours and then hit compile and hope to god it works on the first go.
That's reality people -- you don't have the time, the resources, and if you took the academic attitude to work with you, you'd be cut up and used as shark food by everyone else for being so damn slow and pragmatic when they need things working tonight so they can go home after being there for 15 effing hours to make the latest milestone.
You're working with the wrong programmers then. See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone. By the way if you're working 15 hour days it means you're mismanaging your manager and their expectations (and/or you suck at your job).
Water is wet, the sky is (perceived as) blue, the world *did not* end, etc.
On a more serious note I wouldn't describe any of the code examples I encountered in school as perfect or "well-thought-out" specimens." Nearly every one of them was a trivial case which ignored most error cases and expected the client human/system/software to be well-behaved. I've often thought that Comp. Sci. students (3rd or 4th year) should be forced to pick up someone else's code and refactor it into something workable. I'm not talking about the disgustingly huge and unmaintainable messes that we work with out in the real world, but something big enough to give them an inkling of the kind of scope they'll be expected to deal with.
I also think that if you're not learning TDD in school these days you're not getting your money's worth, and you'd actually be jeopardizing your career by not learning this early, as it is a life-saver out in the real world.
I was in and out in about 20 minutes, so my experience was fairly quick. There was a Somali lady in front of me who might have had a more interesting time of it however. I made some small talk with her, and she told me it was her first time voting, as she had just married her husband, an American. I asked her if this was the "F - K" line and she nervously told me that yes it was, but kept repeating "This is the line, be careful, be careful!" as though they wouldn't let me vote if I accidentally got in the wrong line. She was both proud and afraid of the whole process. The interesting bit of this is that when her time came there was some activity, and I made out that she couldn't read the ballot, and wanted to know if her husband (who was also in line) could read it for her. I didn't hear the rest though, as it was quickly my turn at the polling station.
I haven't had a chance to look up the pertinent law regarding whether someone else is allowed to read the ballot or not, but I would imagine this same scenario has played out many times over (This isn't an argument for or against ballots in multiple languages, just an account of a polling incident).
Congratulations! You're in the process of joining the human race by displaying a sense of self-awareness and an awareness of other's feelings! You've already solved half the problem simply by noticing that you're acting like an arrogant jerk. Next step: When you notice you're about to say or do something arrogant or jerk-like just invoke Wheaton's Law.
Where does it come from: As for where it comes from it is pretty easy to see. Most hardcore nerds spent their youth getting picked and teased for being hardcore nerds. Get them into a field in which most people still regard as Voodoo/High Wizardry (Come on, you have to admit that even though people in general are more familiar with tech now most of them are fairly ignorant of how anything tech-related actually works. This is not a dig against anyone, it is simply a statement that most individuals don't know or care how a given piece of tech works, just that it does.) and it is easy to see how a level of arrogance might develop.
Rectifying it (Issue status - Won't Fix): Luckily this is a self-rectifying problem. Once said arrogant jerks get out into the real world most of them will go through the post-grad school of hard knocks. No one wants to work with an arrogant jerk. A lot of them will either self-correct their behavior and try to play nice with their co-workers, family, friends, etc. The rest won't have enough self-awareness to see what is causing the problem in the first place and will quickly either be out of a job, spouse, friends, etc. Problem solved either way. I've seen both scenarios play out.
Are you working in an environment in which you're the only developer working on your particular piece of code and everyone else has their own little fiefdom as well, or are you working in a more collaborative environment, such as an Agile/Scrum/whatever environment that practices paired-programming, collective code ownership, and TDD? I've worked in both (I'm currently in an Agile environment and never plan to go back to the "old" way of doing things in case you're wondering where my bias lays.), and I gotta say the need for code reviews seems a lot stronger in your typical Waterfall shop than it it in the Agile shop.
In the waterfall scenario my experience was everyone worked on their own module and there wasn't much in the way of oversight or another pair of eyes until a formal code review was held. You could get away with writing some really bad code and unless a code review was held on a regular enough basis (and they weren't) it would ship as long as it worked.
In the paired-programming scenario you always have a second pair of eyes to check the code being written, and if your pairing partner is effective they'll stop you when they see a better way of solving the current problem and vice versa. Paired-programming is essentially a continuous code review if it is done properly. Couple this with switching partners often enough and you get a team that thoroughly knows the codebase and can generally make more informed design decisions. Add in TDD and you'll (hopefully) have enough code coverage and quality tests to keep your code clean and maintainable.
Now, I'm not trying to say practicing Agile completely eliminates the need for code reviews, but it lessens that need greatly. It is still entirely possible for a lot of terrible code to get written in an Agile environment, especially if two clueless developers are pairing, but if you're working with clueless developers you'll have that problem no matter if you're on a Waterfall or Agile project.
Forgot all that prose from Kotaku. Doom 2 with the Army of Darkness mod said it much more succinctly. I spent my days making demons howl and die amid shouts of "Come get some!" and "This is my BOOMSTICK!" Man I miss games like that.
If the school has any number of gullible/inexperienced Comp. Sci. tutors then it may be very easy. I tutored Comp. Sci. for a while and there was no lack of students who thought they could get me to do their homework for them. It always started off with "I have this assignment and I'm confused about this part of it.... can you help me?" Of course most of them understood when I only gave generalized answers that didn't have anything to do with the assignment, but there were always a few that thought I was simply being unhelpful. I know some Comp. Sci. tutors though that simply went along with the students and practically did their assignments for them, but it didn't really bother me because I knew the cheaters would either get caught in school or (worse) it would come out in their work if they ever got hired somewhere.
I find it hard to believe that oil would have any worth to aliens, as a fuel source or otherwise. Aside from plastics and lubricants oil really only has value to us as a fuel source, and if they have the ability to reach Earth via interstellar travel it is highly unlikely that that would consider it valuable as fuel.
You're making the awfully large assumption that Earth would be considered habitable for another species. It is just as likely that an nitrogen and oxygen rich atmosphere would be poisonous or even acidic to them (more likely?) than breathable. We also need to consider possible differences in mass and gravity, not to mention that any extraterrestrial that sets foot on Earth would have to contend with a diverse and aggressive ecosystem (I'm thinking bacteria and viruses that have lived here for millions of years).
As far as the Earth having massive resources, what could we possibly have that couldn't be obtained more easily from one of the (thousands/millions) of other mostly uninhabited other planets in the galaxy? Further, why go to the possibly enormous effort of coming to a world which is already inhabited in the first place (assuming the reason is not for the sake of anthropology or scientific curiosity), especially considering that if they are that advanced they could find other suitable worlds whose indigenous species is less hostile (and lets face it, we ARE a rather hostile species, even if we aren't that technologically advanced).
No, I find it far more likely that if another species did contact us it would not out of aggression or need for resources, but for scientific purposes... or worse, a need to spread their particular religious beliefs to all non-believers.
Then again, the universe is pretty big place, and there could be any number of space-faring species that might be tempted by Earth. Who knows.
There's another reality: it's really, really hard to manage projects remotely. I have tried this for a number of projects, and have learned the following things:
Not that I disagree entirely that it may be more difficult to manage someone in India, and I've certainly heard horror stories, but come on. These could all be applied to just about any remote contractor who isn't worth their salt. I have worked with/currently work with plenty of Indians who really knew/know their stuff.