Why Developers Get Fired(itmanagement.earthweb.com)
itmanagement.earthweb.com
Why Developers Get Fired
http://itmanagement.earthweb.com/features/article.php/3839981/Why-Developers-Get-Fired.htm
20 comments
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.
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.
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?
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?
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.
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.
'weekly velocity' is the Agile expression for the number of high-quality man hours a person or team can be expected to actually produce.
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...
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...
> How do you make pre-commit vetting of code quality scale
Use distributed version control, and work on your next patch while waiting on review of your first. Even if you can't use it officially, you can use it locally: http://spyced.blogspot.com/2009/06/patch-oriented-developmen...
Use distributed version control, and work on your next patch while waiting on review of your first. Even if you can't use it officially, you can use it locally: http://spyced.blogspot.com/2009/06/patch-oriented-developmen...
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.
>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.
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.
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.
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!)
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.
Negativity gets people fired more than anything else. If it's true, it inevitably reflects on the managers. If not, well, the complainer is blaming others for what are probably his own problems. In both cases, it impacts the entire team, which is where the real damage happens.
Negativity gets people fired more than anything else. If it's true, it inevitably reflects on the managers. If not, well, the complainer is blaming others for what are probably his own problems. In both cases, it impacts the entire team, which is where the real damage happens.
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.
Also, if you're generating a bunch of good code and solving hard problems, people are going to notice you.
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.
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.
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.
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.
Maybe you're right, but upper management knows what are the critical applications and those who deliver fixes and improvements to those apps, will shine. This happens at big companies too (at least it does in AutoZone, my current work place), perhaps this is the exception to the rule, but it's what I've experienced.
Your results should speak for themselves but not in the way an engineer might think. Your technical expertise or the virtuosity of your software is not relevant to the business at large (though it is relevant to the business at hand).
What matters is the value that your work delivers to the business. If you write software that consistently delivers value and has significantly positive impact, it should speak for you. If you work on unimportant projects with little or no benefit or impact to the company, it will not help you, and you should also wonder why you're wasting your time on it anyways. Certainly when it comes time for the business to execute cost-cutting measures like in times like these, they will wonder why.
Then there's politics which can render all of the above moot. It's unfortunate, but that's how humanity rolls. If you work in a large company and wonder how some totally useless and unimportant projects that cost the business money hand over fist manage to survive even during tough times like these, well, now you know why.
What matters is the value that your work delivers to the business. If you write software that consistently delivers value and has significantly positive impact, it should speak for you. If you work on unimportant projects with little or no benefit or impact to the company, it will not help you, and you should also wonder why you're wasting your time on it anyways. Certainly when it comes time for the business to execute cost-cutting measures like in times like these, they will wonder why.
Then there's politics which can render all of the above moot. It's unfortunate, but that's how humanity rolls. If you work in a large company and wonder how some totally useless and unimportant projects that cost the business money hand over fist manage to survive even during tough times like these, well, now you know why.
I call this the "degrees of separation" rule. How far is your job from the point where the company makes money. Sales and accounts receivable (as much as we like to make fun of them) are pretty high on the totem pole. After you get past the politics, they tend to enjoy some form of stability. And it's not uncommon to hear of a salesman/woman work 10 years in the same company.
On the other hand if your job is writing software for a widget company than it better be vital part of every widget. You don't want to be the guy that is made redundant because what they assumed was good work contributed nothing to the overall business.
On the other hand if your job is writing software for a widget company than it better be vital part of every widget. You don't want to be the guy that is made redundant because what they assumed was good work contributed nothing to the overall business.
Or what if the good work you did contributed quite positively to the business, but in a way that wasn't directly connected via the dots back to you. For instance, what if you write a kick-ass piece of software that doubles the sales team's efficiency, but no manager ever gets farther than congratulating the sales team on a miraculous performance because the believe nothing behind the scenes changed. What if they continue to believe this, in spite of your appeals that it was your software that helped the sales force along?
A company managed this way is a company that will have little left but a sales and marketing force eventually, because the executive staff will have pruned everyone else as being redundant. Arguably, this could happen even in a shrinkwrapped software company, where the software isn't just a vital part of the business, it is the only part.
Hire someone incompetent, or see someone incompetent get hired above you, you may find you'll be made "redundant" even if you are the last developer hacking on the product. It is employment at the will of your employer, and nothing says they can't terminate you due to their own incompetence.
A company managed this way is a company that will have little left but a sales and marketing force eventually, because the executive staff will have pruned everyone else as being redundant. Arguably, this could happen even in a shrinkwrapped software company, where the software isn't just a vital part of the business, it is the only part.
Hire someone incompetent, or see someone incompetent get hired above you, you may find you'll be made "redundant" even if you are the last developer hacking on the product. It is employment at the will of your employer, and nothing says they can't terminate you due to their own incompetence.
Results don't always matter. politics can factor in, too. :(
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.