|
As a programmer or system administrator, you could either strive to have your fingers in every system or to isolate yourself as much as possible to become an easily-substituted cog. Advantages of the latter include being able to take vacations and not being on call, while the former means that you'd always have something to do and be very difficult to fire. Aiming for either extreme would require a conscious effort. Except for the obvious ethical considerations, what should one strive for? |
|||||||||||||||||||
|
|
I aim for systems to be autonomous. Otherwise, just when I'm really in the middle of something some system I need my fingers in will demand my attention. That's unnecessary stress and takes away time from building new things, which I enjoy far more than keeping my fingers in everything. |
|||
|
|
|
For some people I don't think there is a choice here. There are people that just don't have the skills or patience to work all over the stack and/or on many different problems at one time. There are also people out there that really don't internalize a problem well until they have wrestled it themselves or don't have the patience to code around an issue they know they could solve in another tier or application. Personally, I think that the developers that have an extremely isolated view of their piece of the puzzle do everyone a disservice by not paying enough attention to what is/can be done in the related pieces to fully realize the most efficient solution. Some people go the other way to an extreme, but the fact that they become un-fire-able is a deficiency in the organization either in keeping enough notes and backups or in not hiring enough people to keep the highly skilled people with some peers that could step in when the proverbial bus comes along. |
|||||
|
|
I personally believe that it is better to polish one skills to be easily re-employable than to dig deep into the workings of one particular organization in order to become unfirable. Jobs come and go, so to it that you represent value to many employers out there. |
|||||||||
|
|
You should NOT be Indispensable. What if all your coworkers decided to become Indispensable too! Then what! You have an disastrous non-function team. And you will hate your job and all your co-workers. You the Indispensable Guy is the Guy every hates, the Information hoarder!. You the Indispensable Guy is lousy coder, sure you think you are the best so you can do everything yourself, But if you are so great why are you so worried about being replaced?! Your Approach should be that you provide your employer with the best value for your salary, that means not only having top notch skills, but helping every one on the team become more productive as well. If your employer decides to fire you.. there will be another one who sees the value you bring and want you. |
|||||||||
|
|
I think you do yourself and your organization a disservice by being indispensable. You also do yourself a disservice by aiming to be an easily replaced cog in wheel. Strive to be the best at what you are doing. Try to understanding how it fits in the larger picture. Be generous in sharing your skills and knowledge. You will be missed when absent, but won't be a significant issue for you or your organization. If possible, try to cross-train at least one other person to do your critical task. This may be difficult if there is noone in the organization interested in doing so. It is in the organization's best interest to assist you. At least document these task well enough that someone else can do them if necessary. |
|||
|
|
|
Definitely aim to leave a clean table every day that a new colleague could pick up reasonably quickly. It's the right thing to do both for you - as you are free to pursue new ways without burdening responsibilities - and the employer, in case something tragic happens to you. However, investing in this is as much the employer's responsibility, as it is the employee's. Properly documenting stuff and developing emergency plans if you're not available is a lot of work, and the employer needs to recognize the enormous value in this and allow for the time to do it. |
|||
|
|
|
Either case you're never totally safe from being fired. Generally indispensable employees are better-paid, so consider the possibility that your company in a budget cut-off could fire this indispensable personnel and hire more affordable easily-substituted cogs. By other side if you're indispensable and you quit there are more chances that you get excellent recommendations from your former bosses for being an outstanding employee. So I'd rather being an indispensable one. Worst case scenario is getting fired for being more expensive. Getting interrupted during vacations is quite a bearable downside. |
|||||||||
|
|
Definitely don't try to be indispensable. Furthermore if you're a manager and notice that a programmer is trying to become indispensable, fire that person immediately. I ran across the advice about firing would-be indispensable programmers in The Psychology of Computer Programming. The silver edition printed the original book, and then chapter by chapter comments on the original. About that part Gerald Weinberg commented, that he had received more thanks for this piece of advice than any other advice he had ever given. |
|||||||||||
|
|
I don't think you should strive to be either "indispensable" or an "easily replaceable cog". Both of these directions are byproducts of different kinds of behavior, but neither should be the goal. What you should actually be trying to do is learn as much about your business domain and the technical stacks in which you work, and apply that knowledge to do the best job you can, while constantly improving both yourself and the product you're working on. If you're the only person in your organization doing this, then you might reach a point where you are "indispensable" to the organization for a time. This is ok, but only for a time. At that point your goal should shift into transferring your knowledge to others (if you haven't been doing that already), documenting what you know into places that others can easily reference, or training the next generation on "how to learn" and to do what you have done. Once you do these things, you will no longer be "indispensable". On the other hand, if everyone in your organization already behaves this way, constantly learning, constantly striving to do better, you may find yourself a "replaceable cog". That's fine too, everyone is replaceable at this organization, information is well-known and well-documented, and you probably have an excellent management team. In this organization, the trick is to find a way to stand out by taking on a project no one wants, turning around a terrible or cumbersome business process, or taking a risk on something your peers are dubious of, but if successful could bring in new revenue, etc. If your goal is simply to be able to take vacations and not be called after-hours, it sounds like you are already a "replaceable cog". |
|||
|
|
|
Read Seth Godin's Linchpin. Become indenspensable not because you hoard knowledge about the system, but because you're brilliant in making it better for everyone (customers and developers, of both the existing and potential category.) (I've read it myself, incidentally just the month after I decided to stop muttering for myself and just start to the best job I can. :-) |
|||
|
|
|
I've alawys striven to learn as much as I can about the work environment and application and business domain, not to become indepensible but to be able to do my job more easily and better. I also always strive to pass that hard-gained knowldge on to others. No one in an organization is indispensible, so don't strive for that. Strive to be the best you can be at what you do which may mean going the extra mile. But it doesn't mean you have to give up weekends and holidays and vacations. If you have done your job well, you have prepared someone else to take over when you are sick or out of the office for any other reason. Your work is checked in to source control and others know where it is, others have code reviewed your work and are familiar with it, others know how to troublshoot if there is a problem. Professionals don't hoard information in order to be indispenable; they do work to be considered expert in their field. |
|||
|
|
|
You should strive to become indispensable by making yourself dispensable. If your work is so good that anyone can work on it and improve it, then your dispensable. However, you create so much value for your employer that he would be stupid to let you go. If, on the other hand, you aim to make yourself indispensable by developing nightmarish solutions, you will be replaceable by a more skillful programmer and you will hate your job. In the unlikely case that your employer doesn't want you anymore because you put yourself out of work, you will most likely be able to find a better job in no time. |
|||
|
|
|
If you are indispensable, how do you aim to be promoted? So yeah, even from a purely egotistical position, it's still negative to be indispensable. Also, why strain yourself to reach the unobtainable? We're all replaceable in the end, and I firmly believe this to be a good thing. |
|||
|
|
|
The goal should be to write code that can be managed and enhanced by someone else without too much difficulty or your direct involvment. Not only does this free you up to take a vacation, but allows you to create something new. Other than helping create a great company that will attract other great programmers, I don't know what one can do to be replaced to write the next great app. Many musical groups replace singers and musicians, but few ever replace song writers. |
|||
|
|
