I am replaceable

Weird thing to say. “I can be replaced”. Who wants to be replaceable after all? Taking this point of view results in some rather philosophical discussions probably. However, I think, that those discussions are very helpful when we’re talking about software engineering. In this article I wish to explain my situation as a developer while making this statement.

Ok. Being replaced because you’re not good enough can hurt. You did your best and it is found not to be enough for your previous employer. Your previous employer had a hard time too (maybe). He is losing a part of his team and now needs to find someone better fitting. But there is one thing he does not have to worry about; the code you’ve left. It can be picked up by almost anyone else because you wrote it like you’re replaceable.

Why would I do this? So I can be replaced easily?

So the above sounds contradictory. ‘Why would I do this? So I can be replaced easily?‘. The origin of this question all starts with some vanity, ego and maybe a little fear. You want to be the best maybe. Or you want to stay at your current company so you start creating code that is only understandable by you. Having the fear to be replaced is always there, but I found out that creating this whole replaceable situation puts you in a far more valuable place in the eyes of your employer.

How should my code reflect this and what will happen then?

There are some mindsets you’ll have to change and I leave it up to you to how far you want to go. 

1. Don’t over-complicate your code. That means you don’t want to use complex design patterns just because they result in the least amount of code. I believe that if you use a simpler, more elaborate design pattern, any junior developer can pick up the code
2. Write all your methods, functions, variables, etc. in full name. This is an easy one, but sometimes feels too ugly. I would always prefer simplifyPhoneNumberToOnlyDigits(string phoneNumberWithFormat) to simplifyPhone(string p). (just an example ofcourse);
3. Also keep in mind that it’s not just code. Documentation is a big part of course. This includes in-code documentation like JavaDoc/PHPDoc, the actual documents necessary to get into the code (remember, you are replaced directly), and all the extra kinds of documentation that is used by your employer like wiki’s, diagrams, explainer video’s, etc;
4. Ok, this list could be vèèèry long, but you get the gist.

Then WHY do all this?? Just so your employer has less problems kicking you out? NO. I found that if you do this, your employer is actually more likely to keep you on because of this mindset. Creating code like it’s not yours to keep, results in more readable code, less bugs, high maintainability and a lot more benefits.

Why am I one to talk? I started as a consultant for a large multi-national IT consultancy company where I got suspicious about the positive effects about the mindset. After seeing a lot of different environments, the most important thing I noticed is that if people wanted me gone for whatever reason, they were happy about how I left it and in almost ALL projects that I worked for, I was requested to work for again because of all this.

Now I run my own company and I am responsible for all the technique at SOSvolaris. And now, even though it’s my own product, me and my team still write it like I we're a consultant who can be replaced at any second.

Hope this mindset is something you all can acknowledge and/or help you in the future, but if it is not. Please place a comment and let’s discuss.