Codex: Leaving a job

Leaving a job

Even as developers, we can find ourselves in bad workplaces. Too much or not enough processes, spaghetti unmaintainable codebase, over-engineered solutions, lack of automated testing, poor planning, old technologies, long manual builds, to name a few.

The most popular solution to all these problems is a job change.
We want improved companies, but do we at least try to improve them? Why we do not change current jobs to be a new, better ones?


Changing a job

You may think: I am a good programmer and this is not my fault, why should I clean someone’s mess? Is it my responsibility? The scope of the contract was only about writing the code…
There are a few reasons for taking this challenge though.

First one is an idealistic reason: common good. That every worker gives more of himself and the world becomes a better place. Sharing knowledge and practices.
Looking at it that way, leaving seems to be the easiest, selfish solution.

Second, less idealistic, is about being a professional. You are hired as a professional, and part of being professional is about being more than a robot just doing tasks in exchange of money. If the company demands quality below common standards in the software development, or tries to push an impossible deadline… it is the company to be improved, and the developer to fight for it.
The professional attitude is perfectly described in a book The Clean Coder by Robert C. Martin (Uncle Bob).

Third, is more down-to-earth. It might be easier to improve current job than to find a significantly better one. Because – The code is not greener on the other side of the cubicle.
Also, working conditions can change even after a few months: current company can improve, and a possible new and shiny company, can get worse.

Fourth, improving the workplace will make you seen as someone responsible and caring. And this can be a key point for a promotion or a raise.

Fifth, after having your workplace improved, you will work more with a new technologies and tools, which will make you more valuable on the market.

Finally, you might have already decided to take another job. Before you find it, doing something to fix current pain points won’t hurt. You are leaving anyway, maybe your notice period will be more enjoyable.


To cover edge cases

When the advice on improving instead of leaving should apply? Every company is different. Working for some time at one place, talking with coworkers there, will reveal if there is a chance.

Generally, don’t try to force a change before you understand why something is in certain condition right now. And don’t push for anything too hard, except critical (like pushing a new feature without testing it all all).

If your missions is to save the software development world, don’t do silly blackmailing. Being fired won’t help anybody.

Let the company grow to new solutions. Present your ideas well, include possible returns on investment.

Don’t fix mistakes of your coworkers behind their backs. They won’t learn that way. The improvement must remain even if you leave the job, otherwise it’s not worth the hassle.

Sometimes, maybe everyone thinks something is a problem and they are just afraid to speak it up, or don’t have a presentable solution yet.
Maybe the company uses business (mis)practice “cut costs as long as they don’t complain” – then certainly do complain.

Getting Things Done When You’re Only a Grunt on Joel on Software has very good tips as well.


Don’t tell the truth?

One of common tips when leaving a bad company is to leave on good terms. When you are asked by your soon-to-be ex-boss, you have to say “Yeah, everything is fine, I’ve just got a better offer”.
Just like the other option would be only “This ***** company is so bad, **** you all”.

Think about saying “It’s fine, but <e.g. unit testing> would really help the company, and my new company uses it extensively with huge success. It was one of many points their offer was better”. After five people leave with that comment, there is a possibility that the company might eventually probably get it.



The goal is to make a decision on leaving without emotions or illusion, that anywhere else will be better – for granted.

Remember that duties go first, then improvements.

Improving or at least trying to do so will be beneficial to you and the company, so try to improve as long as it is reasonable.
Sometimes the choice would be to live at some medieval colony on a class M planet and “develop” basics of electronics, or to just ask Captain Picard for an asylum, and improve the shiny holodeck software.

Anyway, if you don’t care about your company, or you’ve graduated from the University of Ferrenginar, that’s fine. But please stop complaining how bad your last workplace was.

Edit of 2021.06:
Recently I have found an article Technical leader worries: my organisation is a mess and nobody cares by Mariusz Sieraczkiewicz, which puts job satisfaction and quitting in a similar perspective I think…

One thought on “Codex: Leaving a job

Leave a Reply

Your email address will not be published. Required fields are marked *