Posted
by
Soulskillon Sunday September 20, 2009 @01:42PM
from the failure-to-meet-tps-report-quota dept.

jammag writes "Other coders get canned — but never you, right? From a developer who's now a manager (and who admits to being fired himself) comes the inside story on how the Big Ax might sneak up on you. To prevent it, he recommends some strategic bragging, keeping a CYA (Cover Your ...) folder to document your efforts, and making sure that your talent isn't frittered away so much that even your most mediocre colleagues look good. "

After reading this article, it sure puts things into perspective about how I was raised. It seems that Eric Spiegel and I have very different perspectives and work ethic. If you do a good job, you will be rewarded. Three things that will do nothing for you are bitching, bragging and blaming. Avoid them like the plague -- that is, of course, unless they're listed in your job description.

However, some people truly have their heads buried in the sand (or their code).

Yes, imagine the shock and horror that you would see on people's faces if I spent my time doing what I'm getting paid to do: develop code. Yes, I'm young. No, I've never been fired but I've been "hired then unhired" out of college because of a poor job environment in the locale of my origin. No matter, plenty of jobs were out there for me.

Spiegel claims he's fired people. I wonder how he would have chosen people if he saw through an employee's thinly veiled attempts to make himself look better? Or if he knew that employee spent time trying to cover his or her own ass instead of -- you know -- just get work done? These points aren't addressed in the blog.

So for those of you reading this, I will offer you an alternative to what the blog suggests. I imagine most developers (even agile developers) have a system for tracking completed requirements and also for fixing reported errors/bugs. If you spend your time chewing up those outstanding items and forget about all this near-Machiavellian bullshit manipulation Spiegel is proposing then you've got nothing to worry about. If your manager wants to fire you, just pull up the numbers if he or she hasn't already and show them. You can't fire a developer that's leading in resolutions and completed requirements. It's that simple. Skip the drama and get to work.

Alex Trebek: "Hmmm, Bob is making over $X. I see he's the most productive, but we could higher two new grads and an intern for the same amount. They'd be at least that productive right?"Contestant: "What is the final nail on a project's coffin, Alex?" Alex Trebek: "Right you are!"Contestant: "I'll stay in the same category and take 'Stupid Managers' for $800." Alex Trebek: "The answer is: Half your team has been fired and your manager has moved software modules to be developed in this country." Contestant: "What is India?" Alex Trebek: "Correct again!"

1. Board level manager's meeting.2. [New person] is eager to prove themselves and suggests [bad idea] from [trade magazine].3. Nobody else in the meeting has had enough time to read something other than [trade magazine], and so believe [bad idea] is a good idea.4. Vote passes unanimously.5. Middle management, who has read something other than [trade magazine] tries to politely tell [new person] that [bad idea] won't work.6. [new person] ignores cries of pain and suffering, stiffens their resolve to ram [bad idea] down organization's throat, backed by the full power of the board.7. Middle management stalls as long as possible, warning everyone of the impending apocalypse.7a. Except you and anyone on the lower rungs.7b. Those who do find out, bail from the company like rats from a sinking ship.8. Costs suddenly rise, due to a sudden vaccum of experienced workers and a drop in efficiency. The effort can no longer be stalled.9. A week later, you're asked to fill out some forms and update the knowledge base.10. You're so focused on your job, you think nothing of it.10a. Alternate: Your manager is kind and says something to you.11. Regardless, you're still let go before you can swim to another piece of floatsam.12. Upper management cries victory -- everything costs less now!13. Middle management develops a drinking habit, but says nothing.14. The new people hired in [Country X] think everyone over here is a bunch of idiots and drunks.

China for me. I built a team of top notch loyal coders (many with 10 years+ service). We got acquired and the new owners wanted me to (and the CEO) to move development to China. The CEO said "you'll have to get rid of me and the CTO before that will happen". Their answer was to the effect of "your terms are acceptable to us". A year and a half later, development is in China, the local team down to 25% of original strength (with the rest looking) and the product has been written off by every analyst. They bought the company for the technology (and the most signficant technology has been written off by the company, which is now rebuilding that part in a language that is not capable of getting the same result).

Software development is not a commodity - software businesses that treat it like one may reduce costs, but obliterate the value in the product.

The thing is, a preponderance of managers are stupid, and it's getting _worse_ not better, so these kinds of decisions are being made more and more often.

Not so much stupid as not thinking everything through. Most American jobs were designed with interchangable workers. In fields like software development, talent isn't a recognisable commodity to the boards of directors. Want to cut development costs? Dump the expensive American coders with interchangeable $OFFSHORE_NATION coders. They're cheaper.

Since talent isn't looked at, from the beancounters' viewpoint, outsourcing is win-win. And they're the first to bitch when the $OFFSHORE_NATION coders have problems understanding the initial design of the application.

India is way too expensive. How you can possibly compete by making software in India? You should really consider moving development to east Asia.

It's interesting to read in the Indian English-speaking newspapers how people are bemoaning the problem of "their" industry being outsourced to cheaper countries (China and Malaysia, for example). The quality won't be as good, they say, and the communications pathways are too long.

Just because something is a bad decision doesn't mean someone won't make it.

If we take bad decisions to mean illogical decisions then you can't mitigate against them, simple as that. They come out of the blue and no amount of hand waving is gonna change the decision. And if you think presenting evidence of your good work will turn the tables then you don't understand the meaning off 'illogical'. So like the GP says, just do your job and you'll be fine . . .

For the first 9 months, no. But from then on its possible, just impregnate 1 woman a month. And wait for 9 months time(which may or may not be acceptable depending on the case) and 9 women would have a baby in a month. All you have to do is forget the first nine months, and hope that you will survive the first 9 months without loosing too much.

I agree that good metrics are the way to go, but be careful on what you measure, no tracking system is complete enough to follow all relevant parameters (and if it were, it will be such a pain to have it up to date that it would be useless).

Unfortunately no amount of merit is going to save you if your PHB has a chip on his shoulder, thinks you are incurably rude, or otherwise has a motivation to get rid of you. He will do everything he can to find an excuse to be rid of you if he wants to.

Being a nerd is unfortunately no excuse to duck out on social graces or office politics.

His advice seems to be "If you are a great programmer, you still have to get out and market". Jesus freaking Christ, can't companies do employee evaluations at all? It is like these guys think marketing is the best way to do everything.

In other words, help your manager do their job instead of you doing yours.

That is why you do employee evaluations, to see the good, the bad and the ugly. All your talking about is self-promotion in the guise of productivity. It may make your managers job easier but it is has nothing to do with productivity, competence or effectiveness.

In other words, help your manager do their job instead of you doing yours.

Not instead of your job, but in addition to it. Overall, an organization where people go the extra mile to help those they work with tends to be a lot more productive than one where people stick to doing their formal jobs and nothing else.

And yes, this also means helping your co-workers and the people you manage (if you're a manager).

I got fired a couple months ago from a corporate company doing development. The idiot manager who fired me put in the signed document of reasons I was fired two days of me not being there. Turns out I was there. Both days. Subversion logs prove it. He also lied about doing reviews with me. The whole document had zero to do with results. Seeing as how I met all my deadlines and helped other employees out it's hard to lie about that.

It all boils down to whether or not your immediate supervisor likes yo

in the end, the people who are going to make decisions are people and most of them have no idea if a Programmer is a good or bad one. If you don't make sure people know what you are contributing you are asking for it. Especially if you have to work in a place with a low ethical standard where people will take credit for your work without even a second thought.

The larger the corporation the less results actually matter. What REALLY matters at review time is what people, especially managers other than your own, think you've done. It doesn't matter if you've written 100,000 lines of bug free code if you've been quietly flying under the radar and getting your job done you will be rated lower than the person who speaks up at every meeting, sends emails to everyone in sight but really produces very little. Microsoft is especially bad for this, as you can tell by their products. What counts is how well you market yourself to the team and senior managers, not your results.

Evaluations. What a wonderful tool. I'm a Software Engineer at a large defense contractor. A few years ago on my evaluation, for "Future Position" I put "International Space Station" as a joke. It was there for three years before anyone noticed.

Spiegel claims he's fired people. I wonder how he would have chosen people if he saw through an employee's thinly veiled attempts to make himself look better? Or if he knew that employee spent time trying to cover his or her own ass instead of -- you know -- just get work done? These points aren't addressed in the blog.

I think it's a matter of semantics. Bragging as a thin attempt to make yourself look better when you suck is worthless. Managers are not stupid.

However, managers are busy. In most organizations, too busy to do too much work managing their employees. Business bragging simply means to inform your boss when you do something good. Don't lie. Don't stretch the truth. Just provide information the boss might be too busy to notice.

It doesn't even really need to be bragging. Every few days or so, I'll run in to one of my managers and have a conversation along the lines of:

Me: "Oh hey, I finished $module for $client. Did you want me to do anything else on that project?"Manager: "Nah, just give the exe to $tester so they can test it, and then I'll have $supportPerson install it at the client site. By the way, have you had a chance to work on $otherModule yet?"Me: "It's been on my back burner for a couple weeks. I've toyed with a few ideas on how to implement it, but haven't coded it yet. Why, is it becoming urgent?"Manager: "I was hoping to have it ready to go by the end of next week."Me: "Alright. I need to finish $module3 first as it's due this Friday, and then I'll get on that one. I should be able to have it done by late this week or early next if I hit a snag."Manager: "Great, thank you."

Great, now my manager knows I'm getting projects done and knows what I'm currently working on, and now I know what from my mile long to-do list needs to get done sooner rather than later and can prioritize accordingly. No bragging required. A few weeks after I started this habit, I even had the CEO (who, in my small company, is one of the ones I have these chats with) call me in to his office and thank me for keeping them in the loop.

Why does it seem, that the entirety of American business is set up to fall to pieces if employees take more than a few days vacation? Here (Denmark) we are actually entitled (by law) to have five weeks vacation a year, and we can take up to three of them together as summer vacation. This year I even combined it with some comp-time, and took 29 days in one go. And that didn't cause any major problems, since my manager knew he had to plan for it (it did cause him a spot of bother when I quit a week after coming back from vacation - but that's besides the point). I just truly can't imagine working in an environment where you are expected to put in long days (standard workweek around here is 37 hours, give-or-take) without compensation and not even get to take proper vacations...

Why does it seem, that the entirety of American business is set up to fall to pieces if employees take more than a few days vacation?

Because in any given organization, 10% of the employees are doing 90% of the actual work. The other 90% are goofing off, taking long lunches, surfing the web, talking to co-workers, ordering from catalogs, playing crosswords/solitaire/minesweeper/sudoku, posting to Slashdot, etc. If those 10% leave for a few days, everything does fall to pieces.

When you're employed, try living below your means and saving the surplus. Amazing how much less of a panic losing your job is when you have $10-20K socked away in a bank account. Now you have several months cushion to search for another job; you don't have to leap at the first thing that turns up, no matter how bad. You don't have to panic, and you don't have to live in fear at your current job that you might get laid-off unexpectedly.

Seriously, it's too useful to have a cash reserve for emergencies. Start

You can't fire a developer that's leading in resolutions and completed requirements. It's that simple. Skip the drama and get to work.

Sure you can.

In a really large company or a public service sector job you may have a Human Resources department with policies that offer some protection, but otherwise you manager can fire you just because he or she feels like it. Did your original job offer letter mention anything about employment being "at will"? if so you can be fired for any reason or none at all.

Or just not give a shit. I'm a good programmer, and I deliver. If my manager for some idiotic reason or another wishes to fire me, I'm happy to find a new job where I'll be appreciated without political bullshit.

Actually, there's no specific contract term necessary in most states. If you work in the US, the presumption is that you are at will. Now, there are some exceptions [wikipedia.org], but those are usually contracted (read: hidden disclaimer) around anyway. Unless you're in a union job (Unions? In my tech industry?) You can get fired for basically anything, since it's not always a lucrative or an easy case to prove. Generally the cost of the litigation is less than finding a new job, anyway.

...but otherwise you (sic) manager can fire you just because he or she feels like it.

Perhaps in the US this is true but elsewhere many countries have laws that prevent this. They can choose not to renew your contract but otherwise they can only fire you for a valid reasons, like failure to do your job, company downsizing etc. If you sack them without a valid reason you can get sued for unfair dismissal.

You must be wet behind the ears. None of what is mentioned in TFA really states you have to take these steps to the extreme. While you never came out and wrote it, you sure make the implication that the writer of the article is telling you to do this.

Hard work only gets you so far. And guess what else? Hard work may never get you promoted. You go on to make another point on the other absolute end, that if you're a hard worker, you must be the top producer in your company. You can work hard and still fail at what you're doing. This is why people are sometimes oblivious. I've worked with a few people like this. They do work really hard. The work that they do, however isn't usually the best and no amount of training can help them out. Some of them just never got it. Some of them were the type of people who thought that their way was the best way to do things when it clearly wasn't. In either case, they worked hard but were eventually let go because of how their work turned out.

It never hurts to chat yourself up casually every now and then. You can do this a number of different ways. I'm a supervisor where I work. All of the supervisor's used to here that the president of the company thought we were doing the bare minimum for our jobs. That we were just good little foot soldiers. I realized part of the problem was that my immediate manager didn't really have an idea of what the fuck I did every day. All he knew was that I helped my team to produce a lot of work that generated a lot of profit.

So one day I took about an hour to sit down and type out a list of projects my team needs to address. These were mostly "as we encounter them" issues. Items where if we take half an hour, an hour even, we could figure out a few things out to help us out in the future. I send this list to my boss with updates about once a month now. It gives him an idea of what else I'm doing and how quickly these tasks are getting done. It also allows him to more easily give me help when I need it.

So what was the net effect of me doing that besides a little extra help from the boss? The president of the company has personally told me on several occasions that he views me as a very valuable employee. That I have a bright future there and that he would rather not ever see me go.

And honestly, if you don't spend a modicum amount of time trying to cover your ass, you may get blind-sided one day. You rail against it, but then in your last paragraph you even cite an example of how to cover your ass. Not everyone has access to raw data to pull up, so some tracking on their end might be necessary. It doesn't take a lot of time to do this.

What you said is dead on, but the point you didn't explicitly make, but probably intended to, is that what you are doing there is valuable. It's not just fluff. Your management needs and wants that kind of communication, and when you provide it for them, they love it. When they have to suck it out of you, they hate it. When they never feel like they have a clear picture of what's going on, it's a source of stress for them, and when you communicate well, it lowers their stress levels.

Why don't they just trust you? Because they've had people working for them before who communicated poorly on purpose, because they *weren't getting anything done*. And they've had good people working for them who kept quiet about what they were doing because they didn't like the plan, and wanted to go in a different direction and present it as a fait accompli. And, so often, that sort of thing doesn't work out. So if you also communicate poorly, they're going to tend to assume your situation is the same. It doesn't matter how many poor communicators they've had working for them who actually got stuff done. They remember the times they've been burned, not the times they haven't.

I work for a smaller company, and the smaller the companies are, the truer the words are. Still, I have no illusions based on what I've been told. I've made it very clear to them that my employment is a two way street. If they're not willing to show me some loyalty, I won't show them any. Even in the down trodden economy I could find work in the same field rather quickly. While I get dicked around from time to time, I've managed to mitigate some of that. Besides, you will get dicked around no matter where y

Wrong. If the boss thinks you do a good job. Unfortunately, the amount of brainpower used when debugging can't really be measured, and wildly varies based on outside factors, like your API working correctly, the quality of the bug report, the type of bug (ever had one of those that only come out when you gave up looking for it?) etc.

Bragging and blaming will let the boss know about those factors, so he may appreciate your 3 fixed heisenbugs where you had to hunt down the reporter who was on vacation more th

Oh, my dear fellow, replacing the "bug tracking system selected by the VP to generate pretty charts" is often a social art form of the highest importance and the greatest difficulty. And the manager often has tremendous power to game the system, by deciding what the engineer's priority list or success criteria should be.

And getting the code into that source control and bug tracking system is often a huge project that "the bottom line" doesn't justify, at least in smaller environments. This is especially the

>> However, some people truly have their heads buried in the sand (or their code).

> Yes, imagine the shock and horror that you would see on people's faces if I spent my time doing what I'm getting paid to do: develop code.> I imagine most developers[...] have a system for tracking completed requirements and also for fixing reported errors/bugs.

I'd put this not under developing, but programming. Developing code encompasses more than those facts, which you can extract from a commit log.Also, the c

I had a manager once I didn't get along with, and our 1-on-1 meetings weren't very pleasant. I actually got up and walked-out on one, when she told me "this isn't an 8 to 4 job, you know". The previous night, I'd actually been up until midnight working on a particularly difficult problem.

But when I thought about it, I was being the ass-- not her. How could she have known I was up until midnight working? I was working from home. I didn't send out any emails saying I was working that late. At that time, our company didn't have timecards, and even if it had this was the next day, long before the timecard would have been submitted.

Anyway, the next day I apologized, and since then I've always managed to find some excuse to send out an email (CCing my management) whenever I'm working extra late, just so they're aware that it's happening. Since then I haven't had any problems.

The moral of the story: don't "brag" brag. Be smart about it. Managers can't judge you based on things they don't know about. This article basically says the same thing. I know we're all geeks and we hate actually talking to people, but the time you spend communicating to your co-workers is golden, slack on whatever else you want, but never hesitate to pop off an email.

The vast majority of my job in a management capacity is to translate from geek to suit and back again. The guy who owns my company, my direct boss, is not technically minded. The man has fantastic ideas, but couldn't write a lick of code or install a server to save his life.

The company is lucky to have someone like me. Many do not. And in the absence of an interpreter, you bet your ass that closing a lot of tickets in the bug tracker will mean dick when it comes to convincing your boss who doesn't read the bug tracker to not fire you. And frankly, pulling out the metrics to show that you're valuable is exactly the kind of strategic bragging you're arguing against.

You can fire a developer who is leading in resolutions and completed requirements. It happens every day. The job is not just to make sure that you're working your butt off, but that your boss knows it. Help them to make informed decisions. It may suck, but you know what, that's life.

After reading this article, it sure puts things into perspective about how I was raised. It seems that Eric Spiegel and I have very different perspectives and work ethic. If you do a good job, you will be rewarded.

You clearly need to get out in the world a little more. What happens when, not if, your boss doesn't see things quite your way? What happens when your hard work feels threatening to your co-workers, who may not work quite so hard, and leads them to do all kinds of stuff to undermine you. You're not working in splendid isolation with some fairy-tale objective criteria, assessed by equally mythical perfectly fair assessors, for success. You're in reality land, and while working hard is one thing to do--sometimes it's not even a good thing--it's far from the only one.

One example of "working hard" that's not good to do is when you, through your diligence, pile more technical debt onto a project that's already got unsustainably much of it. Another is working hard to accomplish something that's illegal and/or unethical.

This is kinda vicious but my strategy is if someone else's coding isn't good enough or they make massive mistakes, I don't just let it fly. You don't have to be their boss, you only have to be working on the same project as them because you're the one putting up with missing object methods and bad documentation and poorly written code. Tell em to rewrite it before you can use it and correct them and generally let them know that it has to be acceptable or they get to fix it. If anyone asks about project d

This is kinda vicious but my strategy is if someone else's coding isn't good enough or they make massive mistakes, I don't just let it fly. You don't have to be their boss, you only have to be working on the same project as them because you're the one putting up with missing object methods and bad documentation and poorly written code. Tell em to rewrite it before you can use it and correct them and generally let them know that it has to be acceptable or they get to fix it. If anyone asks about project delays, don't hesitate to throw them under the bus and accurately report that they were the reason for the delay because their code didn't work. Soon it'll become really obvious that they're the inferior employee who should be replaced if possible.

Or, you could just come off looking like a jerk to both your team and to your boss. You're on a team for a reason: to work together, not complain about how bad someone else's code (or any other work, for that matter) is.

If you are a team member and not in a lead role, you're not in a position to decide what's acceptable and what's not. And you'd be foolish to believe that you are in that position.

Yes, you should let the other person know that improvement is needed, but "throwing them under the bus" isn't the way to do it.

I wasn't fired because I didn't toot my horn. I got fired because I knew the system too well -- and when upper management was told about this, specifically about a distinct lack of guidance in their security policies and documentation, they canned me. The reason developers get fired is either for the same reason most people get fired -- namely that they piss off the wrong person and they find someone in power to make their dream come true (and someone else's nightmare to begin), -OR- they learn too much about the system and not enough about politics and get caught by surprise when they try to implement a change that is a political hotbed. My last job: In-house developer doing network/system administration, deployment, and integration tasks.

Very often, developing stuff (especially in-house) has conflicting political goals, which are distinct from the design goals. Each team wants a certain piece of the pie and wants assurances they are "indespensible". Well, the problem is that in every project people need to work together and so there is always some overlap or need for integration -- which is fought tooth and nail because once things are integrated and made redundant (as business should be) -- people stop being "indepensible". So those that are slightly more politically aware find ways to strategically delay the project or insert superfluous technical considerations. And should a really good developer see this and figure out a way to convince others (by the strength of his/her design argument) -- this person will very quickly find a surprise pink slip for some random reason.

Keeping your job as a developer is as dependent on your ability to design well as it is on your ability to know when to duck.

I got laid off in 2002 specifically because I was vocal and did my best to try and make for a better work environment. The problem was that management was TOO political. The parent poster is 100% accurate. After that I learned, never to be vocal. Give simple opinions and never give negative feedback, or try not to do so.

I got laid off in 2002 specifically because I was vocal and did my best to try and make for a better work environment.

What do you mean by being vocal? If you are constantly suggesting changes to the way people work, people may start to see you as a troublemaker even if your suggestions are good. I've seen the type: young, over-eager and making many good suggestions... to the wrong people. Going over their bosses' heads. Upstaging senior teammates. Even claiming credit for team efforts. That sort of thing.

On the other hand... celebrate success! That is what the article is on about. When your team completes an obj

Programming is relatively simple compared to the complexity of human interaction. While we might consider it lame that software development is heavily influenced by purely social factors, it doesn't change the fact that we live in a social world. Too many developers think of themselves as the lone console cowboy, churning out brilliant code few others can understand. Too many developers think if they simply write good code, the rest falls into place.

Pro tip: maintain a list of everything you do: bugs you've closed, features you've added, projects you've planned, servers you've upgraded, or whatever else you've worked on. The next time your boss asks if you've been busy, you'll be glad to have a precise and detailed answer.

And the corollary: Prove you've been busy, but not efficiently busy.
I got laid off in 2001 from a software dev position. My co-workers on the same project escaped the ax. Why? Because I made the mistake of finishing my work (and finishing it well) before my co-workers. When it came time to tighten the belt, I was on the bench waiting for my next assignment...they were still languishing at wrapping up what they didn't finish. Guess who got RIF'd?

I've been a software engineer at the company I'm at for about 7 years now. Was in technical support before that (enterprise level development support).

Here's my solution to not being fired. Make yourself damn good at solving the difficult customer problems no one else can solve. Do it so that customers and executives at your own company request you by name (executives at a customer knowing you by name can help here too). Yes, it makes life somewhat miserable when those ugly ass escalations come in, but you know what, when customers and company exeuctives ask for you by name because you did a great job solving problem xyz 3 months ago and saved a multi-million dollar deal, middle management will think twice about being the one to tell company executives, uhh, that person was fired last month.

Screw making deadlines, I miss deadlines all the time and haven't been fired yet. Why? Because instead of working toward my deadlines I'm saving multi-million dollar deals that could get lost because of other people's incompetence:). It's a great way for job security, and I love troubleshooting, even if the escalations are a pain in the ass.

--Here's my solution to not being fired. Make yourself damn good at solving the difficult customer problems no one else can solve. Do it so that customers and executives at your own company request you by name (executives at a customer knowing you by name can help here too).--

This may work but it pisses off upper management. They will get jealous of you being called instead of them. That's the other way it can go in smaller outfits.

Honestly, in the end, if your company needs to fire people for any reason, sooner or later, nothing you can do will prevent it 100%.

The company I work for now had cuts during the recession. A member of our team, a "star" developer (actually, probably easily among the top developers in the world). Quite well known, could do the job of 10, amazing management capabilities, deep insights in the business, etc. Not a small company either, douzens of thousands of developers.

He had abilities no one else had, and without him things would have gone sour, because there was no one in the -world- good enough to replace him. But management saw fit to get rid of him anyway, since obviously he was rather expensive (cost effective though, but they only looked at the absolute numbers).

After he left, it took an -army- to replace him, and even then, outages occured, some data was lost, and to this day, still, he hadn't truly been "replaced" and things aren't going so well. Now obviously thats a problem with the company to depend so much on someone, and thats a big bad thing, but point is: he was irreplaceable, everyone loved him, clients knew him by name (well, technically, a big chunk of the world does), and poof he went anyway.

There's a difference between being fired and laid off. Even then, there's no silver bullet, but there're many many things you can do to stack the odds in your favor. I think what I do is one thing good to have the your repertoire.

There are 2 types here:
The irreplaceable - these people become a burden on any company at the end. Unless that person is one of the founders, it is better to have replaceable parts than ultra specialized person. You would probably think twice when buying a mechanical item that would need any single part to be specially manufactured, with wait time of 4 months.

The highly valuable, but replaceable - these will be held in a company till the end. Why? Because the value does not come from the person just exi

Ah yes, diving catch engineering. I actually like your way of doing it, because you're doing a big save for a problem someone else caused, rather than allowing a bad situation to fester and then being a hero at the last minute (right?). But really, they shouldn't have you in the critical path if that's your work philosophy. Being a good troubleshooter who can pull peoples' asses out of the fire when things go wrong is valuable in itself.

I like that term. Yup, dive catching describes it well, and right, it's not about letting it fail, or letting it fester, but just getting in and getting the job done. In the end, myself, and some of the more astute observers might be able to figure out the root cause, but there's no reason to draw attention to it. Even those that I jokingly call incompetent aren't really incompetent, they just have a different skill set, and mine and theirs complement each other very well.

Good coders get canned all the time. Often it's because they have and exercise integrity which equates to shitting on the kitchen floor in today's corporate environments. The advice in the article is entertaining but probably not practical. If you're on the chopping block there is little you can do to mitigate the outcome. It really depends on your *perceived* value to the organization. People are too smart and narcissistic to change their perception of you based on your bragging. Bragging used to work back when most people with power in an organization had absolutely no idea about technology. If I walk into work and start bragging about my work and skills today, my peers and superiors are just going to be annoyed and think I'm a jerk. Bragging about the team's successes, and how the current team is a cohesive unit, is better advice that may save not only your butt, but your entire team's as well.

Too true. I work at an IT consulting firm and my boss pretty much told me flat out that I'm going to be in some serious shit if I don't start dragging my feet to bill clients more hours. Apparently I'm too productive and don't over bill. I called my boss to ask him a question about a task I was going for a client one day - 10 minute phone call (maybe 6 minutes of it being the task at hand) and he bills the client for an hour for "assisting me". Now I'm just waiting for the economy to pick up so I can ge

I work at an IT consulting firm and my boss pretty much told me flat out that I'm going to be in some serious shit if I don't start dragging my feet to bill clients more hours. Apparently I'm too productive and don't over bill.

This is the main reason IT consultants have such a bad rep. We get paid big bucks and even then we're expected to screw clients. I've seen consultants where lawyers are saints in comparison.

I'm a former programmer, now a manager. Recently, we had to cut some dead wood. I went through all my employees and
asked myself, "Would I hire this person?" (I didn't hire any of them in the first place). In many cases, the answer was no. Either they shouldn't
have been hired in the first place (previous manager was borderline incompetent), they didn't work out as well as expected, or they had attitude/personal
problems that outweighed their contributions.

Speaking from previous experience, nothing can save you if your management team believes that the cure for all their department's woes can be found overseas. If slashing the bottom line is their primary concern, I don't think there's anything you can do. Short of moving to Cebu or Bangalore.

...the horrible degree of corruption implied by just about every post under this article?

The essential implication seems to be that your longevity in employment has absolutely nothing to do with your actual work. Rather, it has everything to do with someone else's perception of you, and said perception doesn't necessarily need to have any honest or factual relationship with your work output whatsoever.

If this is the case, I seriously wonder how much longer contemporary human society can last. Is it really so completely, unsparingly rotten out there these days?

Part of my job involved finding coding mistakes made by our overseas contractors. To put it simply, they were sloppy and didn't seem to care. When I left, the quality issue hadn't been resolved...
and they were the ones who wound up getting my job!

The essential implication seems to be that your longevity in employment has absolutely nothing to do with your actual work.

Nah it just sounds like the advice of someone who sucks at what they do: and by sucks, I mean not constantly working to improve. I've seen this: people don't realize they suck and don't realize that others don't, [wikipedia.org] and therefore assume the only way to get ahead is by politics and dirty tricks... even when it's not. Of course, I'm sure sometimes it is, but if so, it's time to find someplace else to work. Managers firing their resources (especially valuable ones) is more detrimental to them than to their for

Selection bias. First, no one here is posting saying "I have an extremely fair employer who works closely with me in a very just way to ensure that I do my job well, and in turn I work very hard to please my employer so that my employment is safe and full of opportunity." The people responding here are ones with stories to share about how they got fired, and people who are fired rarely blame themselves or consider it to be justified.

Second, geeks in general seem prey to misconceptions about how the world should operate in ways that are very logical and rational and (invariably) beneficial to them. Their collisions with real life tend to lead to anecdotes posted on./ about how much they suffer at the hands of a cruel, cruel world.

The same employees who complain about being fired despite their productivity would have left at the first offer of a higher salary anyway. It's true that businesses have the advantage over individual workers since they can afford to waste an enormous amount of human capital, but individual workers have their role in the universal corruption too.

"For those who donâ(TM)t see it coming".....here in New Zealand would earn the employer a death sentence in Employment court (well, a large settlement anyway).

NZ law states broadly 2 key points: That there is a relationship of good faith between employer and employee, and that both parties act in a fair way.

examples from both sides:

For the employer:
- Theft by an employee is grounds is grounds for instant dismissal
- A drop in income that requires a restructuring process when some employees might be shed.

For the employee:
- A drop of productivity can be due to various reasons. The employer must determine what those reason are. And instigate a prodedure policy known by both parties. The No.1 rule is "no surprises" to the employee.
- Numerous instances of Case Law indicate the employer must act to prove in a fair way they are right(they are the ones with the resources). For example , allowing one employee to arrive late but then enforce it on another first time late person would show lack of process and earn punitive penalties in employment court.

- Heads: They are too pedantic about development practices in an organization focused on shorter term results.- Tails: They are too focused on shorter term results in an organization focused on pedantic engineering.- Uneven performance - productivity that tends to spike around review time but lag in the between months. Many managers aren't naive about this.- Embattling the lead developer. Some developers take a personal disliking to the lead for whatever reason, and take a

sometimes you do nothing at all that gets you fired. Many times I was laid off because the company wasn't earning enough money and the companies I worked for would fire IT staff first. Usually with a 90% turn around in 4 years.

Last two programming jobs I had I got fired because I ran up health insurance rates and got sick too much. Turns out the stress of working too hard gave me high blood pressure and other illnesses and I even developed schizoaffective disorder. When management learned about my illnesses

If your boss likes you, he will set easy goals. If he doesn't like you, he will set unrealistic goals. You can be the hardest worker in the place, but getting "results" is an arbitrary and meaningless phrase, entirely dictated by the whims of your manager.

My question is why do good developers, that are talented get laid off?

Because they earn more money. This goes double for if they have lots of experience. I know someone who's almost 60 and they kept incompetent people in the department but laid him off (when the last 3 months before he was laid off he was working 14 hour days to make up all the work that wasn't being done by the others in the same department) because he made too much money.

I got laid off once when the old boss died, and the new boss thought I was too tight with the old "administration". After I was gone, the lay offs were done. Go figure.

Later I got fired from Microsoft. Microsoft's corporate culture is about a grading curve. No matter how good your team is, no matter how successful they are, some get "A"s, some "C"s, some "D"s, and some Fail. You get an "A" and (at the time) you could be rich beyond your dreams. You fail, and you are asked to leave.

This makes life at work brutal, because helping others be productive doesn't get you a great grade unless you can clearly claim credit. Furthermore, making use of someone else's advances in an obvious way is going to count for them, so you don't do it. Bottom line, it makes a very productive environment cause deadwood gets tossed. But if you survive a few years, you do so because you can develop an "in" with those that grade you, and you increasingly get grades partly (but almost never solely) because of who likes you.

The bottom line is that your first year is absolutely critical. You are almost never going to get an "A" cause you don't have the "In"s for that. But you can't fall down in visibility or you are toast.

Now it happened that my Dad died the first year I was working there. It was a long and drawn out process with cancer. I took several trips during the year to be with him when things got bad. And for the funeral. And I found it tough to talk to people. Then I had a meeting with my group leader, a guy who laughed nearly constantly but paradoxically had no sense of humor what so ever. We met in a conference room outside the doors of the building, and I was told to simply leave. My stuff would be sent to me.

After being tossed out the door, the project lead told me, "My dad died, and it didn't hurt my productivity."

The bottom line is that I MIGHT have avoided this had I spent more time talking up and down the chain of command about what I was going through. I could have taken leave until I had my head back together. The environment made it tough to get any support from people around me at work, but I might have worked harder at that. But it is also possible that some situations just are not going to be within your ability to manage.

In my experience, bosses want to see things. Working user interfaces. They want to be able to play with products as soon as possible.

Bad strategy:- Choose the best tools for the job even if this is not one the company used for previous projects- Write solid, reliable, secure, clean, flexible, scalable, optimized and tested foundations.- Tell your boss that you spent 80% of the time allowed to the project writing quality code, but there's nothing to look at yet.- Sequentially and methodically write every part of the project, with a crappy UI just for testing- Polish the UI, replace images with nice-looking ones- Profit?

Rewarding strategy:- Stick with the same old tools: no need to justify nor to demonstrate anything.- Write crappy foundations. Hard-code data as much as possible. You just need to get a working test case.- Work on the UI. Make it look cool even if it barely works. Add every possible button as soon as possible, even if they don't trigger any action. Looking at the interface is the way most people will judge the completion of the project.- Connect the UI to the crappy foundations. You can easily show how much progress you did on the project.- Rewrite the foundations so that they can deal with real data.- The project is ready for production, you made the deadline.- Plugging security holes, rewriting everything so that it can handle the real load, and fixing bugs will be dealt with after the deadline.- Who cares about the quality of the code ? It's closed source anyway.

In the same vein, I remember something from a previous workplace. I wrote a very nifty piece of software, technically some of the best stuff I ever did for that company, asked my boss to come around so that he could take a look. His only remark, after I was "I like the look of it, but could you make the green a shade more yellowish? then it would be really great". I was quite pissed off for the rest of the day somehow

Non-IT people generally really don't care about how code works (or even if it work at all), what matters is that they have something shiny to look at.

Unfortunately, the document neglects to mention bad management counter-tactics. I just watched an engineer get guided away from everything productive he did into a "primary focus" of a project to re-write the manager's old project, saw the manager completely ruin the work because it wasn't written exactly the way the manager had done it (which was dangerous stuff, and the point of the project), and block the engineer from closing any other work orders until the primary project was done. The result was that it _killed_ the engineer's productivity on all those little pie charts and project ticket reports, and got him "encouraged to resign". And it kept around that old piece of dirty garbage code, which only that manager knows how to maintain.

I'd love to go directly after the manager for this, but it's hard. The manager knows how to play the paperwork game and the blame game and I'm not even from his company. It won't help the engineer much: I've written him recommendations and am trying to guide him to better work, but the field is still not hiring much.

The first thing that struck me about that article was that I had (blissfully) forgotten how horrible, corrupt and incompetent a lot of companies out there are. I agree with the overall thrust of his article, although I'd phrase it as "Be good at what you do, be proud of what you achieve, and act accordingly". That said, I just want to take a few points from the article. This guy has been working in some toxic environments, and it's done bad things to his world view.

Why wouldn't you see this one coming? Well, you might be thinking the missed deadlines are not your fault. Your excuses may include "the design was bad" or "the deadlines are not realistic" or "they are making me code in Java and I am a.NET expert."
Guess what? Excuses don't matter. Results matter.

If the design was bad, well, I'm the Lead, so I had approval on the design, and I had to sell it to the stakeholders, and convince myself that it was possible with the available resources. If it wasn't, that was my fault, and I shouldn't be trying to blame them for it.

In a project with a scheduled deadline and fixed scope (i.e., non-agile), if you don't have historical information to work from, the only sensible way to estimate the effort is to ask the developers who are going to implement it. If I didn't ask them, and set deadlines willy-nilly, and then they couldn't meet them because I missed a whole chunk of complexity out, then that was my fault, and I shouldn't be trying to blame them for it. (The corollary being that, if I did ask them and they didn't meet their own estimates, you bet they've got some talking to do, because I'm about to have a very painful meeting...)

I wouldn't ask a French translator to translate Italian for me and bitch about it if they were slow ("Hey, they both have Latin roots..."). Similarly, if I ask you to do something that I know you've got a learning curve on, and I don't make space for that in the project, and don't give you the assistance you need to learn it, guess what...yep, that's my fault. It's only your fault if you didn't get off your ass and learn it (although I do expect you to be able to learn quickly—you're supposed to be a professional developer, after all.)

The job of the manager is to make sure that you're doing your best possible work, and to make sure that all impediments to that are removed. It is not to make ludicrous promises and then blame you when they can't be delivered. If you find yourself working under such a waste of space, move as soon as is practical. If you are such a manager, please consider growing some stones and taking the responsibility you're being paid to take.

You have to promote your work. Yes, I mean brag.

That might work in the U.S.A. Good luck with that in, say, New Zealand [wikipedia.org].

If you are doing good work, then you'll receive kudos when the software is implemented. And if the implementation is not a success? This is tricky because you don't want to play the blame game in public.

The "in public" is very telling. You don't want to play the blame game at all.

Seriously, people. If you're a good developer, for pity's sake don't work in companies like this. They're rotting your mind.

First. Managing people and dealing with corporate politics is something I actually know a thing or two about, developing, not so much. (although I've been mucking around programming things since nine-teen-seventy-something, among many other things.)

Many developers imagine themselves to be unique snowflakes, who are so much smarter and better at their jobs than anyone else could possibly ever be, again, this is something I understand. (I work in manufacturing, with engineers, toolmakers and quality people, all of whom either, are smart and know how to do things you don't, or think they do, to varying degrees.)

If you don't want to get fired remember these rules.

Don's rules for being essential, and thus not getting fired.

The better your boss is, the better these will work.

1: Remember who the boss is at all times. When it is you then act like it all times. When it is not you, remember that at all times.

1.1: Have your bosses back at all times, no matter what.

2: When your boss asks for your input give it, argue fight scream, yell explain why he or she is utterly wrong and you are right, do not pull punches.

3: Once your boss has made a decision, even if it is utterly wrong, accept it, go with it, do your best to make it work, if it is even remotely possible. If not, try your best to soften the crash landing. (Hint, sometimes your boss has made a doomed or stupid decision because someone told him he had to, or for some reason he can't explain to you, see rule 1.1)

4: Do brag, do point out when you and why you are useful and what it is you do that makes the company money, and makes your bosses life easier. These are your two primary functions as an employee. Being smart, being cool, coding/designing/solving problems etc.. That's all corollary in nature to making your employer money and making your boss happy.

5: Remember your boss may be a pointy-haired idiot, but he is your boss. (This is worth repeating.)

6: If you feel the need to stab your boss in the back, you make absolutely certain you are going to inflict a fatal wound, and you will have a new boss afterwords. Absolutely certain. (Uhm.. Please keep in mind I mean in a business/employment sense, please don't kill anyone because of what I post on/. However if you do feel the need to kill someone, it is probably better to finish the job with a single stabbing.)

7: Keep your friends close, and your enemies closer.

8: Revenge is a dish best served cold, and anonymously.

9: It is always better to avert any disaster or crisis from happening than it it to be sure you can blame it on someone else. Even if you have a chance to pin it on an enemy, or someone who is incompetent or stupid, don't stab anyone in the back unless it's a fatal wound.

10: In any workplace battle or argument, keep in mind what you stand to lose and what you stand to win, there are times when it is better to cave in and accept defeat even though you are right, than it is to win a bloody hard fought victory which will leave hard feelings on both sides for some time to come.
10.1: This rule applies even when you are smarter than the other side of the argument.
10.2: Even when they are stupid.
10.3 Yes this means you.

11: In terms of internal office conflicts do not forget to give those people you are fighting with a face saving way out no matter how wrong they are, no matter how stupid they are, they are people to, if you glory in explaining and demonstrating how smart you are at their expense today, then someday in the future they will be the one's preparing you a nice cold dish full of anonymous revenge.

Finally: Don't be a dick, don't be controversial for no good reason, like I said several times above, if I am your boss, make absolutely certain that I know you have my back at all times whether I'm right or wrong. [1] If you do this then I will fight for you to the bitter end and do everything but demand whoever wants you

1) To the person who makes the hiring decision, make it clear that the person sucks up more money than they make the company. Make it a pure business decision.

2) Make it easy - very few people enjoy firing people. It is not only confrontational, but it often means admitting you were wrong in hiring in the first place. Give your boss as much of an emotional out as possible.

3) Have the meeting where you solidly and without malice make your case. If your boss isn't going to fire the guy right then and there, b

No, it's not fair today. In fact, in most states employment is "at will", which means among other things that if you aren't a member of a protected class of people (and often if you are a member of a protected class) you can be fired for any reason at any time. And therein lies a large part of the problem.

Cops and teachers both have a very significant tool to protect themselves that developers as a rule lack: a union. Yes, I know, a lot of folks think of union regs as pile of bureaucratic BS, and unions as