Should I Stay or Should I Go

When is the right time to leave your job? It is natural to want to stay in a secure position. It is also natural to think a new job would solve all your problems. When is the right time to switch?

Are you finding it difficult to motivate yourself to go to or stay in the office? Are you constantly distracted from what you are supposed to be doing by the pull of social media, news sites and your notifications from your personal phone? Perhaps you are experiencing the warning signs that it is time to move jobs.

A Change is as Good as a Rest

There may be nothing wrong with the job you are in at present; it might be giving you great experience, making you face challenges regularly and have great co-workers to interact with. Sometimes it is simply that you need a change.

Ever feel like you have been there so long that you start to say “We didn’t always do things like this”? When you look around your colleagues and can’t find anyone that was in the company when you joined, and for those that came after it is difficult to remember exactly when they joined the ranks. It might be time to look for opportunities elsewhere, simply to keep from feeling like a dinosaur.

Another sign is that although you have not risen to the highest rank in the department or company, there is little that goes on that is not run past you. Simply by being there for so many years has given you a feel for the entire organisation. This drains your time as you get consulted for anything and everything.

A worse scenario, however, is if the new bunch of employees stop asking you about the systems. They are planning to replace everything and no longer want any advice from you about how to get it done. This can be demoralising as you look on as years of work is taken apart one piece at a time.

All Good Things Must Come to an End

As software engineers, we often work with hubris, assuming that our creations will last forever and always give the maximum functional value. That is simply not the case. All systems get replaced. All software is replaceable. Even developers are replaceable.

We should not get so tied to our creations that we are unwilling to let them go. To walk away from them. To see the next crop of engineers take them and change them to make them work better. This often involves the tearing apart of the lines we had once committed with pride, debugged with care and released into the production wild with the eye of a parent sending their eldest child into school for the first time.

The previous paragraph is an exaggeration. Developers are more likely to look ahead to the next coding challenge than to look back at code already written. Those pesky bugs that keep distracting us from new things are more likely to raise curses when they are brought to our attention than tearful eyes. My point is that we sometimes take excessive pride in past creations. This pride is not always warranted.

It can be difficult to ask “Can we live without it?” as this means destroying something that we were part of. It means that the specialist knowledge that only we have as its creator is no longer ours to wield.

The code we write solves the problem at the present moment. If we are forward thinking, it can work long into the future, capable of scaling with growth or changing with new use cases. But eventually, all production code will get replaced.

How often do we consider this moment, the moment that a system will be turned off, when we start to write code? I don’t think I even had a conversation with fellow engineers that went along the lines of “How will we remove this from our systems when its no longer of use?”; decommissioning code can be problematic. Any monolithic application will have issues as the dependencies between different parts will make it a tangled mess to sort out. But micro services architectures will also face issues as the dependencies between components grow. When is it safe to remove a service?

If we ask ourselves at design time how we will eventually remove the code or service, it may make this task easier when the time comes. If it is possible to know, perhaps by monitoring for particular warning signs, when a component is reaching its end of life, then we can plan appropriately. Perhaps when a web service is called less than a certain threshold per time period then it is worth reviewing its value. We would then design and build with that metric in mind.

Exit Plan

Similarly, when we join a company, should we consider what the exit plan is? Often a job is just a means to keep earning a living, not really helping us to achieve our life goals. When starting a new job it would be a good idea to ask, what is my exit plan from this company and job?

Perhaps you are taking a new job (or took your existing job) to gain experience in a technology that you otherwise would not have had. Why not state at the beginning of the job how much experience in terms of time you need to fulfil that goal? Or perhaps you are taking on a management type role and wish to advance up the hierarchy; it would be a good idea to state, privately at least, how far the company should take you and in what sort of time frame.

What we are getting at here is having long term goals to advance towards. For those in a technical job like software development there are some clear forks along the way. Should you continue in a purely technical role or move towards people management? Is the big picture decision making of architecture more interesting than the hands-on experience of writing code every day. If you are junior level, what is your target for experience with this company?

Asking these questions up front can help you to avoid the trap of staying in a job too long. Review them annually or more frequently to ensure that the company is still providing you with the experience that you require to reach your goals. When it stops doing that, it is probably time to leave.

By planning your exit strategy from a company well in advance (in other words on the day you start!) you will have clear signals that it is time to leave and not fall into the pitfalls of simply doing the job because it’s your job, long after the excitement of the role has gone, and long after it has ceased moving you towards your career goals. It will also take the emotional attachment, to both your code creations and the people you work with, out of the equation because you are reviewing your position with metrics that you wrote before becoming a part of the company.

Is it too late if I start now? It’s never too late, but it will be harder. Take time to answer these questions and make a decision:

• what is my career goal (it helps to think big here)?
• when do I want to retire?
• what skills to I want and are they being improved here?
• am I gaining the appropriate experience here?
• is there a path to higher levels of management, if that is my desire?
• is the technology stack up-to-date and of use to my career?
• am I getting to work on projects that interest me?
• can I become an expert in a technology niche while still working here?
• is there a good culture?

If your goals will not be reached by staying at the company then take action. Either way it may be a good idea to write down a few points:

• your long term vision; the big dream you have for your life and/or career
• a milestone along the way that is more tangible than the big dream
• what sort of results to you need in the next year to get to the milestone?
• what activities can you do daily, weekly or monthly to achieve these results?
• what are you going to do first?

Take time to think about and answer these questions. Try to view your career as if looking at it from the outside. Perhaps imagine yourself a year or two after retirement, looking back. Can you imagine what a successful career would look like? Are you on that path?

Whether you decide to stay in your current position, look for promotion within your company, or look elsewhere, try to ensure that you will be taking a step towards the fulfilment of a big goal so that the “future you” will look back with pride on their career and this decision.