Why Developers Get Fired 535
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. "
a better idea (Score:2, Insightful)
Re:From My Simpleton Point of View (Score:5, Insightful)
It depends, if said developer is completing the most work, but also one of the highest paid, then the next round of down sizing it goes something like this:
PHB: 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?
Re:From My Simpleton Point of View (Score:2, Insightful)
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).
Metrics are useful to prove a point, but are not the point.
Programming is simple (Score:2, Insightful)
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.
The hardest part of software development has little to do with computers, but everything to do with people.
Re:From My Simpleton Point of View (Score:5, Insightful)
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.
Got a crappy product, market more; Sued for incompetence? Create a press release.
Yes, this crap bothers me.
Bragging (Score:5, Insightful)
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.
Managers like when you make their jobs easier.
You Have A Lot To Learn (Score:5, Insightful)
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.
Re:a better idea (Score:5, Insightful)
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.
Re:From My Simpleton Point of View (Score:3, Insightful)
If you do a good job, you will be rewarded.
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 than your coworkers' 10 off-by-ones taking 5 minutes each. If you ignore office politics, you'll be on the wrong end of it.
Re:From My Simpleton Point of View (Score:5, Insightful)
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?
In a word, no. The reason they can't do it is that measuring the value of n programmers on a team would require reading and understanding all of their code. Managers have too much other work.
You need to make the job of the people around you easier. That includes your manager.
It's tragic... (Score:5, Insightful)
Re:From My Simpleton Point of View (Score:5, Insightful)
--Jesus freaking Christ, can't companies do employee evaluations at all?--
I appears that they can't. I haven't seen one in a long time that even had a clue as to who did what. It's just whether you are liked or not and not what results you produce.
Nothing can save you! Maybe? (Score:3, Insightful)
Been there. Seen that.
Re:From My Simpleton Point of View (Score:5, Insightful)
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.
Has anyone noticed... (Score:5, Insightful)
...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?
Re:From My Simpleton Point of View (Score:3, Insightful)
Re:a better idea (Score:2, Insightful)
I agree, give your coworker sufficient warnings. Ask him if he needs help with techniques, maybe a little mentoring. Only rat somebody out as a last resort.
I'm a manager... (Score:4, Insightful)
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.
Re:From My Simpleton Point of View (Score:3, Insightful)
As you say, you are young. Apparently also naive about the ways of the world.
The problem with your theory is that you need to manage the boss's impression of you before they go into the "who do we get rid of" decision making process.
Once they've decided to get rid of you, no amount of waving statistics at them is going to stop it.
1. It makes them look weak.
2. It makes them look stupid.
3. There's a risk of you taking revenge on them for wanting to get rid of you (especially if you have access to production systems.)
There's also a practical problem with your suggestion.
At my workplace, we put one "defect" in the database for each major feature. That "defect" may represent 30 pages of requirements document. We create the defect because we have a rule of all source control submissions having an associated defect.
If I get that "defect" assigned to me, and complete it successfully, I show one closed "defect."
If, however, I screw it all up, the testers are going to write 20 defects against the work, and they're all going to be assigned to me. I ultimately fix them all and have 21 closed defects.
Who's the better developer - the guy who closed one defect or the guy who closed twenty-one?
Re:From My Simpleton Point of View (Score:4, Insightful)
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).
Re:From My Simpleton Point of View (Score:2, Insightful)
Re:Doesn't help. (Score:3, Insightful)
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 objective, send an email to the stakeholders: "Today we rolled out system xyz, thanks to the hard work and dedication of the team!", something like that. And make sure you are in a position to send that mail! If you are the project manager, it'll likely be ok. If you have someone above you who is also closely involved with your work, check with them first. And if they prefer to handle such announcements, make sure they do it!
Re:My solution to not being fired. (Score:3, Insightful)
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 existing, he needs to do something valuable. And these people are not in any way easily replaceable, nor is there any political controversy over the person.
I have been both, I quit 2 places where I became irreplaceable.
Re:getting fired vs laid off (Score:5, Insightful)
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.
Re:Doesn't help. (Score:1, Insightful)
Of all the places I've worked, 100% of the small outfits (5-15 people) have had rampant cutthroat office politics with a heaping side of subterfuge. 100% of the large outfits (multi-department) have had a refreshing lack of politics and subterfuge.
Re:It's tragic... (Score:1, Insightful)
Integrity is the reason I'm currently interviewing. I made it clear that I would work through whatever garbage came up, but that I would not look the other way or lie when my self-respect was on the line. After being at the company for years, moving teams, and witnessing extremely unethical actions by my manager I refused to be part of it. Its quite clear that they are trying to force me out, but I'm happily trying to leave instead. The company has gone downhill since engineering became political and already many of the best people have left. The actions of management create a lot of disdain and, just in the last week, were outright discriminatory by breaking the equal employment opportunity act.
Integrity is a critical asset to an engineer and disrespect is the surest way to lose your best people.
Show UI stuff (Score:5, Insightful)
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.
Re:Has anyone noticed... (Score:3, Insightful)
Re:From My Simpleton Point of View (Score:5, Insightful)
Re:Bragging (Score:5, Insightful)
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.
Toxic mindset. (Score:3, Insightful)
Disclaimer: I am a lead dev/team leader.
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.
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.
Re:From My Simpleton Point of View (Score:5, Insightful)
we could higher two new grads and an intern for the same amount. They'd be at least that productive right?
And nine women could have a baby in 1 month.
Re:From My Simpleton Point of View (Score:4, Insightful)
Re:Bragging (Score:4, Insightful)
Re:From My Simpleton Point of View (Score:3, Insightful)
99% of programmers think they're good, and that they deliver. What if you're wrong? Might help to market yourself a bit better just in case you're not as good as you think you are.
Re:You Have A Lot To Learn (Score:3, Insightful)
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.
Translation: we want to make you feel valued rather than pay you more, and are preparing to guilt the hell out of you when you realize how much you're worth and get a better offer somewhere else.
I absolutely hate it when the bosses tell me how valuable I am, because it is utterly meaningless bullshit unless it comes in the form of increased pay or increased vacation or other tangibles--being sent on a course I'm interested in, etc. Words from the mouth of a human being are worth nothing, and they'll still push you over the side in a moment when it happens to appear convenient for them to do so.
Re:From My Simpleton Point of View (Score:3, Insightful)
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.
Re:You Have A Lot To Learn (Score:2, Insightful)
I was going to make a more spiteful reply, but I think you touched on what I wanted to say, so I'll forgo the scorn and just come out and say it.
Programming ...is an art. That's what we want to tell management and they don't want to hear. They see a product come out, and that's what the programmer develops, and that product can be made by anyone. The product will exist whether it's produced by a crack team of programmers, the very best, or whether it's produced by Joe's Codeshack & Office Supplies Warehouse.
What a programmer wants to believe is that the artistry is valuable to the company. I have never worked on a company project, but I have to imagine that if you're just another guy in the line, no, it never will be. If you're a manager and can drive the course of even part of the project, then maybe; otherwise, you are filling a part that is by its very design supposed to be interchangeable. Programming is by its very nature solving a problem; there is a way to solve the problem (or there isn't), and it WILL be solved, whether it's by one person in one day or ten people in twenty. You may be better than them, but it's all relative, so you're trying to argue marginal value to people that don't care. In the meantime you're someone who was hired to be a gear, never rose above it, and is crying because you're a cog in the machine.
What makes a person valuable to the company? Crap, I don't know, ask someone with more experience. But what makes you LESS valuable to the company as a whole?
* Being faceless to everyone who makes the decisions (being friends with people on the same level doesn't help much)
* Not reporting what you did
* Not reporting what you CAN and CAN'T do
* Not explaining things others will need to know
* Creating more problems by being incompatable with the others
* Being an angsty, emo "Management is PAIN" type who truly believes and acts like the company is supposed to be psychic and always pick the best of the litter even when the "best of the litter" (ie, yourself) just sits in their cubicle being oblivious to the world and thinking they're such a blasted genius and that nobody else could do it.
America seems to have a very educated, very angsty caste of people whom the last point describes too clearly. "If you do your job well, you will be rewarded" is rather cliche; if you are VALUABLE, you will be rewarded. I don't know where the meme that keeping your head down and nose to the grindstone is more valuable than contributing meaningfully to the company--or the country--came from, but it's crap. If you want them to care, make them care. Don't just keep a wish in your heart like a teenager with a crush and hope someday middle management will suddenly admit she loved you all along and come on let's retire to Hawaii and you can write all of our code and we'll never be angry at you again or make you work overtime and have a donut and some coffee.
I guess I didn't manage to get rid of the spiteful commentary after all. Oh well.
Disclaimer: I'm young, unemployed, have never been a manager, but golly gee whiz, some people act like children.
Generic Advice, agreement and disagreement. (Score:4, Insightful)
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
Re:You Have A Lot To Learn (Score:3, Insightful)
Re:From My Simpleton Point of View (Score:4, Insightful)
Re:From My Simpleton Point of View (Score:2, Insightful)
Having just spent the last decade working for large multinationals (IBM, EDS, Fujitsu, etc) I have to say that in effect most employee evaluations come down to "work harder not smarter". It is much easier to measure and rate how many hours an employee has worked, than to evaluate in detail the quality of their work.
This is pretty much how it goes down in my part of IBM:
- Once a year, the senior guys for your area get together to finalise the ratings for all of the plebs
- They have a basic set of criteria that are key, such as "productive utilisation" (= did said pleb work themselves nearly to death for the greater glory of the company), "give back" (= how much unpaid extra work did the pleb do for the company), and compliance with corporate regulations (no trivial event in the monsterous bureaucracy of IBM)
- Occasionally, a manager will try to get some recognition for one of their direct reports who has delivered quality work. Typically they are unable to quantify this in 30 seconds or less to the satisfaction of the rest of the managers present.
- As you can imagine, with 200 people to evaluate not much time gets spent on each pleb
Which is a long way of responding to your question "can't companies do employee evaluations at all?" with the answer "no, not really".
Re:From My Simpleton Point of View (Score:5, Insightful)
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.
Re:From My Simpleton Point of View (Score:3, Insightful)
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 you. Mine was an idiot who couldn't meet deadlines for a development cycle and methodology he himself implemented. So he needed someone to blame. When he fired me I yelled at him for a good 15 minutes. I've never talked to anyone I've worked for like that in my life. When he tried to say he was going to escort me out of the office I yelled at him some more. I demanded access to my computer, cleared out everything and when he tried to give me lip for having access to personal accounts I yelled at him some more. I saw him on Facebook that morning. I said goodbye to everyone and walked out on my own.
I absolutely refuse to play games with people. I am not going to work for a company where I can't just do my job and be appreciated. If some jerk wants to fire me because he's got problems that's not on me. I ended up with a new job about 2 months later.
Re:Don't leave onsite support empty handed (Score:1, Insightful)
You paid him to work 9-5, right? You didn't pay him to be available evenings. You cannot expect him or anyone else to be available evenings or any other time they are not being paid for. Okay, so he left early one day. Who hasn't? Do you let a job interfere with the rest of your life? Do you live to work, or work to live? If you have your priorities straight, you work to live.
Make it work in their environment? The onus was on you to either replicate the environment in house, or to fly him there so he could do the work on-site,with any custom controls or other libraries the project relied on; not fire him because you made half-assed guesses.
Who's the asshole here in this situation? Seems to me it is you, not the "VB guy".
Re:Bragging (Score:1, Insightful)
Many people don't like the idea that they could go away, and the company would do just fine without them for some time. They feel like they have more job security if there is some pain when they are gone, so they (consciously or subconsciously) make that the norm.
Re:Generic Advice, agreement and disagreement. (Score:2, Insightful)
Actually, he doesn't sound like a sociopath.
He sounds like a pretty bright guy who has figured out how to play the business game and survive amongst all the sociopaths, narcissists, malingerers, and general d-bags without becoming one himself.
The fact is that he sounds very much like the kind of person I'd either like to be working with or for.
I never really put it all into words, but it occurred to me while I was reading his post that this is more or less how I manage to get along.
I am just about the only person in my organization who will look the head of IT in the eye and said "Dude, are you smoking crack?". Ive often found that when the the crack quotient seems high, it's due to some external (to the IT department) force, be it customer driven or from another department. Either way, there's usually very little that can be done to stop the stupid once it gains momentum... but you can often harness and direct it to some degree to end up in a semi-sane place.
Really, there are three things I'd add to Don's rules:
1) Know / Understand your bosses real objectives, and know / understand THEIR bosses real objective, and always keep them in mind. It will help you keep your sanity and it will make you better able to have their backs. This is especially helpful if your boss doesn't understand this rule and is oblivious to the real goals and objectives of their higher-ups. If this is the case, try and being them around. It will benefit them greatly and that will trickle down to you.
2) Try not to care more about your task/assignment/job than your company / chain of command. I fall victim to this one all the time, but am trying to get better. Don kind of said it already - it was the part about screaming/shouting/jumping up and down on stacks of printouts while the issue was open, but accepting it once the issue was closed/decided.
In simple terms, part of what makes a star programmer good is that they often really give a damn about what they're doing. Properly applied, this is what makes you much more productive than the run of the mill developer, but if you don't keep it in check - applying it at the wrong place/time or you're not aware of the higher-ups real objectives as stated previously, then caring too much can lead you astray.
3a) Never cook fish in the lunchroom microwave: It really stinks up the place and everyone will hate you.
3b) Never pop popcorn in the lunchroom microwave: It tends to bring productivity to a screeching halt as everyone takes a break to go make some for themselves. Also, anyone in the office who is on a diet will hate you.
Re:Bragging (Score:3, Insightful)
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.
Of course you can't. Because you live in a country where if you were to suddenly find yourself out of a job, you wouldn't be completely fucked. Here in the land of opportunity (to get fucked), your job is quite literally your life. No employment? No health insurance. No house payments. No car. No food. It's incredible (incredibly sad, that is) how rapidly you can descend from "successful" to "eating out of garbage cans" in this country.
Re:From My Simpleton Point of View (Score:2, Insightful)
You point out an interesting problem that many call centers face though. There isn't always a perfect correlation between the number of calls a given agent takes vs. his ability to service the customer. If he is manning a queue that is responsible for first-level or tier 1 support, his job may be quite simple, requiring him to do some very basic troubleshooting in an effort to appropriately route or escalate the customer's issue, while solving the very basic or simple problems so that the other departments have more time to troubleshoot more detailed issues. In that case, he will take a higher number of calls than agents in other queues simply because the nature of his calls means they will be shorter, but he can still effectively service the customer at the same time.
Even in longer staffed queues, an experienced agent may take more calls because he is able to resolve issues quicker than a newer agent in the same queue, and quite possibly provide the customer with a better experience than they would have had with a different agent. On the same token, someone who takes fewer, longer calls in a queue that typically sees quick, short calls may catch the eyes of management because of their metrics, but they may be a better agent who spends a couple of extra minutes per call ensuring that an issue is resolved, and preventing additional calls for the customer. Yet they will probably be fired/laid off purely because of their metrics, although the metrics don't accurately reflect their ability to service the customer.
It's because of things like this that management often incorrectly bases their decisions off of incorrect or incomplete data, because they simply draw incorrect conclusions or don't take a deep enough look at an employee to find out why their metrics differ from the baseline that they have (often arbitrarily) set. And it's not just limited to call centers. I've seen managers do the same thing for developers, attempting to judge what kind of employee they are purely based on superficial things like how many lines of code they produce or how many SVN commits they do, instead of judging them by the actual quality of their work.
Things like serious attention to detail, efficient production of code, and being able to quickly and easily resolve complex problems in a few lines of code or a few commits is MUCH more important than writing lines and lines of redundant code or recommitting your project 10 times before you finally get it right. Problem is, the best way to measure that is to have someone managing you who actually understands what you are doing, and that sadly just doesn't happen as often as it needs to.