Developer Stigma After a Bad Or Catastrophic Release?

An anonymous reader writes "We hear in the news all the time about how executives can drive a company into the ground and yet somehow become more desirable to other big companies. What we don't hear about are the grunts who implemented those decisions, and whether or not they end up resume-stained or blacklisted. Since we've got so many developers with lots of time in the trenches, I thought I would appeal to their experience. When disaster looms and sales starts pushing for development that has little chance but to end in disaster, what happens to the programmer who decides he needs his job enough to follow orders? Have they ever become unhireable?"

Comments

In my experience, no.

[whatthef*ck]

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer. I've told that to interviewers a number of times. If they don't get it, then I don't want to work for them.

Re:In my experience, no.

[Brian Gordon]

then I don't want to work for them

Must be nice to be 5 years ago.

Re:In my experience, no.

[Kjella]

Sseriously, even in the worst of times there are businesses that are growing. Those that do are well aware of the situation and know that in this market they can hire high quality workers at reasonable prices, even the kind of employees no sane employer would normally lay off that they'd normally have to headhunt with huge paychecks. So yeah, many people are in the "nod, smile and say yes if offered a job" mode you shouldn't assume it's that way for everyone.

Re:In my experience, no.

[DerekLyons]

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer.

Yep, and the same thing applies to the executives the questioner slams.

Re:In my experience, no.

[The End Of Days]

Class warfare is pretty much the only way the Slashdot team can bring any class to this site.

Re:In my experience, no.

[Bogtha]

Not really. If a project is a catastrophe, then that's usually attributable to executive decisions. If the output of the developers caused the catastrophe, then it's usually because the project was mismanaged - not assigning any resources to QA, ignoring risks, handling change requests badly, allowing feature creep, setting unrealistic deadlines, and so on. It's rare that developers are actually to blame for a project going pear-shaped, and when they are, management are often complicit because they knowingly hired cheap developers without experience. The developers are there to write code, it's the managers' jobs to ensure that the project succeeds.

Re:In my experience, no.

[dublindan]

Agreed. The company I'm working for is doing better than ever. In bad economic times, any company that sells products which will save the customer money in the long run is going to do well. People will spend a lot of money if it will help them save more in the long run.

Re:In my experience, no.

[Savage-Rabbit]

It's rare that developers are actually to blame for a project going pear-shaped, and when they are, management are often complicit because they knowingly hired cheap developers without experience. The developers are there to write code, it's the managers' jobs to ensure that the project succeeds.

You assume that most developers write good code, which isn't nearly always the case. I have seen projects run into major problems necessitating extensive rewrites because of fundamental mistakes in low level programming and design decisions that were taken by developers, not a bunch of weaselly managers and marketing creeps. You can completely screw up a project by taking the ad-hoc approach to designing an API or a protocol in a way that can be very expensive to fix. I agree that management (or marketing for that matter) usually makes it's contributions to such disasters as well but you can't just absolve the coders, especially the senior techies that do the design work. In the end coders must also live up to a minimal level of competence.

Re:In my experience, no.

[Hurricane78]

I very much doubt that. Because other than for us, they do not get punished for it. They usually get large compensations, and leave with a nice reference, shortly before everything crashes. Usually, all the blame then goes to the "end game" manager, who "ran this successful business down so quickly". That "end game" manager usually is a promoted straw-man from a lower level.

So they learn the opposite of what we developers learn. They learn that you can make good money with it, and apply for an even bigger job in the next company. :)
I've seen it myself many times. I always hoped that I just had bad luck with my jobs. But I was not the only one with stories like this. And after all, Dilbert wasn't such a big success in our circles for nothing. ;)

Re:In my experience, no.

[JAlexoi]

5 years ago you could be payed for doing nothing. Now the people that are actually valuable get payed well, in spite of the bad economic situation. Value is value, in any economic situation.

Re:In my experience, no.

[John Hasler]

> I have seen projects run into major problems necessitating extensive rewrites because of
> fundamental mistakes in low level programming and design decisions that were taken by
> developers, not a bunch of weaselly managers and marketing creeps.

An executive who doesn't notice until too late that his developers are screwing up is screwing up.

Re:In my experience, no.

[fooslacker]

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer. I've told that to interviewers a number of times. If they don't get it, then I don't want to work for them.

Developers blame the project management and architects, architects blame the project management and developers, project management blames the architects and developers and everyone blames politics. All the posts about how much you learned or how valuable the experience was is nice but the truth of the matter is that very few individuals have the introspection skills necessary or the broad view to see what true convergence of horrific behaviors and decisions led to the smoking crater that is the massive software project failure.

The good thing is that with all this confusing and complexity it's extremely rare that anyone ever gets blamed for even their part in the failure much less the whole thing and while some folks might be blacklisted in a small enough company it's almost unheard of for anyone leadership through grunts to be blacklisted in an entire industry or even a big company.

The bad news is that we rarely learn from our mistakes and large software projects continue to fail or succeed when the right random mix of situations and behaviors occur. My first advice would be try to steer clear of massive big bang delivery waterfall type projects, they're ripe for breeding a convergence of bad things that lead to failure and while you won't be blacklisted but you'll still experience the suffering and frustration of a failing project.

More practical advice for those of you who can't or don't want to avoid these situations is when one of these monstrosities fails be realistic. You're working in a high risk environment for this type of failure. A huge project with a team with more than 20 or worse 100 (or even worse 1000) people is courting failure. When you experience failure certainly look at what other people did wrong but more importantly ask yourself, "given this high risk of failure environment what did I do that contributed to it". We tend to see what other did to contribute and place an inordinate amount of blame on their behaviors and mistakes when in truth it is the convergence of a massive number of little mistakes that most often causes failure. Any one of the problems alone wouldn't doom the project but the whole of their destructiveness is greater than the sum of the parts in this case. If you can at least not contribute to that swirl of chaos you'll have done the best you can to help avert disaster. Beyond that just prepare to be disappointed because these types of projects are hard and risky and they fail far too often.

Re:In my experience, no.

[Bogtha]

You assume that most developers write good code

No, I don't.

I have seen projects run into major problems necessitating extensive rewrites because of fundamental mistakes in low level programming and design decisions that were taken by developers, not a bunch of weaselly managers and marketing creeps.

But the question is how did the project manage to get into such a state without anybody stopping this? Is there no oversight? That's a managerial problem. Is there nobody competent to speak up? That's a managerial problem. Are the competent people not listened to? That's a managerial problem. Are the competent people so overworked that they aren't aware of what the rest of the team is doing? That's a managerial problem.

When developers screw up, the fault lies with the developers. When developers are allowed to screw up over the entire course of a project, irrevocably damaging the project, the fault lies with the managers.

In the end coders must also live up to a minimal level of competence.

Agreed, but my point is that if an organisation has no such competence in its development team, this is not a problem any developer can take responsibility for; it's a problem with how the organisation is run.

Re:In my experience, no.

[ultranova]

In bad economic times, any company that sells products which will save the customer money in the long run is going to do well. People will spend a lot of money if it will help them save more in the long run.

Only if they have money to spend. If they don't and are struggling to survive they have little choice but to go with the cheapest option, even if it'll end up costing more in the long run. That's one of the reasons why our society is becoming increasingly stratified, and the basic problem with capitalism: you have to have capital in order to make capital, leading to an exponential growth in wealth differences, and all the social and economical problems that brings.

Re:In my experience, no.

[inotocracy]

Some of that can be attributed to unrealistic deadlines, pushing the programmers to hard and/or not providing a large enough window to properly spec a project. ..grumble..

Re:In my experience, no.

[Anonymous Coward]

Only if they have money to spend. If they don't and are struggling to survive they have little choice but to go with the cheapest option, even if it'll end up costing more in the long run.

I must punch one hole in your argument: taxes. People still have to pay them. If someone feels they can 1) owe less or get a bigger refund or 2) they are less likely to be audited, they'll spring the $20-$60 for one of these applications.

From what I saw, the tax software companies did just fine this last season.

Re:In my experience, no.

[cerberusss]

I very much doubt that. Because other than for us, they do not get punished for it. They usually get large compensations

They, they, they. It all sounds very black-and-white.

I've seen a project go wrong. The project manager clamored for support but not in the right way. She also did not get it due to an inexperienced division manager. Whatever the reasons, the combination turned out bad. She saw the problems coming, felt she didn't get support and asked to be moved elsewhere. Someone else took over.

Some time later, she told me a potential career movement had been obstructed because someone in the management team remembered her from that bad project. I have not heard about the division manager his career, or the replacement project manager.

My point is that I find your view "zOMG they PROFITS!!" pretty unrealistic. There are lots of sides to stories on failed projects.

Re:In my experience, no.

[Anonymous Coward]

You assume that most developers write good code, which isn't nearly always the case. I have seen projects run into major problems necessitating extensive rewrites because of fundamental mistakes in low level programming and design decisions that were taken by developers, not a bunch of weaselly managers and marketing creeps. You can completely screw up a project by taking the ad-hoc approach to designing an API or a protocol in a way that can be very expensive to fix. I agree that management (or marketing for that matter) usually makes it's contributions to such disasters as well but you can't just absolve the coders, especially the senior techies that do the design work. In the end coders must also live up to a minimal level of competence.

OK, you're talking about the people who call themselves architects and so on. Yeah, I've seen them screw things up royally, and not get caught. It's easy for a mere programmer to suspect, but not easy to *prove*, that the project would have succeeded/been less over budget/etc if this-or-that technical decision had been taken differently.

One of my favorite architecture fsckups is second-hand: an embedded system where all arithmetic was to be done via COM interfaces: you had to call the object which did floating-point addition, the one which did floating-point multiplication ...

Re:In my experience, no.

[Anonymous Coward]

Talented people still can pick and choose who they work for. Sorry your choices are more limited. Try expanding your skill set and you as well will have choice in who you work for.

Re:In my experience, no.

[BitZtream]

In tough economic times the only companies that suffer are the ones that weren't doing well or weren't needed to begin with.

Show me one well managed company that provides an essential service thats anywhere close to failure.

The only companies suffering are the ones that were riding on the over inflated economy. I say this full well knowing that the company I work for, on the verge of going out of business falls squarely into both categories.

Re:In my experience, no.

[Hognoxious]

leading to an exponential growth in wealth differences

What's the variable on the x axis? Couldn't you just use "big"?

Re:In my experience, no.

[Hognoxious]

Exactly. Even if the developers were the second most retarded bunch of 'tards to ever lick the windows of a short bus, an even more retarded bunch started the problem by hiring them.

Re:In my experience, no.

[ScrewMaster]

I agree that management (or marketing for that matter) usually makes it's contributions to such disasters as well but you can't just absolve the coders, especially the senior techies that do the design work.

Yes, you can.

Sure, it's the senior design staff that is responsible for making poor design decisions ... but it's management that made the decision to hire those particular individuals in the first place! It's management that didn't put into place the proper processes to assure success. Truth is, a well-thought-out design process won't allow major disasters to happen very often, but that costs money and time. Yes, mistakes sometimes slip by, but if you have proper review and testing procedures in place you really can't single out the engineers to take the heat. Everybody makes mistakes, everybody screws up sometime, and you simply have to accept that possibility and account for it in the way you run your projects. Look, any way you slice it, management is responsible because we know how to do it right. Whether it be an accounting program or a space-shuttle flight-control system, we know how to make big projects work. There's no mystery, it's not rocket science. It just takes the right stuff. A manager who fails to hire the right stuff (or a senior executive who fails to give said manager the resources to hire the right stuff) should find themselves on the unemployment line because it's their fault.

Furthermore, there's a reason execs get paid more than engineers: it's because they are the ones who ultimately have responsibility for failure. Granted, they often manage to weasel out of it, or place the blame on someone they hired who wasn't up to the job, but it's still an upper-level failure. A manager who selects the wrong person for the job is just as culpable (really, more so) than the engineer who picks the wrong solution.

I mean, who is more the fool? The fool ... or the fool who hires him?

Re:In my experience, no.

[nbauman]

It's his way of saying that y(n)=a(n)e^bx) has different values of b for different values of n.

Re:In my experience, no.

[Leynos]

Time.

Re:In my experience, no.

[rakslice]

Maybe... In the trenches you can learn from your co-workers, and you can learn from your mistakes. But it's often lonely at the top, "White boy welfare" makes even the latter difficult.

Re:In my experience, no.

[wrook]

I've worked on some flops in my time too. At subsequent interviews I'm pretty candid about what went wrong. For example on one project it became clear that we were building a product that nobody would want to use. Eventually the project was canned because it was simply stupid. I'm invariably asked what I would do differently in those situations.

I respond that when I see a potential problem, I discuss it with my manager. I point out possible solutions and indicate the cost of remedial action. I try to explain what the consequences of ignoring the problem is. Usually they ask if that will solve the problem. I say, probably not. Because I am not running the project. I am only one voice and can only view the project from my perspective. I will honestly give feedback and and discretely point out potential problems. But business is about taking risk. I may not be able to fully understand the risks and potential benefits from my position. So in the end I will discuss problems, but I will accept decisions and do my best to fulfill my role. Sometimes the risk doesn't pan out and we are left with a failure. Even if I correctly predicted the failure, that doesn't mean it wasn't worth trying.

Re:In my experience, no.

[Anonymous Coward]

I'm working for a small company looking to hire good C++ programmer. To be honest even in this climate it's really hard to find good candidates. Good coders are generally thin on the ground.

Re:In my experience, no.

[magarity]

In tough economic times the only companies that suffer are the ones that weren't doing well or weren't needed to begin with ... The only companies suffering are the ones that were riding on the over inflated economy.

You mean the government?

Re:In my experience, no.

[Anonymous Coward]

We have a similar product, and we are doing better... However we still lose deals due to the downturn because:

• companies go under
• executives are too distracted with firefighting
• buyouts are occurring

Re:In my experience, no.

[Crudely_Indecent]

Sseriously, even in the worst of times there are businesses that are growing.

Extra "S" accepted, because it's that sserious. My company has grown by 30% so far this year....it's our best year ever and we're only halfway through it!!!

I discussed bonuses with my boss today and things are looking really good.....that is, unless the government continues to devalue the dollar. Either I'll be able to buy a house, or a loaf of bread.

Re:In my experience, no.

[spiffmastercow]

Where is this? I have a hard time finding a place where they want a programmer for a lower level language than java.

Re:In my experience, no.

[RockDoctor]

When developers screw up, the fault lies with the developers.

... and at the most basic level, catching those screw-ups is the job of the compiler. Catching higher-levle screw-ups is a designer or managerial issue.
I just spent about half an hour of Sunday morning bouncing a poorly defined change proposal back up the chain of command to the ultimate client. Yes, ultimately the change proposed is doable and not-insane, but I'm not going to take responsibility for turning a really incoherently phrased change request into something comprehensible and then passing on the necessary work to my colleagues to carry out. I don't get paid enough, by a factor of between 2 and 3, to take that sort of responsibility. And it's not as if it's so urgent that the client doesn't have 12 hours (of his Sunday) to work out what exactly he wants done, and get out a comprehensibly-worded change request in good time.

Oh dear, I'm becoming a manager. Kill me. Now.

Re:In my experience, no.

[John Betonschaar]

OK, you're talking about the people who call themselves architects and so on. Yeah, I've seen them screw things up royally, and not get caught. It's easy for a mere programmer to suspect, but not easy to *prove*, that the project would have succeeded/been less over budget/etc if this-or-that technical decision had been taken differently.

This sounds very familiar, just having rewritten a 200+ page 'architecture' that ±6 people worked on for a year without completing it, using only 3 (good) engineers, within 3 weeks, resulting in an 'architecture' that consists only of a really thin layer of interfaces implemented in less than 10 classes, and documented in about 5 pages of architecture and of course the generated API documentation. The people who worked on this for a year were pulled from the project but officially because they 'needed to be allocated elsewhere'. I don't think they'll every really be held accountable for the wasted time, effort and money, not even the execs that 'managed' the project.

Re:In my experience, no.

[drinkypoo]

It's actually a three-dimensional graph charting beginning capital, end capital, and time. While there are outliers, I suspect you'd pretty much see a sort of tear drop shape (I was going to say rain drop, but, you know) whose fat end is near the origin, and which tapers sharply (and yes, off into infinity... if you can believe in a technological singularity, why not an economic one? time isn't infinite anyway, even for spherical cows.)

Re:In my experience, no.

[ThePhilips]

Only if they have money to spend.

Hey! I've in the situation like that.

Management quickly realized that crisis is coming (.Com buble) to our niche market. And their decision was questionable (and actually job threatening to me) but in the end saved the company: they pumped production of cheap offering (making it even cheaper), expecting that manageable higher-end expensive systems wouldn't sell at all (for which I was writing control software). And there was period of 13 month when no higher-end systems were sold. Yet, company managed to survive by cutting off only contractors - not a single full-time employee were fired.

Now to the point. When I spoke to management about the crisis and their handling of it, they simply told that industry wouldn't stop working - they would need equipment, but they will not have money to buy something new or expensive.

In the end that strategy played off: there were much less sales and support/maintenance something like doubled (can't buy -> but have to do work -> better maintain existing equipment).

P.S. A sort of hypocrisy in behavior of public companies also showed itself. Most were banned by shareholders from buying anything. Yet, several such clients forked us for maintenance quite a big buck - which would have allowed them otherwise to buy a completely new equipment.

Re:In my experience, no.

[drinkypoo]

My point is that I find your view "zOMG they PROFITS!!" pretty unrealistic. There are lots of sides to stories on failed projects.

I cannot disagree with you more. The project is the responsibility of the company owner(s), but some executive is in charge. What's the difference? Those who bear the responsibility are the ones on the hook in case of failure. The execs don't, they get to ride their golden parachute. The only thing execs get in trouble for is fraud in which they don't cut the proper heads of government their share.

I was just going to say "Look where Carly Fiorina is today" but then I checked her Wikipedia page and it says she has cancer. It's unfortunate that people only get what they deserve by accident. (When you play fast and loose with a public company, you're fucking with a lot of people's livelihoods.)

Re:In my experience, no.

[Anonymous Coward]

An executive who doesn't notice until too late that his developers are screwing up is screwing up.

What kind of retarded statement is that. Do you really expect executives to know every detail about how to do every job of the people underneath them. Unless you're a hardcore software company, I don't expect executives to know shit about computers in general. Banks run on mission critical software but I don't expect bank execs to know the first thing about programming. Even if they have a CTO, he's probably more of an ex-accenture implementation guy which is a far harder job to get right than coding (if it weren't why would there be so many implementation screwups). In addition when things go wrong, they usually go wrong at the end, when its by definition too late.

Just people you'll never make it to the top doesn't mean you have to be pissed at the people already there.

Re:In my experience, no.

[Hurricane78]

They, they, they. It all sounds very black-and-white.

Well, how would you expect me to call "them"? While I now have my own small company, I am not a middle-manager of a big company, and never will be. So of course I have to always use "they". :)
I don't see how this influences the correctness (or the errors?) in my arguments...

My point is that I find your view "zOMG they PROFITS!!" pretty unrealistic.

I'm sorry?? Isn't the very point and single all-ruling purpose of a company, to make "zOMG teh PROFITS!!"? :)
And aren't the people whose job it is to make sure those profits come in called "management"? :)
And aren't they the ones defining what they earn, and what money to leave with?
My view is, that a competent manager of course sees his own job as a company that has to make "zOMG teh PROFITS!!", and therefore it is natural, that "zOMG they PROFITS!!". :))

Re:In my experience, no.

[vcompiler]

A pure technical problem (by "pure technical" I mean a problem purely caused by developers) is usually much less difficult to fix than most people originally thought. And problems caused by culture or management are difficult to fix. A culture encourage transparency and don't blame developer usually encourage developers not covering problems in their code, and encourages a developer benevolently fix problems introduced by others. A culture that blames developer for every single defect in the code, make them cover mistakes, not admit problem by any excuses, not let others tough their own code, and not tough other's code, either.

Re:In my experience, no.

[that IT girl]

I do support for retail stores and can also assert that the liquor stores are also doing quite well these days. (I know this will get a Funny mod, but it's true!)

Re:In my experience, no.

[cerberusss]

Couple of things.

The first one is a bit vague, but by starting almost every sentence with 'they', you're dividing the team, and everytime you're forgetting a little bit that it's actually a team and not two parties that are at odds with eachother. Yes, I'm overarching a bit.

Second thing is this. What you're basically saying is that managers profit from failing projects. I don't buy this generalization. I've seen managers come off of projects damaged in some way. Even if they jump ship, they will be remembered in the organization.

Re:In my experience, no.

[Anonymous Coward]

FYI- you overuse parentheses in your writing.

Re:In my experience, no.

[ahabswhale]

That's just it. Most managers and executives don't know shit about software development so they don't know when shit is going bad. Hire people who know how to run software. This notion that project management is all the same regardless of industry is a bunch of crap.

Re:In my experience, no.

[The End Of Days]

Go figure, all the developers are rushing in to scream that it can never under any circumstances be their fault. Of course not. You are all perfect in every way and never make any mistakes at all, and when you do, it's those who are supervising you at fault. Naturally. That makes perfect sense. In a dream world.

Re:In my experience, no.

[electrofelix]

your government is well managed?

Re:In my experience, no.

[geminidomino]

Sure, it's the senior design staff that is responsible for making poor design decisions ... but it's management that made the decision to hire those particular individuals in the first place!

That's assuming it's not one of those situations where the management is making the poor design decision and overruling the senior tech... Those are ALWAYS fun.

Sr. Tech: We can't do this. There's a 50% chance of destroying 100% of the users' data.
Mgmt: Only 50%? Make it so!
Programmers: *spontaneous bandwidth spike to Monster.com*

Re:In my experience, no.

[hesaigo999ca]

Could not agree with you more...I am in a stable company now, but before went through many of these types of cos. that just did not get it, all in the name of saving a few pennies, instead of getting the proper resources...in the end they lost everything, even with such great potential they had...!

Re:In my experience, no.

[dublindan]

Very good point, I'd mod you up if I could :-D

Re:In my experience, no.

[dublindan]

I actually believe that. I also hear that the gambling industry is doing just as well, or better, than before.

Re:In my experience, no.

[dublindan]

Haha, that would make sense, sure.
Actually, I work in telecommunications and our products help to reduce costs for mobile network operators. A bit of a niche market, sure, but they have the money to spend on products which will ultimately save (or make) them even more.

Re:In my experience, no.

[jinushaun]

Not everyone is feeling the pinch of the recession. (I'm one of them) There are still plenty of jobs out there. Companies will always need skilled employees.

Re:In my experience, no.

[Anonymous Coward]

Not really...

They're the idiots who thought up and forced the implementation of the stupid idea in the first place.

The developers / admins / grunts are the ones who have to pay for the executive's ineptitude.

The executives should be shot on site to prevent the spread of insanity/stupidity.

Re:In my experience, no.

[ivan256]

Buy the house now. Finance the whole thing. Then you can root for the de-valuation.

Don't Worry!

[rlp]

I'm sure Windows 7 developers will still be employable after the October release.

Re:Don't Worry!

[westlake]

I'm sure Windows 7 developers will still be employable after the October release.

In the W3Schools stats the Win 7 RC has half the desktop share of Linux.

Re:Don't Worry!

[mysidia]

Yes, but the project managers who made all the decisions about what Vista would be may not be in for such luck.

Not everyone on a development team is equally to blame for a project's overall failure.

e.g. Development members basically have to rely on other teams and co-workers on their own team to do their jobs correctly.

You may be assigned to do X. But when the overall project is completed, X and Y need to be combined in some manner.

If X's design handed down by the architecture team is horrible, or Y's code is a piece of junk, developers of X can't help that, the best they can do is implement the vision and assignments handed down by the project leadership as correctly and effectively as possible.

I won't blame the team who built the new start menu programming in Vista for the Aero team's poor choice of theme changes.

I won't blame the theme designers for the poor choices of changes to 'control panel', and how, you need 7 clicks now, through non-obvious choices, to assign a static IP to a NIC.

For the most part, no individual developer is responsible for the disaster, except the leadership of the project, and the people who actually had input or opportunity to provide input into the major decisions that made Vista so undesirable.

Re:Don't Worry!

[Kjella]

I'm sure Windows 7 developers will still be employable after the October release.

I don't know, can we have a show of hands for Windows ME developers that are still employed in IT?

Re:Don't Worry!

[Anonymous Coward]

iare of Mellenium guy. Me nmaed it ME after me. i many gude peeple skil

Re:Don't Worry!

[Anonymous Coward]

Does janitorial work near the machine room count?
If so, I think we might have a few still employed in IT.

Re:Don't Worry!

[SanityInAnarchy]

I'd assume they're still working on Vista.

Re:Don't Worry!

[Anonymous Coward]

We sentenced them to doing the maintenance releases and patches for it. Harsh, I know, but the punishment has to fit the crime.

Re:Don't Worry!

[Anonymous Coward]

Well its good to know that in some completely random stats that Linux is ahead of the not yet final release pack!

Re:Don't Worry!

[Anonymous Coward]

That says more about the desktop share of Linux than of the WIn 7 RC...

People change jobs all the time

[flyingfsck]

Bad programmers move on to do other things. A guy may suck at programming and be perfectly fine in IT doing maintenance, or in an over priced big box electronics store selling some new electronic pieces of shit.

Re:People change jobs all the time

[Guysmiley777]

Big box electronics store don't want anyone who has technical knowledge on the sales floor. They want people with used car salesman skills to shovel their rip-off extended warranties to rubes. Being able to spout techobabble bingo may help, but only as a smokescreen. An actual techie might tell customers the truth. That would be entirely unacceptable.

Re:People change jobs all the time

[Quothz]

They want people with used car salesman skills to shovel their rip-off extended warranties to rubes. Being able to spout techobabble bingo may help, but only as a smokescreen. An actual techie might tell customers the truth. That would be entirely unacceptable.

Obligatory: You know the difference between a used car salesman and a computer salesman? A car salesman knows when he's lying.

Re:People change jobs all the time

[wonkavader]

I thought you were going to say that the car salesman knows how to drive.

Re:People change jobs all the time

[TheMCP]

Bad programmers move on to do other things.

Except when they don't. I've seen bad programmers who simply move from job to job, doing incompetent work until their employer catches on and gets rid of them.

Re:People change jobs all the time

[DeVilla]

This is true. I know a fellow who got a job selling cars, not based on his knowledge of cars, (though he is knowledgeable and was actually applying to be a mechanic) but based on his ability to perform a simple act requested by the interviewer. "Here, try to sell me this pen."

Re:People change jobs all the time

[masmullin]

Whenever I take a test drive, the car salesman always makes me drive. I assumed it was because car salesmen suck at driving.

Re:People change jobs all the time

[ryen]

Bad programmers move on to do other things. A guy may suck at programming and be perfectly fine in IT doing maintenance, managerial duties, or in an over priced big box electronics store selling some new electronic pieces of shit.

There, fixed that for you.

Re:People change jobs all the time

[Anonymous Coward]

The bad programmers usually get an MBA and move on to project management. We all know since they can't program that well... they can't possibly mess up a project by managing them. Laf.

Re:People change jobs all the time

[MilesAttacca]

Speaking as someone who does sell those extended warranties, it's not a black-and-white bad deal, because of the customers themselves.

Scenario 1: We don't sell a warranty on an electronic product. It breaks. The customer will invariably want to return it to our store, after the 14-day electronics return policy clearly printed on the receipt (a policy I explicitly mention at the register) -- hell, often months later. When I remind them of the return policy, and tell them they now have to take up defects with the manufacturer, 9/10 of them won't get why this is the case and feel disappointed and cheated, and at least 1/3 will tell me they're never shopping at my store again. Some of them do this more "nicely" than others.

If I do sell a warranty, the user is covered against accidental damage, damage not covered under the manufacturer's warranty, and just not wanting the product after all. Compared to a 15-days-plus regular return, management doesn't bitch as much about a store warranty return performed in the store, even though we're supposed to direct customers to our 800 number/website to process returns. (From personally having one of the warranties on a camera I eventually dropped, yes, it really is a no-questions-asked, quick, friendly process. I don't think I even mentioned I'm an employee.) Since we can do this, the customer is happy, and my job is much more pleasant.

The important point of this story is that the customer doesn't understand the return process, and the customer doesn't want to understand the return process. He doesn't know why his product broke, or even if it's really broken. He doesn't want to look for solutions online, doesn't want to go to the trouble of phoning the Indian call center of the now-distrusted company, doesn't want to box the product up and ship it back. He goes to the "source" of the problem, my store, and just wants his money back within about 60 seconds and the signing of a single receipt.

Theoretically, by selling these no-worries warranties, I'm contributing to the downfall of mankind by telling people that, with a warranty, they don't have to be self-reliant, knowledgeable, or in any way responsible. But it's not like I could instill these qualities in random strangers, anyway. So by selling a warranty, I gain an extra dollar or two in my paycheck (employees' motivation to sell these is primarily managerial, not financial). The customer is placated. I don't have to call other employees or managers to the register, to say exactly what I just said, and take the exact same abuse from the customer.

TL;DR: Customers don't want the truth; that's why it's unacceptable. Until their attitudes change, or my company decides to engage in charity by paying its employees to help soccer moms grow up, instead of paying us to sell product, I'm more than willing to deliver a 30-second spiel about an extended warranty in the hopes of just keeping all parties happy.

Re:People change jobs all the time

[St.Creed]

I once had a trainee colleague who came out of the psychology field and had retrained into IT. She was pretty bored by the whole IT thing after a month or 6, and she wasnt very good at her job either.

However, I ran into her about 10 years later, and she's an IT-manager now, appreciated by several good IT-folks as one of the best managers they ever had the pleasure to work with. She just had to find the place to apply her real skills.

Re:People change jobs all the time

[Hojimbo]

An actual techie might tell the customer his opinion. Techies aren't geniuses - often, they're more prone to a "Oo, shiny new technology" mentality than others. In fact, how many techies do you know who are willing to accept a completely broken product or first-generation technology because they're excited about what it could become, or what it stands for? I would almost argue that a dumbo floor salesman is trying to deliver to a customer something that the customer is more likely to understand and be able to use.

What consumer, who aren't techies, would want those things?

What I'd do

[ILuvRamen]

First of all, if you say at your next job interview "I worked on _____" they won't know what the hell you're talking about. Even IT people don't know about every single software solution ever made and how it performed. The odds that they'll have any idea what you're talking about is non-existant unless you worked on Vista or something.
But if you are working on some super high profile project like for Microsoft or Facebook or something, you'll definitely want to quit BEFORE the project is even close to done. If you know it's idiotic and as soon as it's done it's a disaster and the execs all blame you for their own stupid idea and fire you, well then you're out of a job anyway. So beat them to it and quit! But before you do, tell the higher ups that you refuse to work on a project that pointless and wrong because of what it'll do to your career. Tell them if they don't let you make the major changes you know it needs or cancel the project, you quit. Usually they'll just tell you to quit but who knows, it might get you somewhere.

Re:What I'd do

[Anonymous Coward]

Wow. That's horrible advice.

Burning bridges is stupid. You may very well need a job at that same company some time down the road and the same "clueless" manager is going to be the one hiring you back. A much more pragmatic approach is to simply say that you have opportunities elsewhere and wish them luck on their current project. Being positive, even as you're leaving, is always the correct strategy.

Re:What I'd do

[Brian Gordon]

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

Re:What I'd do

[Kell Bengal]

I agree - definitely jump ship before the the shit-fan interface, but don't burn your bridges. Just tell them you 'need a change' or that you're seeking new challenges. People understand; it might even make you look smarter in their eyes because you saw the writing on the wall early.

Re:What I'd do

[Anonymous Coward]

That's an incredibly dumb thing to do. Projects fail, yes, but for many different reasons which may or may not be an individual programmer's fault.

Bad overall vision for the project.

Poor marketing.

Bad user interface.

Competition from bigger and more powerful companies.

If your programming chops are as good as you think they are, you will walk away from a disaster unscathed. There is a difference between a piece of shit and a finely-engineered piece of shit.

Re:What I'd do

[emandres]

tell the higher ups that you refuse to work on a project that pointless and wrong because of what it'll do to your career

I guarantee that if you go into your boss and refuse to do work you'll get fired for insubordination. In addition, bringing up your "career" is bound to send a pretty strong signal to your boss that you don't plan on working there very far into the future. If the place sucks to work at, polish your resume/CV and start making yourself known to other companies. Don't sabotage yourself by pissing off your boss, thus ensuring a negative reference from your previous employer.

Re:What I'd do

[Kjella]

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

Well, you are taking advice from a guy with the nick "ILuvRamen" - maybe there's a connection?

Re:What I'd do

[johnlcallaway]

Burning bridges is always a bad idea. I'm just turning 50, and it has surprised me the people that I used to know that pop up. In fact, past antagonists gained new respect from me in later jobs as they learned from their mistakes and matured.

That doesn't mean one can't offer advice, one just needs to word it diplomatically instead of calling everyone dumb shits.

Re:What I'd do

[Anonymous Coward]

Tell that to Sarah Palin.

Re:What I'd do

[Anonymous Coward]

A few years back, when I was young and foolish (now I'm just older), I joined a company in the midst of a huge project. At the end of 1 month, I sent my boss an e-mail with a few questions regarding what I thought were show-stoppers. Stupidly, my boss forwarded my e-mail on to several people, looking for answers. And my 'career' there went to hell. I discovered just how unpopular the guy who yells "But the emporer has no clothes!" can be, unless concessus swings your way.

I was out of there after a year. The project took another year to implode. On the exact points I raised. 300+ people, 3 years, half a billion dollars. But it didn't help me one bit.

My advice, in retrospect, is pretty simple: Keep your head down, offer your suggestions - as quiet, subtle suggestions - just once, and, if things don't change, start looking elsewhere.

Re:What I'd do

[avilliers]

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

"I wanted to work on a project that was going to be successful, and I left when I became convinced that I couldn't contribute effectively given the current set up."

Showing you know the difference between a good project and bad project, especially ahead of time, is a plus in an interview. Showing you care enough about the end result, and not just a paycheck, is a plus. You should be able to communicate both of these things pretty convincingly if you left a high-profile disaster ahead of time. Make sure you're professional enough to talk about these things without badmouthing co-workers or sounding like a legend-in-your-own-mind, but other than that you're fine

Even if a project was successful, interviewees should be able to explain what they learned from the things that didn't work well. If it was unsuccessful, they should have a long list of mistakes that they now recognize first hand--and if you're going to claim you recognized all these things at the time they were happening, why did you stay?

I'd be just as interested in hearing the answer to that question. It's not like either situation would make you start with a presumptive strike against you--both should be pretty easy to explain. But there should be some level of awareness demonstrated, shouldn't there? If someone's attitude is "I did what I was told, my section worked fine," you know (at best) you're dealing with someone who has a pure grunt mentality and will never take responsibility for the overall product quality. I'd find working on a project like that very frustrating, and would be suspicious people who didn't.

Re:What I'd do

[Hurricane78]

You have your views, and I accept that. But I, for one, am sick and disgusted of people who always want to play nice to everyone, no matter what that asshole did on said, because "some time in the future, you may need him".

I proudly "burn those bridges". And then I live with it. Because there are tons of other opportunities. Other cities, jobs and countries to go. And even in the same city, with the same job, you still got enough choice.

Besides: Why do you see it this way around? I see it the healthy way around:
He burned the bridge. He killed it. He was the idiot. And most importantly:
He is the one, who now has to live without my skills.
So if he continues to do that, he soon will be alone, knocking on my door. And I will be the one telling him that he should have done a better job in the past.

Stop seeing yourselves as "lower" than your previous "boss". You are on the same level. Yes he got the money. But you got the skills. Let's see him try to build a program out of paychecks.
Yes there are others with such skills. But just like that, there are others with that kind of money.

If you're good, he will apply for a job below you in 5-10 years. :)

Maybe I will go broke, when that usually never happening event happens, that an old boss is my only hope left. But at least I will still be able to have some pride, instead of being someone who buckles when he has to face that type of egocentric person.

Re:What I'd do

[Anonymous Coward]

It's not ideal for your career but if you've come into a company where a very bad decision was made shortly before you came in and the project continually slides down the drain because any with talent gets fed up with being ignored then you do find it hard to stay on board.

It is nice to see how far you can shine the turd and make the best of a bad situation but being out numbered by idiots makes it hard to see things through.

Re:What I'd do

[Hurricane78]

Guess what. I burned the bridges in my last company too. In a way that let a 500 people company still talk about it one year later!
And one year after that, I got a job offering from them. Begging for me to come back. I said no thanks, and that I will buy them for an apple and an egg. (Is it really "for a song" in english? Sounds strange.)
Two years later, they closed the whole shop. Trying to sell the business shortly before it. For that apple and that egg (or that song if you want). :)

I'm not going to play that crooky lie of "ok, everything is ok". Because I will rather die than come back, begging for anything.

Sadly, lack of pride is a big problem nowadays. Which creates many slavery-like jobs for many people in the first place.

After all, managers *learn* that everything is ok with what they did.

Just like in a relationship with someone. *Actually talk to them and state the problem*. :)

Re:What I'd do

[TheMCP]

You're telling your interviewer "I quit in the middle of organizational failure, and I'm smart enough to cover my ass by jumping when things are obviously wrong, rather than stupidly going down with the sinking ship."

Re:What I'd do

[Kell Bengal]

You raise an interesting point - do managers 'learn' that spineless people will just smile and nod to keep their jobs, or is it the attitude of people who get into that line of work? I wonder if things would really be any different if people were more proactive about job mobility.

Re:What I'd do

[nahdude812]

Employers don't want to hear, "I don't like XYZ, so I quit," they want to hear, "I don't like XYZ, here are the problems, and here is a better way to do it."

I understand that sometimes it doesn't matter how good your proposed replacement plan is and how bad things are; some companies are simply not going to hear what you're saying. But an interviewer wants to hear you say what the specific problems were, and what steps you took to try to address them before you gave up. If you tell them you quit because the project was failing, they're going to want you to convince you that you're 1) not a quitter, 2) can critically analyze the gaps, 3) can offer a meaningful and workable solution, and 4) that you can articulate it and be convincing without sounding whiny, angry, annoyed, hotheaded, smug, or any other such negative emotion.

Quitting a project because it's failing is giving up. If you're taking that stance, you'd better be prepared to convince your interviewer that there was no reasonable alternative. I sure don't want to hire you onto my team only to find out that when it gets thick, you split (right when I need you most).

Re:What I'd do

[Stiletto]

Showing you know the difference between a good project and bad project, especially ahead of time, is a plus in an interview.

On what planet? In the interviewer's mind, that translates into: "Given the doomed projects coming up, this guy is going to quit within three months. No Hire."

Re:What I'd do

[cerberusss]

"I wanted to work on a project that was going to be successful, and I left when I became convinced that I couldn't contribute effectively given the current set up."

Make sure you're professional enough to talk about these things without badmouthing co-workers or sounding like a legend-in-your-own-mind, but other than that you're fine

I thought about what is different between the message you're giving and the GP his version of the message. Both basically say the same, but your version is better.

GP says: "They did such-and-such, which I suggested they fix. But they just kept doing it. So I threatened with this-and-that, then took off before they could blame me." Lots of THEY in that sentence, says basically: blames other people, not in control.

Then I realized your version is better because it is said from the first-person. In other words: "I wanted such-and-such, but I felt this-and-that, so I did action-such." It shows that you knew to listen to your instincts, and did what was in your power.

Something to be learned from that.

Re:What I'd do

[avilliers]

On what planet? In the interviewer's mind, that translates into: "Given the doomed projects coming up, this guy is going to quit within three months. No Hire."

You may need to work on your interviewer mind melding skills.

Just ask yourself it that's what you'd think as a manager interviewing an employee. "I have two candidates, one who will understand what's going on in the workplace around him, and one who won't. I obviously need to hire the clueless one, since the smart one will recognize that I am an incompetent who will do nothing but feed him projects are destined to fail." I imagine probably not? Then why do you think anyone else would think that way?

You may be confusing a candidate's being able to distinguish good and bad projects with a candidate who's just a prima donna. The guy who projects a sense of entitlement, who will only want to work on the central aspects of high-profile projects, yeah, he's not going to get an offer. As I said in my grandparent post, you want to make sure you're not coming off that way. Explain why the project failed. Don't explain why it was "beneath you."

Also, this is distinct from concerns about someone being overqualified. Overqualified (ie, should be running a team on paper but is applying for a grunt job) is a concern. Then you're worried that they might leave; but you're also worried that they're apparent "underperforming" is because actually quite incompetent, so exuding cluelessness will not help.

Re:What I'd do

[avilliers]

I thought about what is different between the message you're giving and the GP his version of the message. Both basically say the same, but your version is better.

[ . . . ]

Something to be learned from that.

Well, thanks.

I'll add, along those lines, that the second approach suggests you're willing to work with the manager if things start going poorly. Someone who says "This project is failing, fix it before I quit" creates problems for a manager. Someone who says "Can we figure out a better approach?" creates opportunities.

Re:What I'd do

[Not The Real Me]

"...The project took another year to implode...300+ people, 3 years, half a billion dollars..."

Sounds like a typical government project.

Re:What I'd do

[Anonymous Coward]

There is an exception to the "don't burn bridges" mantra (which I have always followed, except for this one exception).

Look deep into yourself and decide if working with, for, or even having your name approved by the person is going to ruin your life to the point you'd rather be on welfare for the rest of your life.

If the answer is yes, burn, baby, burn!

I had one manager that bad, ever. Anywhere that person works will, guaranteed, be a shithole because they work there. Period. I quit that job with the intent of going on welfare (very lucky for me I managed to find work elsewhere).

Re:What I'd do

[Anonymous Coward]

Do you know what the difference is between big government failures, and private sector failures? Everyone knows about the government ones.

No, that was not a government project. A large company whose current motto "We'll give you an edge." combined with a blue triangle that looks suspiciously like a guillotine.

To put matters in perspective, since then, I've moved to another honking huge company. And seen two huge projects go down the tubes ... one after 7 years and half a billion, the next after just two, and a quarter billion.

There are some serious problems with the way things like this develop. Bureaucratic inertia is terrible. Trying to get something going takes a lot of effort. The problem is, when problem are discovered, it takes a similar herculean effort to get them to change direction to where they should be going.

Often, people are measured - internally - by things that have nothing to do with the overall success of the company, or a project. The original question dealt with 'guilt (or assumption of incompentence) by association'. Seriously, it's pretty much a non-issue. Most developers have zero say in the overall success or failure of a project. In the original project I mentioned, there were three components; client, server, and mainframe. The mainframe piece (my realm, along with a dozen others) was up and running, flawlessly, months before the original deadline. The server and client side couldn't get a basic transaction to run under five minutes, after three years. OTOH, the manager of the mainframe side of the project got shown the door, while the other two *champions* went on (and up) to the board. The company who subsequently hired the mainframe dude knew the score, and they wanted someone who could get the job done, rather than excel at internal CYA politics.

And most interviewers recognize this.

Re:What I'd do

[chez69]

Folks that quit in the middle of things are quitters. I wouldn't hire somebody who didn't want to be part of the solution, they'd bail on me as soon as things where boring.

Why would I want to work with somebody who can't stand adversity?

Re:What I'd do

[An Onerous Coward]

The answer depends a lot on how much adversity you intend to dump on them.

Sitch1: tiny amounts of adversity. Those who can't handle it in small, necessary amounts clearly have problems with their own sense of entitlement, and should be avoided.

Sitch2: moderate amounts of adversity. Different people will have different tolerances. Some will thrive under pressure, others will just muddle through, and some will fall by the wayside.

Sitch3: crank the pain up to 11 and rip off the knob. At this point, all that's left are the kids who haven't yet realized that there are better jobs out there, and the depressed mole people who will cling to the job because they don't think themselves fit to be in the industry at all. But they'll still be resentful, and will plot your demise.

There must be balance in all things.

Re:What I'd do

[An Onerous Coward]

I don't think anybody is asking for the right to show up to a job and idle away the hours on Facebook. The way to get out of a doomed project is to request a reassignment, or to look for another job. Nor did he say that you should explicitly mention your career as the reason for your departure.

It's hard to say what signal you're sending by quitting in the middle of a doomed project. Interviewers hear everything from "this guy takes pride in his work" to "quitter." All you can do is try to spin your way to the former interpretation, and let the chips fall where they may. If you can communicate the sentiment, "I'm generally loyal to my employer, but I do have my threshold for stupidity," and an employer takes that as a red flag, it's probably because they intend to exceed that threshold on a regular basis.

Re:What I'd do

[Hurricane78]

Well, it's very interesting, how things were in Luxemburg some years ago.
Luxemburg is a tiny country. With 480,000 people living there. And over 30% are foreigners.
The country is so rich, that people do not want or have to work. So we had the apparently rare situation, that there were much more job offerings than actual people wanting to work.

So people did not have to fight for jobs, but companies had to fight for employees.
This meaned that potential employees could make demands, just like bosses do "usually". So Christmas bonus? Ok, then I'll go to the competition.
So even fathers got parental leave for I think one year. Etc.

I can tell you that it was great to be an employee in Luxemburg. 1200 was the minimum salary per month, by law. You had all that you wished for.
The only problem was, that people started to demand unrealistic shit, so that businesses themselves suffered. And some spineless companies who had to get new employees now, or go under, bought into these demands. Which forced the rest to do the same.

So what I learned, is that no matter if it's bosses, employees, clients or companies: There is always an idiot who will do it for less. He may not be able to live from what he gets. But that is why he's called an idiot in the first place. ;)
So he drags the standard to a new low for everyone else too, making the whole situation worse in general. This is true for markets where a company offers too cheap prices. For employees working for ridiculously low salaries. Clients letting companies rip them off. And bosses hiring even more incompetent employees.

But I have yet to find a solution, other than just accepting that such people exist, and standing by your own self-value and feeling of what you see as a fair deal.

Re:What I'd do

[plopez]

Folks that quit in the middle of things are quitters.

What if it's a 13 year project? I'm serious. This project started in 1981 and was killed in 1994:
http://www.baselinemag.com/c/a/Projects-Processes/The-Ugly-History-of-Tool-Development-at-the-FAA/

Could you tough it out for 13 years? 10 years?

I've seen people burn out in 18 months of 6-7 day 50-70 hour weeks. I was one of them. I'm not sure if you have ever experienced one of these train wrecks. Get yourself involved in one and then let's talk.

Re:What I'd do

[St.Creed]

If the shop you work for has cowards in the management then nothing can save it. However, I worked for a different company, with a different culture (*) when I told my boss I would advise to stop the project another department was working on (they had turned to us for advise and management saw it as an opportunity to get a foot in the door there). My advise wasn't popular but I could argue it convincingly when I presented it so we withdrew support. The other department continued and about a year later they cancelled it, having spent 500.000 euro in fees and nothing to show for it (they tried to connect 12 parties in a new system, several of those parties had a distinct business interest in getting the project to fail, and two of those parties were in fact key players for the project. The issues weren't technical at all, so the external nerds doing the project hadn't noticed the warning signs).

Later I repeated that one with a project that 'wasn't going too well' according to my manager, who asked me to join it and help out with phase II. Within 3 days I had to report back that the previous 8 months of work had basically been wasted. He wasn't too happy about it so he told me I'd better solve the problem - and I did :) But if I had convinced him it was a lost cause, i'm 100% sure we would have pulled out. Whatever the reasons I left them, it wasn't for incompetent management.

(*) See http://en.wikipedia.org/wiki/Geert_Hofstede for information about a very influential writer on business culture. It's a good place to start.

Re:What I'd do

[chez69]

of course there must be balance. However, If I was a hiring manager, I'd have a lot of tough questions for somebody who quit because it was 'too hard'. Being able to handle pressure is so important, especially when your fixing files by hand at 3am in the morning before a 4am deadlnie.

Anyways job pain is very subjective. I've had a lot of situations in my career that folks probably would say the pain was at 11. I worked thought it and was part of the solution instead of quitting.

Re:What I'd do

[chez69]

I've had my share of hell projects. Be part of the solution, folks that suck it up and fix it instead of pouting/quitting are the folks you want working with you. I'm stuck in an large organization of suck, we've pulled off stuff people said couldn't be done by working hard and staying focused.

Re:What I'd do

[ivan256]

On the other hand, folks that go down with a sinking ship are idiots.

Why would you want to work with somebody who's an idiot?

Re:What I'd do

[Anonymous Coward]

Hello, I see you've become a puppet. You will betray your own values now to protect against a possible future scenario in which defending your values in the past would cause you to not be selected to receive money. Piss on you. What kind of person are you? Are you even a person or just a shell that consumes and defecates? Did you know that it's possible to move your legs without someone pulling the string? After that, living your own life based on your own values and decisions becomes natural. Cool, huh? You're welcome, you spineless piece of shit.

I cant imagine Windows ME is a great career boost

[voss]

However, learning from the mistakes of failed projects can actually increase your value, especially if the employer wants you to speak up.

If executives made the bad decisions, say so

[Anonymous Coward]

It is about the interview. Nobody is going to expect the grunt classifications to be making the big decisions.

Simple explanations of where you made design decisions and where you merely implemented poor design should suffice during the interview. Don't diss your previous managment. Try to remain objective in your descriptions.

In most cases, anyone with any time in the business will have gone through a litany of death marches and will completely understand your history.

Secretly an SCO thread!

[symbolset]

Because who would want to hire the last few software engineers who stayed there through to the last?

A solution

[bunyip]

A good friend of mine spent a couple of years on the Confirm project, which ended in a total mess almost 20 years ago. He claims that he simply put "2 years, federal prison" on his resume so that he'd have a better chance of being hired.

For those that don't know the Confirm project, they spent about $180M and about 6 weeks from the end date realized they were at least 18 months late. You can look up the rest of the details. :-)

Re:A solution

[Anonymous Coward]

http://en.wikipedia.org/wiki/Confirm_Project

Re:A solution

[John Hasler]

> For those that don't know the Confirm project, they spent about $180M and about 6 weeks
> from the end date realized they were at least 18 months late.

Yes, but how did it differ from the average project?

Re:A solution

[BitZtream]

And thats supposed to be shocking or something? Do you realize this is pretty much standard operating procedure for software development now, I can't think of any company that gives me a software release date and I believe it.

Re:A solution

[Swampash]

http://en.wikipedia.org/wiki/Confirm_Project

Re:A solution

[db32]

Funny you should mention that...In the last few days I have been in a few conversations about Windows 7. I say I'm not sure when it will be out and without fail someone promptly tells me the release date...and then I laugh.

Re:A solution

[enrevanche]

They should not have realized that they were late until the delivery date.

Quitting is often worse than completing

[Anonymous Coward]

While I work in a different industry it's also project based and the quality of the project will to some degree determine your next opportunities. What I've found both as a a worker bee and later on in management is that even though the results of the project can have some influence over getting your next contract (I work in film vfx, so if the film looked bad it's harder to find something good to show other companies) not completing the project is much, much worse. Companies want to know that you will stick with them and help them through a crisis rather than bailing on them mid-way through.

As a supervisor I take a close look at a person's end date on a project to see if they jumped ship half way through. There are good reasons to leave part way, but one such as "I didn't like the way it was going" really isn't one of them unless the person could demonstrate specifically what was wrong and how they would have made it better. In business you are paid to do the job asked of you in the best way possible. If you are asked to do something you think is wrong then it's time to start making suggestions as to how to improve the task rather than running away from the situation.

Re:Quitting is often worse than completing

[darpo]

I really can't buy this. Given that companies have no loyalty to workers these days, I believe workers should treat companies the same way. I'm sure in your current role you'd *like* people to be committed and all that. But the reality is that we go to work for money, not out of the goodness of our hearts. Workers need to protect themselves, including by jumping from a sinking ship if necessary, because they have no guarantee that the employer would take care of *them* if situations were reversed (i.e. when the employee is in trouble).

Re:Quitting is often worse than completing

[smellsofbikes]

>If you are asked to do something you think is wrong then it's time to start making suggestions as to how to improve the task rather than running away from the situation.

I have two friends who were fired for doing exactly this, which I think looks worse on your resume than quitting when you realize that your management has already decided to do something you think is a bad idea.

Re:Quitting is often worse than completing

[Ritchie70]

The last few bosses I've had, I have told the same thing:

You pay me too much for me to sit quietly and do what I'm told. If you tell me to do something I think is stupid, I'm going to tell you, in no uncertain terms, that I think it is stupid, and exactly why I think it is stupid.
But I will also accept that there may be things going on that I don't know about, and if you tell me that you understand what I'm saying, but to proceed with the stupidity, then that's what I'm going to do, and I'll do my best to make it successful.

Re:Quitting is often worse than completing

[plopez]

I've never seen loyalty rewarded.

Maybe for some employers but probably not for most

[nahdude812]

It's certainly possible that for some employers they'd hear you worked on Project X which failed spectacularly, and so they'd want to avoid hiring you. But I'd wager for most employers this isn't a black mark against you unless for some reason you have demonstrably substantial culpability in its failure. Maybe if you had 3 or 4 big failures I'd start to wonder if there was a pattern. But even then I'd ask you why those projects failed, and depending on your answer, this might actually make me more likely to hire you. For example, if you could give me a thoughtful analysis of what went wrong in each case, and could give good thoughts on things which might be done to avoid those mistakes in the future, maybe you have the insights necessary to help my team avoid a similar mistake in the future.

The only things I can think of that would make me not want to hire you (based on association with a specific project) is if you put on your resume that you were the lead developer, project leader, etc... or if the project failed for a very specific reason and I knew you were the cause (such as if you were successfully prosecuted for coding a back door into the project, etc).

There were a lot of excellent crew on the Titanic; the crew of the Challenger disaster were not responsible for its failure. Just because you're associated with a catastrophe doesn't mean you did anything wrong.

Just quit

[Gorobei]

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.

Re:Just quit

[Anonymous Coward]

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.

You might pass that piece of advise on to the Washington,DC(District of Corruption) crowd.

Re:Just quit

[JAlexoi]

Really, what about people with iron commitment, that do anything it takes to fix the project till the end? Are those kind of people bad?

Re:Just quit

[TheMCP]

I will hire people who worked on obviously doomed projects or for obviously doomed companies, and I don't mind if they stayed for the final meltdown. Heck, my dad turned off the lights and locked the door for the last time at a largeish corporation a few years ago after its meltdown. But, I will ask for and expect an explanation. If what I get is "oh it was so wonderful I don't understand how it could have gone wrong", I will be dubious about hiring the person, because it demonstrates that they are unrealistic or oblivious. If, on the other hand, I get a simple "I hadn't found a new job yet and I needed the money," I have no problem with that and would consider hiring the person.

Re:Just quit

[lemur666]

Collecting a paycheck to support a losing project is sign you have a wife and two kids to support

There, I fixed it for you.

Working on a doomed project while speaking out and trying to fix it is a sign of an engineer who is a good candidate for promotion. They aren't just focused on their narrow portion and care about the project as a whole.

Generally, seeing engineers quit in the middle of a cluster-fuck project is a ding against their manager. It's up to their manager to make sure the engineers have input into the project, and can actual have their voices heard. Even if the project is a minor failure, people don't mind as much if they feel they have some stake in it. It's also a sign the project can be turned around in a later release if people at least have a voice in how to fix the processes that led to failure in the first place.

Sure some engineers are malcontents who can never be made happy, but these are pretty easy to spot in an interview. They'll talk about how the project sucked, but won't have much to say about how they'd make it better.

And even within clusterfuck projects, there can be small successes. I'm sure there are some lovely components buried deep inside Vista

So a smart interviewer is going to ask questions about your involvement in the clusterfuck.

And if the interviewer doesn't. Try answering the question without being asked. Or talk about how great your subcomponent was. And if the interviewer doesn't like that. Well, do you really want to work for/with a dumb-ass?

It also depends on experience. A smart, junior engineer shouldn't be blamed at all of a project failure. A senior engineer / manager should be asked some tough questions about their involvement.

Then there's the whole "companies with a stench of failure all over everything." Basically, I look for people with short tenures at these sorts of places. I don't want to see a 10 year veteran VP candidate from any company with reputations for "climb to the top of the meatpile" back-stabbers. Or an engineer from a place with a reputation for being insular and producing sub-par code.

Finally, the question you have to ask yourself is "Is this project really a failure?"

15 years ago I left a software company after a 3 year 'Bataan Death March'-style release of what I thought was a very disappointing, bloated, and technologically lagging project.

This product enjoys around a 65% Market share and probably a billion in sales annually.

Re:Just quit

[SirLurksAlot]

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave.

You're obviously a Highly Paid Consultant who could care less what happens to the project or what the client thinks. It's people like you who give developers (and consultants in particular) a bad rap.

Collecting a paycheck to support a losing project is sign you are a loser.

Or they at least have the balls to stick it out until the bitter end, which (if your post is at all accurate) can't be said for you.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown.

Please, what company do you work for so I know who to avoid?

A programmer who quits a clusterfuck is an asset

Or a quitter, i.e. someone I wouldn't care to work with.

It sounds like you're confusing loyalty and professionalism with laziness. Personally if I'm hired to do a job I stick it out until the job is finished. Even if the project ends in spectacular failure, as long as I did my absolute best I stay until the job is done and I expect those I work with to do the same. Everyone works, no one quits.

Re:Just quit

[Gorobei]

You're obviously a Highly Paid Consultant who could care less what happens to the project or what the client thinks. It's people like you who give developers (and consultants in particular) a bad rap.

I'm a highly paid employee who wants a good job done. I've dumped clients when what they want is absurd: better for my guys, better for them: building stupid stuff is a waste of everyone's money and time.

Oh, and the phrase is "couldn't care less."

Re:Just quit

[Gorobei]

If they were good, they would fix the project. Ideally, two weeks in, they go to the boss with a plan to fix. If that doesn't work, three weeks in, they go to her boss with a plan to fix. If that doesn't work, they quit.

Re:Just quit

[Anonymous Coward]

No you aren't. You're a fat poopyhead.

Re:Just quit

[JAlexoi]

There are some people that are in IT not for the paycheck. And sometimes sticking to the project till the absolute end is a very good experience.
And a lot of times, the projects fail because of the third parties involvement, or lack of involvement. In those cases nothing a developer can suggest will help the project.

Re:Just quit

[JAlexoi]

I've dumped clients when what they want is absurd

I sense a major client expectation management problem in your character. Not good...
If you do not know what a client requests upon project start, it's usually a failed project to start. Fire your sales/contract negotiator/project manager.

Oh, and the phrase is "couldn't care less."

Apparently you could care less.

Re:Just quit

[Gorobei]

If you do not know what a client requests upon project start, it's usually a failed project to start. Fire your sales/contract negotiator/project manager.

I don't think we're philosophically far apart here. Project start is the best place to have a go/no-go decision.

I don't much use sales/contract negotiators, etc: just have an expert (senior programmer or whatever) flesh our the rough details with the client, report on the general situation (size, hardness, and sanity,) and we can make a decision in a few minutes. If you find yourself with more than a page of contract per $1M, you're doing it wrong (for in-house work, one email per $100K is a good rule.)

Re:Just quit

[Gorobei]

ok, so stick to the end once just to see what a pointless, soul-draining waste of time it is. Then never do it again.

Learn to fail fast: give it 100% effort, try to make it work, but never lose sight of the big picture. If it is destined to fail, try to fix it. If you can't fix it, go find something you can make a difference on.

Re:Just quit

[Kjella]

It sounds like you're confusing loyalty and professionalism with laziness. Personally if I'm hired to do a job I stick it out until the job is finished. Even if the project ends in spectacular failure, as long as I did my absolute best I stay until the job is done and I expect those I work with to do the same. Everyone works, no one quits.

For me you sound like two extremes on a scale and I think you're both wrong. Yes, if you quit the first time a project you're in is in trouble then you're a quitter. But if it's a huge project or it's a repeated problem, why do you want to inflict a death march project of on yourself? You know the kind where you know the project will be a failure even if your part is flawless. That kind of thing is just a soul-destroyer of morale, making you feel like you live in a Dilbert strip. If the company is just too stupid to cut their losses, are you supposed to loyally and blindly follow their stupidity? Draining every last paycheck before the project burns isn't exactly building confidence in the consultants that either, then you're just blamed for bleeding them dry and leaving them with crap. In fact, I'm quite sure I've heard more accusations of that than the opposite. Of all the reaosns a project fails, "horrible internal project mismanagement" is always the very last option if you got noone else to blame. Try to guide them through the rough waters, but if they insist on heading full speed like Titanic against the ice berg, then I say abandon ship. The honor of going down with the ship may gladly be left to the captain, not the crew.

Re:Just quit

[plopez]

Either dump the client and or jack up the fees to an outrageous amount. If the client still wants to do the project, subcontract it out. If/when the project fails blame the subcontractor :)

Project failure is not business failure

[holophrastic]

Keep in mind that when it comes to actual businesses, it's often better for a project to fail catastrophically in two months.

A project that is started, realized, and dead in two months costs two months of resources. Compare that with the following:
    - a project that takes a year of work to get off the ground, and then eventualyl fails after repeated attempts to make it profitable over another two years.
    - a project that takes three years to become profitable

The former is not only a waste of money, it's a waste of time too.
The latter is profitable, but when considering the opportunity cost, many businesses look for faster, simpler, and lower resource-intensive projects.

The reason business-level executives can be rewarded for a failed project is because a smooth fast failure is a good thing is high-risk projects.

Realizing failure is just as important as realizing success -- when you've got other work to do too.

As for developers knowing earlier, I call zombie bullshit. Developers know when the product isn't great. Business has always made successful projects from crummy products.

Also compare spending $N on a project over a year, versus spending the same $N on the same project over only a month. In business, the latter is better -- why waste time.

But hey, we're all science-lovers here. Look at business the way we look an scientific research. If your experiment can be done faster, at the same or even a moderately increased cost, you get to results faster, and you get to do more experiments, and you get to move through more potential filliments before finally being able to invent that working lightbulb.

Re:Project failure is not business failure

[PPH]

Checking it off as failure and moving on can be good .... if it saves resources. But the bean counter logic states that $N is $N regardless of whether you burned it fast and moved on or slowly and tied up assets. Your time all goes on the books the same way.

What it really boils down to is: How will the project cancellation be handed on the books? Will it appear as a charge on the annual reports? Did it reach some threshold where it must be revealed as material information to the stockholders?

I worked on a project to replace a crippled DB at one outfit into which the company had tossed a quarter of a billion dollars. It took us (5 developers) under a year to build the successful replacement. But the dinosaur still lives on. As an application with drastically reduced functionality, hosted on a system in some corner. But from the point of view of the bean counters, its still operational and may be depreciated over its lifetime instead of charged against income in the quarter the plug is pulled. So they can keep $250 million in fuckup off the books by spreading it over 10 or more years. Needless to say, the old project's management is long gone. Our management always labored under the threat of having to declare that it is time to unplug the old one. Because all the BOD will see is the crippled balance sheet with our boss's name on the memo.

Re:Project failure is not business failure

[holophrastic]

yeah, but that's the bean-counter world of accounting, not the .c.e.o. world of growing the business and finding the next big thing (for that company). And in the end, the bean counters rarely hire the .c.e.o. (unless there's a .c.f.o.)

Re:Project failure is not business failure

[PPH]

A couple of decades ago, our last engineer/CEO retired. Its been bean counters (and a few lawyers) since then. The bean counters don't just hire the CEO, they become them.

Lame Project Survival Kit

[ddt]

I've been in this position a few times because in game development, there are lots of bad games out there that are rushed to completion to sync them up with the release of a film, for example, or to hit Christmas, or because a publisher is trying to make its quarter or because a developer is running out of money.

Here's your lame project survival kit:

1. Stick close to the most talented folks on the team, and treat them as your real boss. Pretty soon, they're going to leave. Make sure they have fond memories of you, so that they can recommend you where they end up, and make sure you get their personal email addresses. Everybody loves a good, helpful coder. This is by far and away the most useful thing you can do for both your soul and the long-term health of your career.

2. Drop the project from your resume. Mention the company but explain that you worked on various projects there.

3. Take responsibility for turning the project around, find a scapegoat in sales, gather evidence, and pin it on him (never in writing) when it goes down in flames. This will make you part evil and is a big part of how people fail upwards, but lots of folks have had made lucrative careers using this approach.

4. Lame projects typically have poor direction and allow people to get away with doing whatever they want without being fired, as long as they look busy. So invent a task that or sub-project that results in a short, flashy demo or video that makes you look good to your next employer.

5. Flatter the slimiest, most inept manager in the group. They typically crave this because no one recognizes their true "genius". They also often pick option 3. and end up attached to some new project to fuck up, which can buy time while you're looking for a new job. They work hard to surround themselves with loyal useful people who say nice things about them.

6. Start humbly asking to buy the CEO lunch and start picking his brain on executive management or anything he knows lots about and seems to be passionate about discussing. Never let him pay for lunch, because you consider it too educational. You may or may not be interested in what he has to say, but the key thing is face time. When things go to poo, it'll be harder for him to fire you.

7. Stop being lazy about your future. Look hard for another job. Put 1-2 hours into it every day after you come home from work. Lame projects blacken and destroy souls.

Re:Lame Project Survival Kit

[Sadsfae]

I've been in this position a few times because in game development, there are lots of bad games out there that are rushed to completion to sync them up with the release of a film

You mean like E.T. for Atari?

http://en.wikipedia.org/wiki/E.T._the_Extra-Terrestrial_(video_game)

Re:Lame Project Survival Kit

[sigmabody]

This is great advice, IMHO, #1 especially. As a senior developer who has both switched companies a few times, and been responsible for trying to find other developers to hire, I have pulled in friends and colleges on many occasions, and I could get a good developer I knew from a previous company a job pretty easily (even today). The problem for people with other good developer friends is usually more that they don't live in the right place, and/or are already happily employed, and/or don't want to work at the particular company.

Re:Lame Project Survival Kit

[JAlexoi]

Well I make my career by joining late projects and doing everything to fix them.
Whenever I see that the project will fail in any case, I quote the project as a project where I have learned "How NOT to do things".
And I can't complain about my career.
On the positive side, the late projects have actually relaxed their rules to get the project completed. So I get into an environment that needs results fast and I can push through more innovative ideas through. Whereas, on a "on schedule" project, there is little space for innovative solutions.

Re:Lame Project Survival Kit

[Anonymous Coward]

6. Start humbly asking to buy the CEO lunch ...

I work in a fairly big company. I think I'd rather eat vomit from a shoe than have lunch with my CEO (grade "A" prick).

Re:Lame Project Survival Kit

[Anonymous Coward]

This is honestly the best advice I think I've ever read on slashdot. You should write a book. I'm not kidding.

Re:Lame Project Survival Kit

[Anonymous Coward]

Erm... Is this from actual experience?

All of this sounds a lot like the past 6 months of Dilbert strips.

Re:Lame Project Survival Kit

[Kjella]

Well I make my career by joining late projects and doing everything to fix them.

Yes, but it's a different story when you're hired in to try rescuing a ship rather than being accused of sinking it. That says you're a specialist we send in when average people have failed.

Re:I cant imagine Windows ME is a great career boo

[Herkum01]

The question is whether they learn anything or not.

Some people will repeat the exact same mistakes if they are unable to self-evaluate. They not only have to identify mistakes but also the proper way to do something. It does not have help if they try something different at the next job and that is wrong too.

NT: Pfft just blame it on QA!

[Anonymous Coward]

NT

Inside, sure; outside, not really

[Anonymous Coward]

A project that failed due to bad executive decisions, can hurt an engineer's chances inside the same company. But other companies don't care so much.

Not a problem

[PPH]

You can always lie on your resume and explain the last couple of years as having served time in the state penitentiary.

But seriously: I went into private practice as an engineer because of this. Not due to a single project. All of mine were quite successful, making them oddities at my old company. But the stink of that employer's reputation just won't come off a CV.

Re:Not a problem

[Anonymous Coward]

But the stink of that employer's reputation just won't come off a CV.

So what was it like working for SCO?

Re:Not a problem

[drinkypoo]

Exactly what I was going to say. SCO had a lot of brilliant minds, it's a shame about what happened to the company. They blew it back in their tech days though, with their sad Motif-based desktop. Talk about failure to innovate. I still know of no OS for the 286 superior to Xenix :)

What normally happens

[Sadsfae]

with expensive upper management/executive types is they do rove from company to company, doing the exact same thing they did at their previous job.

The notion that it might not work at a different organization never comes up or is questioned, they want be seen making large, sweeping changes.

An example would be shoving some mandate down the pipe like an open floorplan for "collaboration" which in most cases turns into a noisy, distracting work environment that just ends up impeding efficiency rather than enhancing it.

Because this was "so successful" at their last job, the lack of effectiveness at the present can easily be blamed on staff, culture, etc.

For larger, more destructive mandates these guys are usually out the door, resume in hand before the full catastrophic effects have been fully felt or realized.

Learn how to turn a weakness into a stength

[Orion Blastar]

and a negative into a positive.

You could have made every mistake you can make on that job or project, but as long as you learned from it and can avoid making the same mistakes, you become a better person for it. That is because human beings learn by mistakes.

When a software project is costing more in expenses to support than revenue it brings in, it is usually because of a quality control problem. I know this from experience and I am usually the programmer taking over "legacy projects" and "legacy software" by debugging them so the quality is better and it runs faster and hardly ever crashes due to the higher quality and quality management process I go through. When I went to college and studied programming I was a student worker in a computer lab, and they had a full time debugger to help the students, when she couldn't help the students because the program was a mess or was for a computer language she didn't know they sent it to me to debug. It was one of my many jobs as I tried to learn as many computer languages as I could while in college. I applied that debugging skill to my career and I helped countless coworkers with debugging issues. How did I get to be so good at debugging? I learned from my own mistakes while writing programs for class, and then I learned from other students' mistakes doing debugging for them, and then from coworkers' mistakes in debugging their programs.

Now while I tried to teach coworkers to learn from their mistakes, they often took it the wrong way, and refused to learn from them, leaving me to always having to debug their programs. The few coworkers that did take my advice and learn from their mistakes went on to other jobs later to be promoted to high paying jobs and careers in writing quality code with quality built into the design. Those that didn't, work the same job, for almost the same pay, and keep making the same mistakes until they are fired or laid off, and then work another job making the same mistakes. I hear from them via email, asking me to help them out like I did when I was working for them, but I cannot as their employers would not want me to see the source code they are working on, so for legal reasons I have to turn them down, and then give them a few web links to debugging books or web sites that might be able to help them out.

Release? That's nothing

[Anonymous Coward]

I've had the whole *company* go bankrupt, and it didn't hurt me. The former CEO of the broke company got me the lead for my next job. Sigh. Probably better to post AC.

Got Talent?

[gru3hunt3r]

I have personally been through this. When companies (or at least the sales people in companies) aren't making their monthly quota they start to get desperate and throw every piece of trash against the wall to see what sticks. I used to think this was a bad thing so I feel a certain kinship to this author. As a developer the consequences of delivering, or attempting to deliver what they told/sold the customer causes their requests to become more and more asinine until eventually they are selling software with features only found in fairy tales.

But just because sales has started promising free elevator rides to the moon so that customers will buy your product does not give you an excuse to not build it... that is what we, as developers do. We make the impossible seem easy, we make it seem magical. That is the career path we have chosen. Alas, perhaps you're not that talented. Perhaps you should consider a job at best buy and continue the 9-5 grind.

The path I will suggest is arduous it will not be paved with roses and cupcakes. Yes, projects will crater, and the disasters will be spectacular -- with enough shrapnel flying every direction to damage everybody. Your companies reputation will become the equivalent of a "turd sandwich", and you will on some days resemble an angry hobbit screaming rants in languages long since forgotten during this age of men. You will need to bend time, and find a way to work 30 hours a day, and your body odor will, at times cause small children and virtuous women to shun you. (It helps if your office has a shower) .. But your skills through this process, they will become uber, nay.. "legendary".

Some slashdot trolls here will say that what I propose is impossible - that you cannot dodge bullets shot at you at point blank range -- but they don't realize you won't need to dodge the bullets at all.

So if you believe the force runs deep and strong in your blood young padawan, then trust it. Give yourself over to it, let it control you and guide you. You'd be amazed what you can do with the blast shield down if you just fucking try.

Oh.. and to respond to your question: True JEDI's don't apply for jobs, they choose which job they want and take it.

ps> After 7 years as CTO .. I ended up getting the CEO's job. (true story)

Re:Got Talent?

[Anonymous Coward]

lol, can you say.... got burnout?

Re:Got Talent?

[An Onerous Coward]

Is this the spiel you give your developers? "We will pile on the stupid and expect you to turn it into gold?"

Your admonitions won't improve anyone's geek-fu. Quite the contrary, it gets them into a mindset where, if it compiles, it's good, and if it runs, it's perfect.

It also teaches them that 90 hour work weeks are not just to be expected, but are in fact a gift from the coding gods, an opportunity to temper your skills on the field of battle. Which may work for a while. Until their marriage fails, or until they realize that they hate working "Jedi hours" for a lousy fifty grand a year. Then, because they've swallowed your Kool-aid, and convinced themselves that "real coders" are supposed to thrive under constant stress and hammer out six impossible algorithms before breakfast, they start looking not for a more laid back coding job, but for a shift at Best Buy.

There is only one use for the crap you're peddling: to get a horde of young coders working long hours at substandard wages. As you mentioned that you're the CEO of your company, this fact doesn't surprise me in the least.

Re:Got Talent?

[drinkypoo]

I'd say you're the troll, or you're well on your way to failure already.

What turd sandwich is this you're allegedly running? You're not proud enough of it to put it in your profile or anything. How many employees does it have, and how many belong to the order Rodentia and work for cheese?

Re:Got Talent?

[Hognoxious]

He's joking. I hope.

Re:Got Talent?

[Anonymous Coward]

http://www.zoovy.com

Re:I cant imagine Windows ME is a great career boo

[Bigjeff5]

Only 30% of IT projects succeed in meeting their original goals of time, cost, scope, or quality. In this sense 70% are "failures".

Nobody gets a bad reputation that "fails" if the project meets the needs of the company/client. Projects that fail completely are generally run poorly, and developer's reputations are not tarnished. Frankly, only an idiot would blame the developer unless they did a piss-poor job. But if that were the case, said developer would have been canned from the project and a new developer would be brought in. THAT looks bad. Finishing a project, no matter how rediculous or terrible it seems to you the developer, rarely has a negative impact. Even if a project gets canceled, it is more likely to affect the project manager's reputation or the reputation of whoever initiated the project.

Again, developers who do a poor enough job to be assigned blame for a project - unless it is a company full of asshats - are usually canned and replaced mid-project. If that didn't happen to you, you should not have a problem, and you could even use it to your advantage in your next job interview. Blame for these types of things are generally an internal company sort of thing, they rarely spread outside the company except for a few industries.

Quitting for anything other than ethical reasons or reasons that are completely unrelated to the job itself would probably tarnish your reputation if you brought it up in an interview. In that case, you should just forget it ever happened. It shouldn't come up unless they go digging for it, and they won't be able to get anything negative relating specific to you unless you specifically made the news somehow. In that case, be honest about your role in the project and be honest about what happened. Unless of course it was your fault the whole thing failed. ;)

I'd say no

[NotSoHeavyD3]

But then again I left my previous company a few weeks before the sh*t hit the fan because I was going back to school for a couple of years. I'm not sure if I would have had problems finding a job if I looked immediately after that fiasco.

If Office Space Has taught Us Anything

[senorpoco]

It is that programmers will ALWAYS fall on their feet, and office space wouldn't be lying would it?

Re:If Office Space Has taught Us Anything

[drinkypoo]

One thing that life has taught me is that when I have found myself out on a financial limb, it's because I walked there.

As a kid starting out I seemingly had no advantages. Awkward, pudgy, socially inept (thank you, thank you) and yet physically imposing, I seemed purpose-built to alienate. The only people who "got" me (aside from the occasional sweet but shiftless sweet young thing) were other nerds. Luckily, these people are often in charge of hiring other nerds, because faces and in fact whole people glaze over in the HR department when people start talking about actual job requirements.

I did in fact have have three advantages; Location, location, and location. Growing up in Santa Cruz meant that I was in a miniature hub of technology, which included then-giants (or at least players) Borland and SCO, in addition to a laundry list of other software companies like ADAQ (A company I worked for briefly which had a SCO Xenix/Unix-based delivery routing and tracking package) and even a few hardware companies like Mountain and Seagate. My first tech job was as an MIS intern with the County of Santa Cruz, and I parlayed this into a successful job interview with a couple of old school EMACS-whacking nerds who worked for a semiconductor design company which is now owned by Creative (the name was less ironic when it was appended with "Labs", implying that they were still at least working on their creativity. Later I worked for a company which developed a groundbreaking music sales website for Creative, which was cancelled. The logo the company designed became the logo for their MP3 players.)

Before the web company job I also worked out in Austin for Tivoli systems, which had recently been acquired by IBM. I moved into an apartment in North Austin because it was easy to get into and was literally the closest thing to work. I paid $600/mo for 600 sq.ft. with a stacked washer/dryer and people told me I was insane to pay it. Coming from a situation where I was sharing a five bedroom house with five other people and paying five hundred, and didn't even have a parking space, I was ecstatic.

In spite of having (obviously) made good money at numerous times and clearly being capable of living on a low cash burn rate, I do not have any gigantic savings amassed. I do not own a home. Shit, one of my vehicles is up on jacks and the other one probably should be... though to be fair I have AFAICT every piece and part to fix the one that's put up, and plan to get to it right after my coffee :) Still, the fact that I'm still getting myself all greasy under my vehicles proves that I could have made more intelligent financial decisions along the road here.

The moral of my long, meandering, and probably primarily sleep-deprived comment is that I personally decided to fuck around and have a good time instead of preparing for my future. When I was living in Texas I could have moved into a cheaper apartment and bought land here in Lake County, California for practically nothing. I could still have lived quite well, and probably would have gained about a hundred less pounds by just cooking at home instead of eating out all the time and inhaling Doritos like models inhale drugs. I'm only now recovered physically from that ordeal... although I'm sure my pancreas suffered irreversible damage :P

Re:Maybe for some employers but probably not for m

[TheRaven64]

Not to mention the fact that, if you saw a project fail close-up you probably learned a bit about why it failed. Hopefully that experience taught you something. If, on the other hand, you've worked on several projects that all failed then you're probably not the best bet as a new hire...

I think you got it the wrong way.

[Hurricane78]

I would never hire a manager of such a failed company. To me they are the archetype PHBs. ^^

A developer/designer/grunt however... I bet after the shitty time he wants nothing more, that to finally work on something where he can freely state all the errors of management, that were ignored in the old company and that were so obvious. So if I clearly state, that in my company, I hire experts because of their expertise and that I will actually listen to them, I will get someone who really cares for the project, has much expertise on the risks of failing, and is motivated to finally get something that he really loves done.

Because in the end, making each and everyone of the team love what he/she's doing because they know that their work is significant and valuable, and first getting the respect, before expecting people to follow you, is what really counts.

So I can really imagine a "low-level" guy from a failed project having learned more than one from a successful project. :)
But usually, I prefer to test this person myself, and make my own image, instead of judging him on something that I know nearly nothing about.

Madden NFL 96

[EWAdams]

One case in which the grunts got off better than the management.

drivers and passengers

[Anonymous Coward]

It's all about the driver-to-passengers ratio.

Passengers - people who show up, work their "normal" hours, get stuff done but rarely take responsibility beyond their narrow remit. They probably have average/below-average technical expertise, but somehow managed to blag their way into the role anyway. They may have a tendency to ignore a problem if nobody else has noticed it. They may work on a side-project that makes people say "ooh shiney" without really helping the team meet its true goals. They probably don't care about the company/product very much and see it as a means to an end. What ends? The paycheck, the prospect of a merit badge because they happened to be on the team with some really productive people, and perhaps some day a promotion.

Drivers - people who combine considerable skill, talent and flair to deliver consistently. If they fall behind (which may not be measured in any official capacity, but by their own personal barometer of progress), they will work extra hard to get stuff completed. If they're in a management role, they will be willing to make hard decisions and change the team or objectives around. If they're in a worker role, they will either be willing to "fix it" or to be honest with managers about the true state of affairs and will come up with alternative solutions.

If you mix too many passengers, you're in for trouble. If your leadership is dominated by passengers, you're in for a LOT of trouble. The dynamics of the team are also a factor, one team's passenger might be much more effective on another team.

Back to the original point...

[techsoldaten]

Back to the original point, I have had to hire a lot of developers in my career. I ask detailed technical questions about the projects they have been involved in, and look for failures as an example of lessons learned.

But you actually have to learn those lessons and change your ways. Stigma can follow you after the failure of a project especially if someone knows what went wrong. One person interviewed with me, he was a senior developer involved in the roll out of the original Toys-R-Us.com. For those that don't remember, it was launched in 1997-ish and had some serious performance and security problems. He seemed to be pretty straight up about the experience and explained what he would have done differently.

After taking a look at some of the projects he had worked on since, I could see that many of the original issues were still part of his developer MO. There was another e-commerce portal where he was a senior architect, I was able to view some details of other user accounts via a hack also worked on the old Toys-R-Us site. The moment I saw that I became a lot more critical and just ripped into his work. I was able to slow his sites down by just reloading pages a few thousand times. Looking at the actual markup on some pages that just failed, I noticed he had it set up to dump Oracle errors into comments on production web pages. There were issues with the quality of the images, there were these big uncompressed JPG files that were like 120 pixels square and 40k.

He claimed this was people at his agency not doing their jobs and blamed developers and designers who worked on his teams. For senior level positions, no one buys the argument that other people are causing the same problems over and over again.

M

impossible

[farble1670]

it's impossible to attribute the failure of a project to individual contributors. they might have been a contributor to the failure, or just a victim of circumstance. you won't know until you interview them, just like anyone else.

as you go up the chain, i think there's more reason to blame. it's up to a manager to assemble the right team to perform a task. if they aren't doing that, there's some fault. and on up, if the manager isn't given the authority to assemble the right team ... etc.

it's quite backward that execs carry little or no blame for failures. if there's any blame at all, it should be on them. they have ultimate authority to make whatever changes are necessary to make things work. why do failed execs make out like bandits with payoffs and future opportunities? it's called an OLD BOYS' CLUB. they protect each other, or scratch each others' backs so to say.

as a person that hires people...

[pjr.cc]

I work for a reasonably small company, but i've also been asked by several of our clients (from small to mammoth) to help with the interview process for technical types. (Im in AU by the way, so may not be pertinent outside Australia).

The fact you may have come from a catastrophic failure really doesn't matter... There maybe some idle curiosity as to how it was "at the end", but in reality nothing matters as much as being able prove that:

1) you have the skill to do the job
2) you have the right attitude
3) other people are willing to say good things about you (i.e. references) and they are believable.

There's often very little you can assume/find out about a single persons involvement in a catastrophe. If they were there to the bitter end its either because they couldn't find a new job quick enough or because they were hoping to save the company (which are opposite ends of the spectrum in terms of an employee - but it could be a million other reasons too). The point im trying to make it that its impossible to know (from an employer perspective) what the reasons might have been and they rarely give much insight anyway. To some extent, the size of the company that folded can make it easier to figure out some facts, but its rarely a developers fault. Its often management/business decisions that result in the doom of a company.

All that aside, there are some things in the industry which are "more is better" and experience is probably the prime candidate. If you've been around for the end of a company, well thats something you have to your advantage as its an experience you have that perhaps alot of your possible competitors for a job may not. Simply put, as an employer if I had someone on my team that lost their job cause of a company collapse i'd certainly like to hear his views on where my company is heading (from a developers perspective).

Thats just my humble opinion, keep in mind almost all employers have different views on almost any subject. some may view your involvement in a catastrophe as a bad thing, but i personally don't know any.

Re:as a person that hires people...

[grikdog]

What's humble about HR? Hiring decisions based on zero knowledge about tech functions is laughable hubris, although maybe things are different in Oz. My best jobs came from interviews with project leaders, not HR, and the project leaders then told HR who was getting hired.

For all the pious wingwang about "being able to prove" skill, attitude and popularity, HR couldn't hire a techie with a Tardis. What "skill" do you want to ramble on about? The ability to spin a widget in a .NET library? Or the ability to solve a problem nobody's thought of yet? Usually that involves teamwork and cooperation, but can you spot the ten guys/gals who can actually contribute in a highpressure vacuum until a solution presents itself? Sometimes, I think HR is designed to prevent synergy.

Hiring is a personal process that involves the usual human foibles. I'll admit to loving the smell of fear in an applicant. Hey, if I can deepsix this guy, my job is safe for another few months. (Purely fictional account, of course.)

The Punishment Should Fit the Crime

[curmudgeon99]

Over the years, I have worked on hundreds of IT projects. I encountered many flawed processes.

I worked for a company that had just decided to use UML and so we were forced to spend months constructing UML diagrams that mostly were a waste of time. Eventually, we made our business folks master the verbal-only [no stick men] use case model and that worked.

I worked on another project where the business people were so involved they made technology decisons and were even standing over the backs of developers ordering 'for' or 'while' loops. (Not to me, thankfully).

I've also worked on perfectly tuned agile teams that had a tight PM daily accountability in standups, and that was stressful but also tremendously productive.

Let The Punishment Fit the Crime

Project fails because business interfered? Hold the head of the business team responsible.

Project fails because the software is buggy? Hold the head of QA accountable. Also maybe the architect or lead developer, who of course will be only too glad to point out the sloppy developer who did the work.

Project fails because the design is stupid or flawed in some other way? Hold the designers accountable.

So, I hope you see my point: if you were part of a project or product that became infamous--your punishment should fit your crime. If you were only a grunt developer implementing a design blessed by the architect and tech lead and designed by the business folks--then hell no, you should not also be accountable. You were doing your job. The junior developer can honestly say that but only if that developer's superiors are being held accountable.

So, if you're the original developer of AIG's Credit-Default Swap software, I would not hold you accountable for the damage done by those "financial instruments" (another name for a stick you would use to dig peanuts out of shit). The architects of this software and the business folks who designed it should be held accountable.)

Re:The Punishment Should Fit the Crime

[farble1670]

it's hard enough to prove guilt in a court of law. suggesting that project failure is going to fit neatly into one of the categories you mentioned is silly, let alone that you will be able to arrive at some objective truth about the reasons.

Re:The Punishment Should Fit the Crime

[curmudgeon99]

Who said anything about proof? No manager needs proof of anything to fire someone. A manager just needs suspicion. But really, I was explaining why it was ludicrous for any junior developer to stand up, among an ocean of peers and say, "I'm the one. I wrote the Credit-Default-Swap logic that became the standard, and I didn't know what the hell I was doing." Unlikely as such a confession is, the confession of guilt is misguided. In this case, it seems clear to me that no authority equals no guilt. Only those in positions of authority deserve to have their careers destroyed, lives ruined, their images burned in effigy, students in college programming classes hearing about it, making that junior CDS coder into a little Satan in his or her cubicle. I think the architect should wear the red suit, horns and pointy tail.

Re:The Punishment Should Fit the Crime

[Anonymous Coward]

Project fails because the software is buggy? Hold the head of QA accountable.

Kindly fuck off. QA didn't write the bugs. QA is not accountable for anything other unless they failed to dilligently search for defects.

Love,

Your QA team.

PS: Fuck you ^ 2 if the development team is late delivering and test time is cut to meet the schedule.

maybe a little too stereotypical

[tommeke100]

This sounds a little too black and white.
I'm sure projects aren't all 1-man operations (or 3- man operations for that matter) where everyone knows everything about the project.
You could very well be part of a project where your sub-project is very successful yet other parts are the deal-breakers.
For example, you could have been working on a very efficient GUI/web-interface that you could be proud of, yet the back-end guys totally f'ed up and made it unscalable.
Or you could have been working on the database-end that kicks ass, but the business logic guys bombed. Not every developer is supposed to know the status of the whole projects, sometimes you're just asked to design by contract, and that's what you do. And this doesn't necessarely means you're just a code-monkey. Like, they could just ask you to design and implement a piece of software that exposes a certain API with a couple of constraints you need to comply to, but everything behind it is your responability. THis doesn't mean you know the overall status of the project.

If the guy has the right credentials, I would just ask what he did on the project, why he thinks it failed, etc...
a lesson lived is a lesson learned!

Re:maybe a little too stereotypical

[Gorobei]

Quite agree on the sub-project thing. I usually just ask the people involved if what they are doing is reusable or special-case. If it's useful, go for it, but if it's gonna get lost in the noise, just get out.

Last year I got called into a meeting with a bunch of users who had somehow got five programmers lined up to write a really stupid bit of infrastructure (think bat-shit insane replication of bat-shit insane current workflow.) I cancelled it on the spot by telling the poor programmers to go find something useful to do. The users complained, but now I've got five productive, happy programmers, and those users are annoying some other boss at some other firm.

Access Your Position, Not Your History

[LifesABeach]

"You can only negotiate from a power position." Were the words told to me by another senior level programmer when I naively ask the same question. Sometimes it's is better to be known for other things than your job history.

i worked on amiga os 2.0

[ifeelswine]

and it has haunted me to this day. i do not go outside for fear that someone will recognize me.

Don't worry ...

[damn_registrars]

Bad programming isn't always punished. And if you look at how this place is running, one might conclude bad programming is seldom, if ever, punished.

Re:Don't worry ...

[Anonymous Coward]

You got that right brother.

Why can I not find a comments page with all comments listed with a single click, and not having to manually expand compressed/hidden comments, or go to page x, y, z - page 49 to save them? I often want to grab them to read on a plane, and the user interface is so lame on all sites (political, paid subscriber, etc.) - is it some website conspiracy by their contractors?

One-click - all comments - there, easy to read, and I just put prior art into the patent-seeking companies.

Man, even the bot-detection scheme confused me with letters on other lines confusing normal text training in, say, the US, or Japan. Dumb, Dumber, Dumbest.

This problem is out of my skillset

[symbolset]

I'm an engineer. This problem requires the skills of someone trained in Human Resources.

Re:This problem is out of my skillset

[Anonymous Coward]

hehehehehehehehehe.

I post anonymously because those spiteful mofos might fire my ass.

Re:This problem is out of my skillset

[ScrewMaster]

I'm an engineer. This problem requires the skills of someone trained in Human Resources.

Bah. Human Resources is the last place I'd turn to solve a Human Resources problem. But yeah, I take your point!

Re:Release? That's nothing

[daremonai]

I worked for two startups in a row which failed, and then joined IBM - only to be assigned to the Workplace OS project, a $2 billion fiasco.

And yet, after all that, I got the best job I ever had. I did have to convince them I wasn't some sort of carrier, though.

Re:I cant imagine Windows ME is a great career boo

[Anonymous Coward]

However, learning from the mistakes of failed projects can actually increase your value, especially if the employer wants you to speak up.

One would think so but how about going in for a operation and the doctor saying "I killed my last patient but believe me I learned from that experience and won't make that mistake again".

Re:Maybe for some employers but probably not for m

[ucanlookitup]

I tend to think most hiring managers are smart enough to know that it takes more than a few bad programmers to make a spectacular failure. Personally, as the manager, I'd ask about the project and listen carefully to the answer. It would tell me a lot about the person (perhaps more than a litany of successes). As a potential applicant, be prepared with an answer that shows you have an understanding of the whole project life cycle and not just your piece. Show that you can critically evaluate the project without resorting to name calling or finger pointing. I don't think you have to worry about it being a career ender.

The low-hanging fruit.

[westlake]

- a project that takes three years to become profitable

This notion worries me a little. Because it suggests you are satisfied with picking the low-hanging fruit. The company with deep pockets and long term goals can be a brutally effective competitor - one that just might sweep up the best features of your niche product and weave them into his own before you can gain any traction.

Re:The low-hanging fruit.

[holophrastic]

That's not what I meant. I meant that the executive able to execute the same project in less time, is the more valuable executive. If a project is going to fail anyway, the better executive will make it fail faster.

If you go into your boss...

[Anonymous Coward]

>...and refuse to do work you'll get fired for insubordination.
Or possibly for sexual harassment.

Unhireable?, Haha, they get promoted...

[hofmny]

Have they ever become unhireable?

Not at all. Instead, they move on to become development leads or even project managers, ruining even more projects and companies!

(my ex was in HR, and basically, US law forbids your old job from saying anything negative to your new employer)

Re:Unhireable?, Haha, they get promoted...

[lemur666]

(my ex was in HR, and basically, US law forbids your old job from saying anything negative to your new employer)

Nonsense. There's nothing to worry about in US law about honestly giving a bad assessment. Now, the person being slagged lawyers' on the other hand...

Mind you, overly litigious ex-employees aside, there are plenty of ways around this.

The phrases "I consider him to be someone I have worked with." , "I found he occasionally did his job." or "I found he could be counted on for a truthful answer sometimes." can work magic.

Re:Unhireable?, Haha, they get promoted...

[ivan256]

You don't have to be obtuse.

Something like "I would not want to work with that person again" is a statement about you, and cannot be mistaken as a false statement about somebody else.

The last two "clever" statements you provided, however, could be.

No excuse.

[crhylove]

I'm sorry, but there is not excuse for a bad release. Zero.

Any decent software is Open Source, and has TONS of developers examining the code. Further, as an Open Source program, there should be constant SVNs and betas for end users to test.

There is no reason for a bad release. What is this 1987 and you are Microsoft?

Ludicrous.

Re:No excuse.

[jhaygood86]

Almost all of the software I have worked on commercially has been successful, and none of it has been open source (I have worked on open source projects, just not as a job). However, I also have a manager who is a developer with an MBA (he was a developer, and he got the MBA while developing) and a project manager who knows technology. Even the requested upgrades to the legacy systems we have get done on schedule and on budget

Re:No excuse.

[ivan256]

Most (the vast majority) Open Source software never has its source code looked at by anybody but the original developer.

Re:No excuse.

[crhylove]

This is true, but for the showstoppers:

Firefox
Gimp
Pidgin
Dolphin
Open Office
Deluge

There is a lot going on, and plenty of people making constant reports and updates. As it should be.

And nobody is listening..

[Anonymous Coward]

I am experiencing the same in my company. A new guy is hired and he is on the mission to build the entire system in two weeks...we tried that before and it failed miserably. So I tried communicating it to this talented soul [who is hired without any technical interview - anyways] - and he went on shooting a few missiles my way. Now, I don't understand why people don't want to listen.

Like re-designing entire production database because they want to use a specific ORM technology or love something brand new. In my opinion - strategy based on "technology looking for a requirement" is a recipe for the disaster. Many a time we as a developer or a group either commit the same mistake or take a passive stand so we can save our own job [ I am doing the same now] - I got my small project going on [1 man army - me myself working on it], but some where in the near distance a team is going on the path that will take them to the cliff...and nobody is listening..

Consultant

[DrugCheese]

I work on a lot of projects where my clients want to go one way (the wrong way) although I plead with them to go the other. In the end they're paying me so I usually do what they want. After time they learn to compromise, mostly because of future costs ... mostly.

I have plenty of good projects with good outcomes. If you can't sell yourself or your opinions, then you'll probably be put in more positions where your better judgment tells you what you're doing is wrong.

Re:Maybe for some employers but probably not for m

[markov_chain]

I concur with the parent, I was involved with the Challenger project but all I did was make some simple gaskets so no problems with rehiring.

Re:Maybe for some employers but probably not for m

[Anonymous Coward]

But even then I'd ask you why those projects failed, and depending on your answer, this might actually make me more likely to hire you.

...

There were a lot of excellent crew on the Titanic; the crew of the Challenger disaster were not responsible for its failure. Just because you're associated with a catastrophe doesn't mean you did anything wrong.

So basically you're saying that you don't mind an office full of zombies, right?

It depends on hindsight

[ned14]

One of the biggest roles I ever worked was as head of development for the control software of the fuel and hydraulic test benches of the EuroFighter defence aircraft. The entire EuroFighter project was probably one of the biggest IT flops of the last twenty years - with at least a 25 BILLION euro overrun as well as five years late and the project still doesn't work (and likely never will). And it wasn't the engineering that went wrong, it was actually the software stuff - few realised at the outset that most of that airplane was actually software and not hardware, and they misallocated the resources accordingly from the start. For example, I was appointed as head of software development despite being just *twenty* *three* years old at the time because no one thought software was the hard part. It typically meant that the big salaries went to the hardware guys and they just got anyone they could for the software - though in fairness, they rapidly ramped up our salaries when they twigged our importance.

.

Yet because of the name recognition and the seniority of the role, it is without doubt the biggest asset on my CV (despite having also worked for ARM and having a long line of open source contributions). Companies really like names they know, and a big engineering project is perceived as being "even better" by managers and HR than a pure software project.

.

However that's today in 2009, and it wasn't always so. In 2003 I couldn't get an interview for love nor money and I think that was because there was more negative EuroFighter news in the press at the time, and I was indeed black balled for it at that time. In hindsight, with the passage of some time (and I'm sure it helps that now I'm older too), people tend to forget the bad and remember only the good.

.

Therefore my advice to you is this: even if you are working on the biggest flop of the next decade which will be talked about by everyone for years to come, remember that the pain of association only lasts a few years. It is still better for your CV in *the* *long* *run* to have worked on a really famous disaster (and to show you have worked on anything e.g. open source competently since) than to have worked a serious of non-descript successes.

.

I guess that's celebrity culture for you, but maybe also a touch of the prodigal son. Interviews and job hiring as just as fraught with insecurity and anxiety for the managers (indeed probably more so) than for the prospective employee. I certainly always found during the hiring process that I worried about how person X would fit into my team, whether their colourful private life might be a boon or a problem, whether and how much they are telling lies or leaving things out etc. Someone who is slightly famous and/or has evidence of having publicly gone through the wringer is probably a safer bet than someone whose background could be entirely faked - after all, I as a manager don't have the time to extensively fact check an interviewee's CV for truth.

.

Hope that helps and good luck in the future. By the way, in the long run forming your own business is definitely the way - it's much more of a challenge, you reap what you sow directly, and best of all you get to mostly work on what you want when you want with whom you want.

.

Cheers,

Niall

Re:I cant imagine Windows ME is a great career boo

[Hognoxious]

There's a big difference between killing and failing to save.

It's not the stigma, it's the stink

[heironymous]

Projects almost never fail for technical reasons. Pretty much everyone knows this, so I wouldn't worry too much about programmers being stigmatized from working on a failed project.

However, you should worry about the effects on yourself. Toxic environments can warp your perspective, your work ethic, and your love for the craft. Engineers need to be optimists, and cynicism will creep into you if you work for a messed-up company.

re: grammar

[story645]

He's just using parenthesis instead of parenthetical commas, so maybe he wants the stylistic effect of parenthesis, and sometimes those parenthesis save a sentence from having a host of commas and therefore being really hard to follow.

Re:Maybe for some employers but probably not for m

[PK_ERTW]

the crew of the Challenger disaster

If you are that involved in a project that failed in such a spectacular fasion, I suspect you are not putting anything on your resume.

A current C.V. is one of the least of your new set of problems.

PK

I worked for MER and C

[Anonymous Coward]

In each country where I have worked there has been a financial clusterfuck of monumental proportions.

Do you think I am really that important or would you be more willing to think it was just a coincidence?

Project/personal success only equate for leaders

[drew_eckhardt]

As team lead with staffing control and sufficient resources, you're personally responsible for the project.

Without enough resources, quantifiable partial success (maybe internal use and a few external alpha customers before money runs out) is your duty.

Otherwise, project success is at best something you can influence.

When you're good you'll accomplish notable things (radical performance improvements, patents, the best test environment you've seen with the lowest cost to find and fix bugs, novel external data structures) on almost any project (the notable exception is being stuck with whatever comes up next on the SCRUM burn-down list) and influence co-workers up, down, and side-ways in the org chart so they'll provide positive references.

What happened to an individual project as a whole isn't relevant, although being exposed to both successes (cradle to grave full-life cycle experience) and failures (better to learn from other people's mistakes than to make them first hand when you're responsible) is something to look for in candidates.

Just get a job in the UK's Public Sector

[DevLifeRant]

The public sector in the UK has a track record of failed projects. All they seem to want is developers who are used to such hardship and bad practice so they can take them on and not rock the boat. devliferant.blogspot.com has lot's of background information on this subject.