DEV Community

Cover image for When is it time to leave?

When is it time to leave?

Kyle Stephens on January 15, 2018

Now that the new year has arrived, the festivities have been wound up and you’ve started to settle back into the day-to-day work routine, you may f...
Collapse
 
whozzawuzza profile image
'''⌐(ಠ۾ಠ)¬'''

This may have been touched on in other postings on dev.to, I can't recall, but how long should/would you give any of these situations before you swap out, particularly if you haven't been at the company a long time?

For example, I've been in my current role ~7mo, mid-to-senior level full stack JS dev. A month after I started, they fired - without warning - an entire team (20+ people) at a different office, for reasons both valid and otherwise... However, it's made the HiPPOs extremely sensitive to anyone's tech opinion. Both how they handled that situation and how they're behaving now makes me very uneasy. I'm not opposed to learning new things, as most of us are here, but when I'm a JS heavy dev and I'm told "it'd be a good idea to learn .NET" here - to bug fix legacy systems that are 6-8 years old, that seems like a huge red flag as well.

I've had quite a number of recruiters and companies reach out in the last month or so. Will it look bad on my resume, or to future employers, if I've got a stint <1 year on there? I mean, on one hand, current interests don't seem to care, but I'm thinking long term.

Collapse
 
antero_nu profile image
Antero Karki

If you have a valid explanation for why you quit within a year, it shouldn't be a problem and it sounds like you do, "they want me to do .NET but I want to focus on JS which I was hired to do. Turbulence within company etc" Been in a similar situation and have been asked why I want to leave so soon and my reasons were fairly similar to yours. I'd like for that to be the exception though.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

That's a tricky one and the answer you get will depend on who you ask.

Some would say that the idea of a 'job for life' is now gone and that no job is ever stable - as evidenced by the fact that an entire team of 20+ people were let go! So, if companies have no loyalty to their employees, maybe there shouldn't be an expectation that the loyalty goes the other way round either? Others may disagree with this view.

I think it's important that you leave for valid reasons however and can justify these at an interview. Any prospective employer would probably be wary of someone who leaves on a whim for trivial reasons.

In any job search, it's a good idea not only to assess the role at hand but also the other potential roles in the organisation - e.g., is there scope for growth, advancement, new learnings, new types of roles, new developments. That way you're more likely to find a company you can enjoy a long tenure with - which is probably preferable to regularly being the 'new guy/gal' anyway, right?

Collapse
 
mrmovl profile image
Tomke Reibisch

Nice and organized writeup. You matched my believes exactly, but my thoughts where never that consize :)
I am about to start a new job, because the old one had problems with Hippos and didn't handle the scaling thing well regarding processes. So many passages I could quote :)

Collapse
 
ky1e_s profile image
Kyle Stephens

Thanks for reading :)

Collapse
 
ben profile image
Ben Halpern

This offers a lot of introspection, speaking as an employer. Thanks Kyle.

Collapse
 
ky1e_s profile image
Kyle Stephens

Happy to share, Ben :)

I think that while both employees and employers can shape a workplace culture it's important that, as an employer, one takes a moment from time to time to step back, reflect, define, and evaluate the culture – both what it is now and what you want it to be in the future.

The above observations are based on my personal experiences and are ones that repeatedly popped up on different projects - I am sure there are other areas to consider, but, as I say, this is just something to stimulate ones thinking about happiness in the workplace.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

I think I've left jobs for all of these reasons.

Don't forget there is also "better opportunity" as a reason to leave. Your current job could be fine, but there's a better one available. A bit of a gamble, but often a good reason.

Being able to a leave a job that doesn't fit (for any reason), is vital to your career.

I find that by the time you start asking yourself the question, "Should I quit?", it's about the right time to do so. Or at least, force the current job to change.

Collapse
 
ky1e_s profile image
Kyle Stephens

A better opportunity is a solid addition.

I think we, as developers, are super privileged that our skills are in such demand and that there are ample opportunities out there for us. So whether it's seeking better opportunities, or seeking an improvement on the current situation, we're so fortunate that most of us have the opportunity to make changes.

Collapse
 
tunaxor profile image
Angel Daniel Munoz Gonzalez

Well This indeed tells me stuff I've been wondering when I'm about to leave in other jobs, I'm glad to know I'm not the only one considering these things

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

Thanks for reading :)

I don't think any role will ever be perfect. It's great you work with great people and are rewarded for your work.

On your point regarding user perspective, I'm not sure whether you mean A) validation that the features delivered succeeded in achieving their goal or b) you would like to understand the tangible benefits to the user of the features being proposed before you develop them.

If it's A) there are some great analytics tools out there. I'll be happy to let you know what I use if you'd like.

If it's B), a first step might be to suggest that requirements are written in the form of User Stories, if they're not already, so that developers can understand what value a proposed feature will bring to a user, instead of "feature must do X thing". Beyond that, it's probably a matter of making suggestions to amend the processes, if processes exist, so that developers are more involved in understanding the business and not simply writing code. If no formal processes exist and you would like a bit more structure, why not be the person to float the proposal? ;)

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
ky1e_s profile image
Kyle Stephens

Because you mentioned lacking user perspective, I was more thinking along the lines of validating that value has been delivered to user post-delivery, via heatmaps/analytics/A-B testing and things like that.

I wish you luck with advising on the processes. It can be a rewarding experience - particularly if people start seeing faster deliveries and better deliverables.

Collapse
 
luisventura profile image
Luis Ventura • Edited

Oh boy do I relate... Actually my last job/workplace went through exactly these stages, one after the other in the course of three years. Madness! but honestly I think this wouldn't have happened if I had been better prepared by then and consequently had countered every situation.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

So, do you feel you had the scope to influence change yourself? Sometimes, particularly in larger organisations where meaningful change must come from the top, I've found that this isn't always the case. However, I do think it's always nice to view these situations through the lens of "there's opportunity in challenges" - whether that's opportunities for personal growth and learning or opportunities for advancement by demonstrating leadership through helping to own and resolve known issues.

Collapse
 
luisventura profile image
Luis Ventura

I believe I was in position to make it better, and even though the 15-employee company is doing well, it would be miles away when I had a somewhat privileged spot. It was a lot of experience, a lot of "never let this happen again" experience, and "fight when you know you're right, humble down when you're not". By the time I quit out of suffocation, I was juggling with too many things that kept me from delivering an acceptable degree of quality, missing milestones and it was a constant fire to fire situation. I think I learned my lesson big time.

Thread Thread
 
ky1e_s profile image
Kyle Stephens

Thanks for the candid response. Every experience is an opportunity to learn, right? Both in terms of personal preferences regarding work environments and also in terms of personal skills approaches and to work! Hope the new role is going better ;)

Collapse
 
arvindhmani profile image
Arvindh Mani

On a side note:

"These projects can typically throw new challenges, present an opportunity to showcase abilities..."

Think carefully before you use the words "throw new" in a sentence on a software developer article!

Collapse
 
ky1e_s profile image
Kyle Stephens

;)

Collapse
 
sebastienkb profile image
Sébastien Kalb

I have a somewhat different experience.

I quit my job last week and doing notice time now. It was a startup, I'm not a founder but I was there since almost the start (4+ years going from 4 people team to 20+).
Being a "veteran dev" had more drawbacks than advantages:

  • Knowing the old code base makes you its support guy by default. New devs aren't bothered to learn it because it would scare them off.
  • Customers know you're knowledgeable of their problems, so they ask you explicitly ("May I talk to X instead? He knows how to fix this").
  • New managers don't know what you accomplished, what you deserve, and where you suffered. All your achievements are reset and you have to proof yourself from scratch in their vision. This was the most tiring considering management changed every year in the past 3 years.
  • You're somewhat irreplaceable in your job and when you consider quitting you get the extra pressure from your teammates to stay, as if the fate of the team depended on it.
  • Management takes veterans for granted because "they have gone through worse anyway", so when you finally quit it's all shock and surprise.

I'm glad I decided to leave but this notice time is awkward.

Collapse
 
ky1e_s profile image
Kyle Stephens

That's an interesting perspective. Thanks for sharing.

I don't think you need to feel any guilt. You've obviously helped the company grow through your contributions. The best thing you can do to leave with your head held high is to probably continue giving it your all during the notice period and ensuring any appropriate handovers are made and documentation is signed off.

Collapse
 
astarael2 profile image
Simon Mills

This is a little too close for comfort... Though it is nice to know it's not just a problem at the company I'm at currently. Things are getting better but everything moves at the speed of corporate. i.e. Glacier pace.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

Thanks for reading.

I wouldn't immediately discount all corporates as some are more nimble than others.

I'm sorry the role's not everything you'd hoped it to be. If you find yourself with downtime, maybe you can use it as an opportunity to learn whatever new technologies or approaches you'd been wanting to look at. You could even turn that learning into a career-booster by starting a community of practice in the office around that new thing you're learning?

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ky1e_s profile image
Kyle Stephens

I really don't think so. You have a very valid reason which you can explain clearly to any prospective employer (as you have just done here). Congrats to your wife and to your family :)

Collapse
 
dsanchezseco profile image
dsanchezseco

HiPPO's everywhere! And more important, non-tech HiPPO's talking about tech decisions. Worst ever that can happen.

Collapse
 
ky1e_s profile image
Kyle Stephens

It's important to differentiate between 'product' decisions and 'tech' decisions. If it's the latter, there's likely a problem for sure.

Collapse
 
dsanchezseco profile image
dsanchezseco

Sure, the tech must address the business, but do not talk about the different tech solutions as long as they solve the problem, I, a developer, I'm paid to think and know about that

Collapse
 
napoleon039 profile image
Nihar Raote

Wow, an interesting peek into some of the reasons why developers leave a company. I had kind of heard about some of these reasons, but you laid it out in a great way🙂. This shows we should research the company, their culture the best we can. And the part when an interviewer asks us whether we have any questions - that's a really great opportunity to get to know the inner workings of the workplace to know if it's a good fit for us. Granted they could hide the truth or just flat out lie, but I guess it helps to identify early on if what we were hired to do is different from what we get to do on the job.

Collapse
 
pozda profile image
Ivan Pozderac

Never ending legacy projects maintenance did it for me.

Collapse
 
ky1e_s profile image
Kyle Stephens

Yeah, that'll do it alright. Although, the flip side is that sometimes, the more legacy - the more lucrative! For instance, have you seen how much a contract COBOL developer can command!?

Collapse
 
pozda profile image
Ivan Pozderac

Of course, but i'm talking about not so old legacy code. for example i had to do some projects on node sass which is fine, but for older projects also had to have ruby sass installed. that's not problem either, but also had projects on various typescript versions, no docker, so changing path variables manually was only option. people were writing features for this projects and they needed me to do some bugfixes on my side here and there and sometimes there was gap of few weeks before i got back on project. I ended up installing and configuring some new software almost every time i worked on them, not to mention that i had to juggle 3 - 6 projects daily. you can get irritated pretty quick when half of day is reconfiguring stuff for 15min of actual work.

i would never prefer money over sanity.

Thread Thread
 
ky1e_s profile image
Kyle Stephens

Ah yes, I was only teasing (you should check out what COBOL looks like to see what I mean!)

That is frustrating alright. Sometimes in those situations the people who make the requests don't realise the real cost involve in making the updates - the context switching, environment configuration, focus switching, etc. - I find it sometimes helps to explain to them the real cost in terms of your hours and they may realise these minor 15min updates aren't worth the 2+ hours it takes to make implement them. Either that or they could hold the requests and batch them together so that there is a significant unit of work to be undertaken in one go.

Thread Thread
 
pozda profile image
Ivan Pozderac

i totally agree with you, but when pm lets client micromanage all the things and when everything task is of urgent importance, there's no room for sanity

Collapse
 
haccker profile image
haccker

gg

Collapse
 
robdwaller profile image
Rob Waller

Great post, I've experienced much of the same.