As a programmer, your work will mostly be split up between either maintenance and feature development. It is up to you to decide which of the two you prefer to spend more time on. If you write bad code, you will end up spending the majority of your time doing bug fixing. If you write good code, you will spend the majority of your time developing new features … and no, you will not run out of features to develop because there will always be room for improvement and it is human nature for people to always strive for bigger and better and more efficient. People who write bad code, are forever stuck doing maintenance and support and never move on to bigger and better features and opportunities. So people who write bad code are doing themeselves a disservice in the long term.
As for becoming indispensable; in my experience it’s impossible to be 100% indispensable, but there are things you can do to become more needed and being needed is not binary (needed or not), but rather something on a scale e.g. needed from 1 – 10. Replacing a programmer/employee always has a cost associated with it in terms of recruitment costs as well as knowledge transfer costs (time and material spent learning the existing code base and technology) . With that said, it all comes down to money for the employer/customer, who will ask themeselves “what is easier, replacing the programmer or carrying on paying him/her”? The answer to that question will determine how needed you are.
Becoming needed is only one aspect, while becoming useful is another. In many ways, striving to become needed will make you less useful and vice versa. For example, the easiest way to become more needed is to become more specialized. The problem with specialising though is that you have less to fall back on if the technology you’ve specialised in becomes irrelevant.
Become needed: specialize by setting yourself apart from the rest.
- Stay away from mainstream technologies and companies: the more popular a technology is the more programmers/experts there are in the market for that specific technology. This obviously means that you will have more competiton. More competiton means greater supply in the market, which means lower prices/salaries for those programmers. When there are 1000 programmers like you lining up at the employer’s door, it becomes easy to replace you.
- Focus on either leading edge or trailing edge technologies for the same reasons as above i.e. there are few that dig into and risk learning a leading edge technology. The same applies to legacy technologies where there is a shortage of skilled people. Nobody wants to learn legacy technologies because it’s not cool. Don’t try to be cool, instead try to be needed.
- Find a niche market/product: there may be mainstream development stacks/technologies being implemented in niche markets/products, but there will always be small details that are learnt only through experience in that specific market. New comers will therefore have a tougher time getting up to speed.
- Learn proprietary technologies: in other words learn technologies that other people cannot learn by simply browsing the internet or picking up a book at the local book store. These are technologies that can only be learnt from your company sending you on those courses etc. Once again this will set you apart from the rest.
- N.B. with all of the above said, keep in mind that there is a tradeoff to specializing. The more you specialize the more needed you are, but the less usefull you become i.e. you may know a technology better than anyone else in the country, but if you can’t do anything else you are not that usefull.
Become useful: generalize by being able to do as many different jobs as possible. See the big picture by understanding the big picture as well as the details: most people focus on either the details (lines of code) or the design/strategy. You don’t have to be an expert at everything, but the wider you spread your view the better.
- Business Logic: Even more importantly, understand the business rules of the software you’re developing. Any programmer with equivalent technical skills as you can take over your code immediately. However, learning the business rules of the software takes a huge amount of time and if there is limited documentation it makes it almost impossible for someone else to take over an intricate software product.
- Design: Learn the design of the software, in terms of how all the components fit together to make up the entire system i.e. the web application, database, clients, services etc. As with the above point, anybody can come in and undertand a specific function in your code, but understanding the overall design of the software is incredibly difficult if there is limited documentation or limited knowledge transfer.
- Sales: Learn and get involved in the sales/business aspect of your company, in terms of what it takes to sell the product and what the customers are looking for. Once again any other programmer can come in and take over some code, but being part of the sales cycle makes your more needed as well as more useful.