
Why Developers Get Fired - TheElder
http://itmanagement.earthweb.com/features/article.php/3839981/Why-Developers-Get-Fired.htm
======
azanar
Ugh. I severely dislike articles like this, because they lend legitimacy to a
pay-by-politics form of reward and punishment.

Each of the three reasons he lists can be traced back to manipulation of one's
political image: you fail to take the absolute most cynical view that
everyone's failures from above will come crashing down on you, and cover your
ass accordingly; you fail to wave your achievements around, because you
believe someone is actively paying attention or gives a crap about anything
you're doing; or you fail to appropriately hide your boredom and lack of
motivation by plodding on at the same rate as everyone else like the good cog
that you are.

None of these have anything to do with actually doing anything. You could be
accomplishing next to nothing, and still be able to hit all of these points;
you could be working miracles in code, and manage to flunk all three and get
thrown out on your ass. They are all the departmental equivalent of spin
control, and are the sign of a broken department and quite possibly a broken
company. It is a sign that people have stopped caring about doing things in
favor of appearing as though they are doing things. This sort of thing is a
slow death of a thousand cuts to an organization, and will result in people
getting fired anyway, when the lack of revenues from people not getting
anything done force staffing cuts anyway.

I understand that a lot of companies are run like this; I don't need to be
reminded about how the real world works, and especially not with the usual
condescension. I'm not trying to convince myself or anyone else that the
corporate world is not stacked this way; what I am doing is yelling in the
same way Dan Pink did about motivation by incentive that this sort of ass-
covering doesn't work. It results in an organization that will steadily decay
from the inside, and will ultimately end up shafting the same people who
thought they could save themselves by just hunkering down and playing the
political game. All these people bought was a little more time cower in fear,
and convince themselves this will all blow over if they just behave. It
doesn't work, and people need to stop convincing themselves, for the sake of
themselves, their coworkers, and the organizations they purport to work for,
that it does.

Life is too short, peoples' time and effort is too valuable, to put up with
asinine wealth tarpits like this. No one, not even the person cowering, is
benefited in the long-term in any way by this sort of attitude.

Ugh, I need to go take a walk to unwind.

------
alexgartrell
Cover Your Ass Folder - If you need one of these, you need to quit. If there
are issues, man up and get them resolved. Don't just hide away the details
until some big angry manager knocks on your door.

Need to Brag - Work for a company that does code reviews/inspection. It's a)
great for the quality of the code and b) great for assigning merit to the
people who've earned it, do that.

~~~
warfangle
What do you do when your team thinks code reviews are not worth the time they
take for a majority of the commits?

At my previous job, code reviews were required foreverything more complicated
than a CSS tweak: change the DOM significantly, and a UI dev has to Ok it.
Change a piece of JS, and the UI definitely needs to ok it. Change a piece of
the mid-tier, and you can bet your ass that it's vetted before it's comitted -
often by additional developers that don't even work on the mid tier.

Granted, this was a corporate b2b app for a fairly large company. Everything
needed to be vetted, and sometimes it splled delays (hey, can you do my code
review so I can test on staging? Ok, in 15 minutes then..).

At my current position on a small team, we do optional weekly code reviews: do
something interesting or that you want feedback on, bring it up in the weekly.

How do you make pre-commit vetting of code quality scale, especially on a low
headcount, high velocity team?

Without impacting the weekly velocity numbers that people not involved in said
code reviews are used to seeing?

~~~
moe
_How do you make pre-commit vetting of code quality scale, especially on a low
headcount, high velocity team?_

Make sure to hire only top notch. Vetting goes faster when everybody knows
what they are doing (yes, this is sort of a "duh!").

 _Without impacting the weekly velocity numbers that people not involved in
said code reviews are used to seeing?_

No idea what "weekly velocity" is or who is making that number up in your
company but I suggest to start measuring in months and quarters for a tangible
idea of effectiveness. Forest, Trees.

~~~
queensnake
'weekly velocity' is the Agile expression for the number of high-quality man
hours a person or team can be expected to actually produce.

~~~
moe
_high-quality man hours ... expected to actually produce_

So, a bit like these velocity points in Pivotal Tracker, only... even more
detached from reality?

I'll let you in on why measuring mostly anything related to code in weeks is
wrong: It promotes short-term thinking and code debt, not unlike what we have
seen in the banking blowup.

Yes, there are classes of tasks that can be solved in a week-timeframe. But
those are not normally the ones that make or break your project.

For a small, contrived example: You can hire a low-skilled worker to provision
new servers. You can then measure how many servers that person gets done per
week.

Or you can hire a high-skilled worker to build infrastructure for provisioning
servers with a mouseclick. This will take months. But once finished you have
saved yourself an ongoing full-time salary and can assign the high-skilled
worker to other tasks.

Good luck determining that high-skilled workers "weekly velocity", though...

------
intellectronica
I find it somewhat amusing that anyone would be interested in writing or
reading this sort of advice. Getting fired is not something you should avoid.
Any relationship that isn't working is better off coming to an end, for both
sides. If you're stuck doing work you don't like and for some reason didn't
find yet the motivation to move on, be glad that your manager did you the
favour.

~~~
ShabbyDoo
>Getting fired is not something you should avoid.

In the long-term, you are right. However, you are much better off sucking it
up for a couple of months while looking for your next job. You avoid the been-
fired stigma, and you have much better negotiating power with your next
employer.

------
drp
The article didn't mention this, but in my experience, the person who most
negatively affects the team's chemistry is the first one out. Producing bad
code (or not enough/none at all) or breaking things is sure to destroy your
connection to the team, but so is being overly negative, distracting or
intrusive.

~~~
herval
in my past experience, those linger on for veeeery long time. The first ones
out are usually the ones who speak up when things are wrong, and the ones who
get involved in too many aspects/things (the Rule of Visibility applies: first
seen, first fired!)

------
rubentopo
I strongly disagree with his "developers need to brag" section...in my
experience, those developers that brag the most are those whose code is a
negative contribution (pardon the oxymoron).

Also, if you're generating a bunch of good code and solving hard problems,
people are going to notice you.

~~~
drp
Maybe "brag" is too strong of a word, but it all depends on what kind of
company you work for. Keeping quiet pretty much ensures that only your peers
and possibly your tech lead will know what quality and quantity of work you're
churning out, unless they decide to share.

If you're working for a small company where the CEO sifts through source
control to see what's changing, producing good code will certainly suffice,
but if you work in a large company with a multi-tiered management structure,
keeping quiet only pushes the responsibility to promote your work to someone
else - and you can't always rely on that happening.

~~~
azanar
_If you're working for a small company where the CEO sifts through source
control to see what's changing, producing good code will certainly suffice,
but if you work in a large company with a multi-tiered management structure,
keeping quiet only pushes the responsibility to promote your work to someone
else - and you can't always rely on that happening._

In the cases where you can't rely on that happening, then that means no one
else gives a damn about what you are doing. This would be very odd in a multi-
tiered organization, since often times development projects are decreed onto
the programming staff by strategic direction committees. If no one cares, the
project is make-work; warning. Either it is going to contribute next to no
value to the organization, or no one has a clue what value it is going to
contribute. Either way, you'll be hard pressed to convince everyone who needs
to be convinced what you are doing is that valuable.

To borrow a PG idea, to everyone above you in the management hierarchy, you
are represented -- as an aggregate of the rest of your group -- by either your
lead or manager. A lot of the interaction between your group and the rest of
the company will be done by them. They _need_ to be your advocate; if they're
not doing that, then your entire group is getting shafted, and need to find a
better advocate.

------
sown
Results don't always matter. politics can factor in, too. :(

