Slashdot Mirror
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?"
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.
I'm sure Windows 7 developers will still be employable after the October release.
[Insert pithy quote here]
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.
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 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.
Scientists point out problems, engineers fix them
altslashdot.org: The future of slashdot.
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. :-)
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?
Live today, because you never know what tomorrow brings
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.
Coding with assembly is like playing with Legos. Coding an application in assembly is like building a car with Legos.
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.
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.
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.
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.
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.
You want the truthiness? You can't handle the truthiness!