Quitting a job you just started

It’s happened to everyone, you just started a brand new job, probably event left a decent job for it, only to realize that the new job sucks and you absolutely hate it. It happened to me recently, I was starting to get cabin fever working for myself and decided to pick up a remote contract position. Pay was good, most of my co-workers were awesome, it was 100% remote which allowed me to maintain my self-employed lifestyle and it was in an industry which I have prior experience. Even still, something was terribly wrong.

I did a fair amount of searching the web on the topic of quitting a job you just started and there were pretty divided views on the matter. One camp were optimists that felt that you need to give the job time and that it will more than likely get better. I felt like that optimism would hold true in situations where you’re in a new job that’s “hard” or above your current skill set. In that situation, yes, giving the job more time would help to improve the conditions. That is assuming you are applying yourself and picking up on the nuances of said job.

The other camp, the camp in which I pitched my tent, were pessimistic and felt that you should get the hell outta Dodge because conditions would most likely not improve. Perhaps pessimism isn’t the right term, it was mostly just trusting your gut. I didn’t like having to make the decision, but that’s how I felt. I consider the idea of quitting something so early on to be defeatist in nature. I know that I could have helped the shop along based on my own experience, but I had to look at the situation and say to myself, “what am I going to get out of this experience?” I felt that the answer was most likely “very little” and that didn’t sit well with me.

It was more than just me being selfish, there were some very big factors that weighed into the decision. Keep in mind that I did not make the decision because I had another job lined up, not initially at least. The decision was made without a safety net and could easily be considered an edge case at best. So what would cause a man to give his 15 days written notice after a mere 3 weeks and 2 days into the job? Glad you asked:

Negative first impressions

You may remember a previous post of mine about how having a child ruins your life. That came up not only on my first day on the job, but my second day as well. That wasn’t even the part that I considered so negative. The same co-worker was very candid with his feelings about the company and the company’s CEO. Statements like “they bought their way into being the CEO” and “they have absolutely no business running a company”. Yes, this happened on my first day. Nevermind the comments about having kids, this was downright cancerous for a new hire.

Oh, and the co-worker’s house smelled like cat piss.

Lack of best practices

The shop was very waterfall in nature, which isn’t ideal but wasn’t the end of the world either. What was very off putting was the fact that many of the most tenured developers were very reluctant to adopt new behaviors, to the point that there was a moment on our daily stand-up call that the most tenured developer was belly laughing when I brought up writing unit tests. I get it, the system was old, full of hacks and resembled a bowl of spaghetti, but it seemed like no one wanted to take the first steps to adopting modern practices.

Speaking of the daily stand-up call, it usually weighed in at 45 to 90 minutes, EVERY DAMN DAY. The team was small enough that the stand-up call could have realistically taken 15 to 20 minutes. I wonder if it was perhaps the fact that everyone was remote and some people felt it was nice to talk to other people every once in a while. Another theory is that some team members were hard to get a hold of so it made the most sense to talk about everything on the call. Regardless of the reason it fucking sucked.

Circling back to unit testing, during my short time there, I was tasked to put together unit testing documentation. Obviously there is a ton wrong with that statement, specifically the fact that unit tests can be automated without the need of filling out senseless spreadsheets. What blew me away was that the documentation wasn’t passed to the QA person, it was just for the developer to do their testing with. The QA person would then put together another set of test documentation, seemed like double the effort in my opinion. Oh, did I mention that these unit test documents were to be reviewed on the daily stand-up call? Fail.

I made it through a single sprint and deployment and everything that could be wrong was wrong with the deployment. The deployment itself happened on a Friday at midnight. Allegedly deployments are typically done earlier in the week, always at midnight Eastern time, but the release I was privy to was an exception for some reason. I’m a firm believer in continuous integration and being able to deploy multiple times during the day. I know that doesn’t work for all shops but Friday at midnight? I thought those days were long behind us. If nothing else, developers aren’t necessarily as sharp in the middle of the night after working all day. If something were to go wrong, you’re setting yourself up for failure by not having everyone on their A game.

9 hour work days

I’m still unsure if I didn’t understand this correctly or what, but evidently all forecasts by the business were built around 9 hour work days. The extra hour was to factor in the daily stand-up call which was blocked out for an hour per day and did not factor into your billable time for the day as only coding / project meetings were billable. I felt this was a blatent abuse of salaried employee’s time and quite possibly illegal considering those 9 hour days didn’t even factor in lunch or breaks.

Back to the meetings, the week that I gave my notice I had 2 days in which I had 4+ hours of meetings each day. That just wasn’t an environment that I would be able to thrive in. To quote 37Signals’ Getting Real, “Meetings Are Toxic”.

Consultants

I was hired to help maintain version 2, also known as their current system, and eventually transition over to version 3 once the moon and stars aligned in such a way to allow the team to move forward with the rewrite. Before even getting to that point, I reviewed the documentation for the project and simply put, it was academia drivel, not to mention my thoughts on ground up rewrites.

What astonished me most of all was that the new system was being designed by a consultant and the project spearheaded by a developer that had only been with the company for 7 months, not one of the senior / tenured developers. The most tenured developer had been around for 9 years and probably knew more about the system than anyone ever would. Incidentally, another senior developer left before I was hired because of this system rewrite. I don’t blame him one bit, I would have left too if I had been around for a while and some “Bob” came in to design a new system that I would have to maintain.

Back to the academia drivel, the documentation for the new system was very textbook and lacked the heart and soul of someone that’s built large scaling systems. Buzz words are just hopes and prayers most of the time and quite frankly, I didn’t think the system was all that terrible. Was it slow as shit in some places? Yes. Could it have been refactored and improved upon? YES! The sad truth was that no one was putting in the effort to make the system better. Focus was 100% on pushing out new features that the business unit wanted.

“Us versus Them”

Nothing is more of turn off than an “us verus them” mentality with a development team. That’s when a great experience ends up just being a job in my opinion. That mentality was very rampant at this shop and honestly, rightfully so.

The aforementioned v3 of the system was being guided by the business unit with little to no input from the development team. Huge red flag signaling imminent failure in my opinion. Also, during my short tenure, I had project priority shuffled a handful of times mid-sprint. Textbook case of agile done wrong, having the business units reprioritize tasks in the middle of a sprint. The whole purpose of a sprint is to avoid such shuffling.

Being asked to rewrite my resignation

This was weird as I had never had it happen before and according to some of my friends, it’s illegal to make the request, at least in some states. The reason I was asked to rewrite my resignation was because of some of the things I had mentioned in this post and it seeming like perhaps my manager was the reason for my feelings. Fact is my manager was great and reminded me a ton of a previous manager that I loved. Hard breaking up with someone you like.

Being asked to rewrite / clean up my resignation letter made me feel like the decision I had made was the right one.

Conclusion

Do I regret the decision? Not at all. It sucked that I had to do it, because no one likes breaking up, but it needed to be done. I don’t plan on putting the experience on my résumé for obvious reasons. Interesting enough, during the experience I had come to find out that at least a couple of my friends have had similar experiences in the past. Shit happens and at the end of the day you need to make decisions that are good for you. If you’re not happy, you won’t be productive, and will probably get fired eventually anyway.

Had a similar experience? I’d love to hear about it, comment below!

Josh Sherman - The Man, The Myth, The Avatar

About Josh

Husband. Father. Pug dad. Musician. Founder of Holiday API, Head of Engineering and Emoji Specialist at Mailshake, and author of the best damn Lorem Ipsum Library for PHP.


If you found this article helpful, please consider buying me a coffee.