Iyfjky

Question

Today I was fired from a software company.. for the 3rd time in 1.5 years. Needless to say I feel like I reached bottom and it's impossible to get out without changing career. Should I change a career? Is it even possible to find a job now?

Fired from a fintech company on the 2nd month for not performing. This was correct since I had a lack of motivation.

Fired from a web platform company for not performing. I was placed to work with a technology unrelated to what I signed for, so this seems like poor management from my side.

Fired on 6th month for poor performance. During probation I received positive feedback. After that I changed project and I spent a lot of time refactoring and trying to remove technical debt. I received a verbal warning for under-performing before going on holidays. In the 4 days I had I tried to fix that by staying overtime and finishing all due work. However when I came back from holidays I received a termination letter.

Except case 1, I think the other cases was due to poor management and probably a bit poor communication from my part. However is there even a chance that I can sell that? Generally the issue as I see it, is that I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

I'm pretty lost at this point. I'm in my 30s without a fallback place, no family around and not many friends. Luckily I have a few savings for keeping me going for 6 months but I'll need to make the right choices.

All this is based in UK. In terms of coding, I would say I'm above average and try to follow general good practices, refactoring, testing, design patterns, etc. I have a very good GitHub portfolio with many high-starred projects built from scratch. Some projects have in fact been used by some companies I have interviewed with.

Comments are not for extended discussion; this conversation has been moved to chat. — Oct 18 at 15:50
What were the KPI/ priorities/ targets/ criticisms of the companies? What did they say about your work? Many places don't give a hoot about refactoring, test, test coverage, architecting, fixing technical debt or culling dead code, and they may not be alive by version 2.0. It's not so much about a right or wrong, more about what process you're compatible with. Ask people you worked with (verbally, privately, offsite). — yesterday
@smci generally refactoring was mentioned in quarterly meetings although not explicit tickets were assigned. On the first project I worked I did quite a bit of refactoring which I generally received positive feedback for. The second project was a total mess and a new technology for me. In combination with poor ticket descriptions (and author being away) I ended up spending way too much time. The feedback from this was that I was taking too much time from others (trying to decipher tickets by asking around) and working on things I'm comfortable with (refactoring, cleaning up). — yesterday
As a side node: 90% of people consider themselves as above average (in what every regard). — 3 hours ago

score 209 · Answer 1 · 2018-10-22 13:52:05Z

Today I was fired from a software company.. for the 3rd time in 1.5
years. Needless to say I feel like I reached bottom and it's
impossible to get out without changing career. Should I change a
career? Is it even possible to find a job now?

Yup, that's pretty bad. But remember that you weren't sure anyone would hire you after being fired before - yet you ended up with this third job.

I think you need to look inward and determine for yourself why this is happening.

Don't blame "poor management" here. Something is going on in each case that resulted in poor performance on your part. In other questions you mentioned that you were fired for not asking enough questions and for not performing senior-level work. Hopefully there are things you can learn from all that.

It might be that you are choosing jobs and/or managers poorly. It might be that you haven't learned how to work hard, focus on what is important, and perform well in spite of issues at work. It might be that you are shooting for too senior-level of a position and are more suited to junior-level work. Or it might simply be that you are not well suited for this sort of job at all.

Spend some time on introspection. Try to come to a conclusion before acting. You likely can't afford to make the same mistake again.

You might consider taking a stab at temp work. Those might be easier jobs to get in your situation. Maybe you can motivate yourself to perform well when the projects are small and time-limited. Your past experience seems to suggest that you could.

I'm in my 30s without a fallback place, no family around and not many
friends.

That's something you'll want to work on independently from your work issues. We all need friends. And a good support group would help when you are having work issues.

Keep trying to be friendly and make more friends. Join a club. Socialize with folks from work. At least try.

+1 for Don't blame "poor management" here. - Even if that were true it is an awful pitch to a new employer. — Oct 17 at 20:53
@JoeStrazzere true but it's hard to be picky when you don't have a job in place already. Plus you can't tell what is going on internally until you work there. — Oct 17 at 21:34
Also you can still pitch yourself with those in mind. It's an easier sell saying "I perform slowly because of (thoroughness, refactoring, technical debt removal, etc.) reasons, and that has in the past been viewed as slow working" than saying "I was fired because poor performance". Be sure to refactor how you're selling yourself and ask questions in regard to pacing. It seems on first glance that you're in fast paced environs and that doesn't necessarily work best for you. Some employers don't need you to work super fast as long as the quality is there and the work brings value. — Oct 17 at 22:45
@JoeStrazzere, I feel your replies come from a somewhat privileged position. It's hard to be picky if you have no job and struggle to be able to buy food and pay your rent. If you're a person with plenty of experience in a field in which you don't need to fear unemployment longer than a month or two, that's probably hard to imagine, but it does happen. — Oct 18 at 7:36
The only things I'd like to add to this response: 1: while looking for your next place of employment, try taking courses to sharpen your skills, whether to be in refactoring, other coding practices, or even communication. 2: in the future, if you see code that should be refactoring, ASK BEFORE DOING. They may not want to spend the resources on refactoring. And finally 3: in future interviews, if they ask about the reasoning of 3 short employments, be sure to explain what you learned from it. "I learned to communicate more with my manager" sounds better than "I had 3 bad managers". — Oct 19 at 12:26

score 207 · Answer 2 · 2018-10-18 05:06:37Z

up vote
207
down vote

I spent a lot of time refactoring and trying to remove technical debt. I received a verbal warning for under-performing before going on holidays.

It seems here you were working on something that wasn't asked for. This is generally very bad, and can lead to termination. If you think the project needs refactoring, and I trust you that it did, you must sell it to the management before you can do it. If you had done that, I suppose the management would have acted differently.

You may have told yourself you can't complete your task without the code to be clean. Truth is, most companies' code isn't. They work with legacy, they try to move on with what they have...

I was placed to work with a technology unrelated to what I signed for

...and almost all of them will hide the legacy behind more appealing new technologies when interviewing.

I don't think this is in itself a signal you should change career. I would think you have no aversion to software engineering when it's done right. But engineering in a company is always a matter of dealing with software done wrong, with management pushing forward. If you want to last in a company, you must be ready to accept this.

edited Oct 18 at 5:06

answered Oct 17 at 20:45

Arthur Havlicek

1,7111312

20

I'd want to add that it would be good to get used to switching technologies. I'd say it's generally good to be able to adapt to any technology that comes along, and try to enjoy the challenge.
â€“Â Theolodis
Oct 18 at 6:20

100

This, this, this, this, this. If, as a relatively new hire, you're given Task A, do Task A. Don't look at the code and say "Oh, wow, that really needs refactoring" and work on Task B (refactoring) at the expense of getting Task A done in a timely way. Start making notes about what refactoring you think might be needed, sure, but wait. After several months of solid delivery on task and learning what the culture, start raising technical debt and refactoring with management on an as-needed basis, and get buy-in before spending time on it. (And be prepared you may not get buy-in.)
â€“Â T.J. Crowder
Oct 18 at 15:45

21

@T.J.Crowder exactly right. I don't know how many times in my career I have encountered awful kludgy code and found out it was done that way because seemingly more elegant solutions just didn't work. Anyone who would have rushed in to "fix" it would have broken it and wasted a lot of time in the process. Take the time to learn why things are the way they are. And remember your employer doesn't want "perfect" code, they want working code that lets you move onto the next thing. There is always a next thing.
â€“Â Seth R
Oct 18 at 16:53

11

TBH, I think the "tendency to clean up messy code" is a real problem in the entire industry, b/c messy is a hugely opinion based attribution. Many of our younger colleagues have that tendency. They often write code that follows some catchy rules from famous authors dogmatically (e.g. adding interfaces to literally every single class), which none of those authors would approve btw. Refactoring not a bad thing, but it isn't sth. managers hire people to do. Also: you shouldn't do it alone, w/o coordination and early after beeing hired. Also, not every messy piece of code is worth the effort.
â€“Â nozzleman
Oct 19 at 9:52

12

Also: there's a chance colleagues complained about you because they felt offended by your "optimizations" of their work. I once escalated a PR which removed all this-qualifiers in a C# codebase and edited the corresponding Analyzers, because the colleague found them to be superflous (which they technically are). While at it, he added underscore-prefixes to every private member variable as a "compromise". It would have been fine if the whole team agreed on that change of paradigm before it was done, but that way it was crap. He got fired for underperforming (finished not a singele feature).
â€“Â nozzleman
Oct 19 at 10:00

Â |Â
show 10 more comments

score 146 · Answer 3 · 2018-10-18 11:21:11Z

Understand why you're getting fired

You've said it yourself. You're focusing on rewriting, when that isn't what you're there to do. You have a really bad case of Not Invented Here syndrome. As far as management goes, the problem seems to be about whether you're prepared to do what your manager tells you and get your work done, or whether you're going to play about with things you think you'd like to do. And faced with a new challenge, it looks like you run away.

When you get over this, then you'll be employable. Until then, frankly you're just causing damage to your employers and to your own reputation. Your employers can usually survive this, but you won't.

Let's look at your resume...

Case 1: Fired from a fintech company on the 2nd month for not performing... lack of motivation.

If you knew this wasn't something which you could focus on, why did you take the job? And if you didn't know, why didn't you resign with dignity instead of wasting everyone's time? This is the one which really concerns me.

Case 2: Fired from a web platform company for not performing... technology unrelated to what I signed for...

The nature of a technical job is that there will always be things you haven't worked on before. If you've not seem that technology before, own up to that, and make sure estimates are adjusted accordingly.

But "not performing" doesn't usually mean that you missed deadlines, it usually means you've been caught slacking off instead of working. In a technical job, I'd expect someone to be excited about learning new skills, or at least be diligent about it. If you're going to run away from anything you don't already know, then find a new career.

Case 3: ... spent a lot of time refactoring and trying to remove technical debt... Have a tendency to cleanup messy code, refactor and ensure things are well tested...

And this is where we see you playing about with things you don't need to. You call it "messy code". The rest of the company called it "working code". I come from a safety-related engineering background. In this line of work, people can be disciplined for fixing bugs. Seriously. The problem with "fixing" a bug is that you need to prove your fix hadn't broken anything else. In the context of retesting an entire car engine and transmission, a minor bug which maybe causes a 1% error in fuelling for one processing tick after an hour's running is most likely completely acceptable, but the cost in money and time of a full retest of the whole system probably isn't. That's before we even get to fixing "messy" code, where your allegedly-non-functional changes may turn out to have side effects due to a missed comma or something equally silly.

In short, you're being hired to do a professional job. So far, you've demonstrated that you aren't able to be professional. When you can go into an interview and present those failures as learning experiences which have helped you turn your mentality around, then you're good to go.. Can you do that...?

This answer has good points about code cleanup you're not asked to do and the bugs you can easily introduce in the process, especially if automated test coverage is low. However, I think "Not Invented Here syndrome" doesn't apply to code refactoring; that's more about re-implementing an existing solution you could reuse from e.g. a software library. — Oct 18 at 3:03
This makes a super important point about this "refactoring". If you're new to a company and haven't spent time working within their existing code before you start to try to "refactor" it to meet your personal code quality standards, there is basically a 100% chance that your ignorance of the product will result in massive bugs. You're going to have to produce meaningful work before having the experience to know what you can safely refactor. Also, your coworkers are not going to be happy code-reviewing your sweeping non-functional changes while they try to actually meet their deadlines. — Oct 18 at 4:10
@JimG.Maybe I should be clearer and say "a 1% error for one processing tick". But yes, an occasional glitch which a customer isn't likely to notice and isn't going to cause problems during emissions tests is absolutely acceptable. I've been through enough bug triage meetings with various automotive companies. :) — Oct 18 at 11:20
I completely agree with this answer. If a painter came to your house, he wouldn't tear down the entire wall and start putting in a new one just so he'd have a fresh surface. He'd work with what he got. Part of being a professional is doing what you're told and working with what you got. If you have a problem, bring it up and get everyone to agree with you before you do otherwise. — Oct 18 at 14:55
To add to what @Dan said, I would expect the painter to recommend to me that I get him or her or someone else to apply a skim coat of plaster if the wall was in poor condition (this happened to me literally a month ago), and then it would be up to me to decide whether to go ahead with that or just let the painter do the best they can with what's there (this is what I did and it looks great!). The analogy is that you can recommend refactoring, but unless you have complete control over the project and time left to achieve the main goals, unless you have sign-off don't do it. — Oct 18 at 17:31

johncip 40927 · Answer 4 · 2018-10-18 09:09:29Z

I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

I'm going to go out on a limb and assume this is more than the usual boy scouting. So:

I have a tendency to choose to cleanup messy code, refactor and ensure things are well tested, whenever they are "adjacent" to something I'm writing, and to prioritize this over shipping, regardless of what I've been tasked with.

Tests and refactoring are great, but it's never 100% one person's call on how much emphasis they get. The code is a means to an end -- it's not just there for your enjoyment, it's there to serve business needs, and the folks who work closer to those needs (the management) are in a better position to set priorities. Plus everything you change is something that you could potentially break, tests or no tests -- to say nothing of the extra review burden.

Regarding a career change, I think that there are two things to consider. The first is that if you are consistently insubordinate, it won't matter what career you're in. Line cooks who "improve" recipes get fired too. In other words, you're potentially being fired for not focusing. Your impulsivity could easily follow you into a new career, so switching will only pay off if you address your focus first. The second is what you mentioned about lacking motivation. What might be causing a lack of focus is if you perhaps don't like coding beyond cleaning existing things up, which is completely understandable. But if true, it means that a fourth dev job would just be signing up for more torture (assuming it's working on a team & on an existing codebase).

But I would make doing what you say you're going to do your top priority, and go from there. Done properly, this also means not taking on obligations you don't think you can meet. Who knows, maybe you'll discover that you'd rather bake bread. (It's just an example, but I think it's a good one -- it's a craft, it involves troubleshooting, it rewards perfectionism, and you generally do it yourself from start to finish.)

Anyway, the important thing is that if you're asked to do a job, and you accept it, then you do it. Later, if it turns out it's not for you, then bow out gracefully and try something else. But doing that "something else" on someone else's dime, while they think you're doing what they asked of you, is just going to piss people off, in any line of work.

In general, developers don't really like writing tests and doing refactoring. At least not 90%+ of time. If that's something that the OP enjoys, maybe he can find a company where he gets to do that full time. I'm going to confidently guess that there are plenty of companies out there who want at least some of their developers to do such work but who find it difficult to motivate them in that regard. — Oct 19 at 14:52
Sure. A place with strong engineering culture will have higher standards, but at the cost of more opinions to navigate and more conventions to bow to. (I personally prefer enforced style rules that I "don't like" to none at all, but not everyone thinks that way.) I'm a neat freak myself, but have had to learn that not everything I write will be some objet d'arte -- esp. given that some "great" things I've written in the past make me cringe now. It's 80/20, as with everything else, and shipping comes first. All that said, maybe OP would dig being on a dedicated testing team? — 3 hours ago

motosubatsu 35.2k1591144 · Answer 5 · 2018-10-18 15:24:16Z

Ouch

You don't need me to tell you that this isn't good so I'm not going to belabour the point but it's worth a quick look at the three firings:

Case 1: Fired from a fintech company on the 2nd month for not performing. This was correct since I had a lack of motivation.

Nothing to say here - you know you messed up. Something tells me that lack of motivation won't be a problem for you now!

Case 2: Fired from a web platform company for not performing. I was placed to work with a technology unrelated to what I signed for, so this seems like poor management from my side.

While it's not ideal management to be putting new hires on tech they are unused to I'd be wary of blaming this all on that - it takes two to tango as the saying goes and I'd be surprised if there wasn't more you could have done to avert this as a firing but let's call it 80-20 their fault.

Case 3: Fired on 6th month for poor performance. During probation I received positive feedback. After that I changed project and I spent a lot of time refactoring and trying to remove technical debt. I received a verbal warning for under-performing before going on holidays. In the 4 days I had I tried to fix that by staying overtime and finishing all due work. However when I came back from holidays I received a termination letter.

Sorry but this one is all on you - refactoring as you go is not bad in of itself, and it can be a very efficient way to clean up a code base without completely stopping forward development for several months. But doing it when you don't have direction or at least approval to do so (including the additional time it takes) is not a good idea. From the employer's perspective it looks very much like you worked to get through probation and then slacked off afterwards (I realise that is not what you did - but that's what it looks like).

Generally the issue as I see it, is that I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

You've identified the likely cause of the "poor performance" views but seem to have not quite got there in realising that this actually is poor performance. Consistently failing to make estimations (assuming those estimations are realistic) isn't just "seen" as slow performing, it is, by any definition of the term slow performing! If a user story/ticket/whatever has an estimation of 6 hours to complete and it takes you 12 hours because you spent an additional 6 hours doing activity X then it doesn't really matter what activity X is, whether you were refactoring or watching cat videos on you tube it still took you 6 hours longer to do your assigned task then was expected.

The good news is that you basically have the skills and talent you need to succeed at coding - you just need to shore up a couple of things in your approach. Spot something that would benefit from a refactor when you're working on a task? Great! That skill can be turned to your advantage rather than a thorn in your side - all you have to do is talk to your manager/team leader or whoever manages the planning and resource allocation and say what you've found, what benefits you think it can bring to the business and how long you think it will take you to do it.

If they agree it's worth the time investment they can account for the extra time, you don't go over estimation, and you look like a rock star for being proactive in helping the company.

I love having coders reporting to me that do that!

However..

You have to accept that sometimes they are going to say "No" or "Not now" to these requests - that's because they deem the timescales for completing the original task to be more valuable right now, and like I say you need to accept that response because there's nothing wrong with them making that call, because that's what they get paid to do.

Unless you are 1110% certain that not implementing your proposed refactoring immediately will have dire consequences for the company then you don't push back, you don't argue. You do what you are being paid to do, if it blows up on the company later then, frankly it's the responsibility of the person who decided not to do it - again this is what they get paid for!

So where do you go from here?

I don't think you need to change careers right now - like I say it sounds like you've got the skills and while your recent job history is, to be blunt, pretty damning. It's not irreprable and with some hard work and a bit of luck you can get the ship righted and be back on course like it never happened.

Here's what I'd do if I were you:

Go contracting (this would be my recommendation) - work history matters less than having the skills in the contract word, and people are more likely to take a punt on someone for a contract then they are for a perm position as it's easier to drop them and get someone else if they make a bad hiring decision. You've got a fantastic buffer of savings that's going to give you time to give it a shot - set yourself a deadline: if you can't find (and be successful) in a contract in 3 months then you can widen your search to include perm positions. I've not had it take more than three weeks to secure a contract position so far, and I'm appalling at interviews, so you can do this! One good contract of 6 months and very few people will care about your last three perm jobs! And on top of all of that even if you have to look at the lower end of the market in terms of day rate for your first couple of contracts you'll probably be making very good money in real terms.

or if contracting really isn't something you want to do:

Stay perm - take a step down the salary ladder

At the moment getting some good work history under your belt is more important than maximizing wages. Work out the lowest realistic amount you need to live and start applying for jobs in that bracket. There's always companies whose hiring ambition exceeds their budget, and they tend to be less choosy. Even if you're taking a Ã‚Â£5k cut off your potential you'll be able to earn that back in the long run by just sticking it out for ~2 years and performing well. I'm not saying it would be fun, or easy, but it would be very effective.

Don't give up - you can do this!

I'd also like to add that refactoring can also be a significant risk. You are making major changes and any time that happens there is potential for things to go wrong. Even if they are a good and experienced programmer the OP hasn't been at these jobs long enough to have the context and history necessary to minimize the risk of these refactors. Most people don't find maintenance program much fun but it is necessary and a skill people should learn. — Oct 18 at 23:17

Andy Lester 892511 · Answer 6 · 2018-10-18 16:40:39Z

I'm guessing that not listening is a key problem. Not just hearing words, but understanding and taking them to heart.

This jumps out at me:

Generally the issue as I see it, is that I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

"That can be seen by many as slow performing" isn't the important part. Your company told you it is slow performing, because they fired you. If your boss says to do something, you do it. If your boss says not to do something, you don't do it. If you're unsure, then ask your boss and do what she says.

As a rookie in the business world, it's not your place to decide what the company should be doing. When you decide on your own to go doing code cleanup, you're telling them company you know better than them. Don't do that.

As a developer for 32 years, I know that it can be frustrating to leave tech debt, to leave messy or undocumented code. But if that's what the company wants you to do, then do it.

Phill 27917 · Answer 7 · 2018-10-19 08:37:52Z

I realise there are already 16 answers here, many of them excellent, but they don't seem to have addressed that there is a small possibility that there could be other reasons for being fired.

It might just be that these have been convenient excuses for your firing. It is never nice to point this out, but it's worth examining if you are fitting in on a personal level.

I've known (of) a few people who have been through several jobs in a short time and they can't see why. To me (and others) it has been obvious - they have a habit or trait that grates on the people around them. For one of the guys, this was a habit of loudly clearing his throat all the time, coupled with not taking the hint when people wanted to end a conversation. I worked in the same office as him and I can tell you, the atmosphere after he left was so much nicer. Another guy, it was a hygiene problem. They both got fired for what sounded reasonable, but you knew in the back of your mind these other traits definitely factored into it.

I'm not saying you have any of these characteristics, it could even be a culture clash, not something that's even your fault, but as other answers suggest, a period of introspection is very valuable here. I would extend that to look at things like personal habits and traits to check if they could be the hidden cause.

score 8 · Answer 8 · 2018-10-17 21:41:34Z

You could always teach computing in high school if you think your industry career path is limited. There are other things you can do like project management too.

But when you do apply for another position, don't explain your firings as management problems. Even if the manager was completely responsible for what happened, you will give the impression that you aren't capable of assessing your own mistakes and weaknesses.

Write a short cover letter with your new applications and explain what happened. Take responsibility for it regardless of the reasons. Explain why things will be different.

You might have to take contracts for a while. Trust me, I've seen contractors come and go a lot.

Once you've re-established yourself, you can start building your career as a successful employee.

NEVER think your options are limited because this will only limit your options. Its cliched but you have to keep a positive attitude.

Thanks for the suggestion. But as I see it.. who would like to hire someone who got fired thrice as a dev, as a project manager? — Oct 17 at 21:33
You cant think that way, even if you decide to become a teacher. You can always shuffle your resume around - you are only talking about 1.5 years. Fill the gap in your resume with teachers college or something similar. — Oct 17 at 21:36
Also i wouldnt necessarily abandon your current career path. — Oct 17 at 21:36

l0b0 1,8681913 · Answer 9 · 2018-10-18 07:20:54Z

I know the feeling of wanting to spend a lot of time improving code quality to increase the speed of development. They can absolutely save massive amounts of time, up to and including making complex projects doable in the first place. However, I would be careful to introduce those slowly when starting a new job.

Expect it to take months to build up enough context (from developers, users and managers as much as from code) to learn where the biggest (not just the big) pain points are. Once you have a solid understanding of these you should be able to present a case to your manager for working on one of them for a short period of time to massively improve some aspect of the code. And when you nail one of these you really show why they should keep you. You don't have to be a fantastic developer to do this - everybody with a bit of experience has skills that the rest of the team lack.

Before all of that, though, I would focus on getting the day to day stuff done. I've worked in places where developer quality assurance was so poor that we spent almost all our time putting out fires. It's not fun, but unless you can make the money roll in faster management isn't going to be interested in cleaning things up.

As a final note I've had several bad jobs as a software developer, but others have been great fun. Personally I would recommend research institutions and smaller companies, as they are in my experience flexible in how they work and at least somewhat interested in QA.

BittermanAndy 93115 · Answer 10 · 2018-10-18 15:16:23Z

Much of what I'd ordinarily say has already been said. But there's at least one path open to you that I don't think anyone has given as an answer yet.

Consider contracting / self-employment.

Many of the other answers have focused on how you can sell yourself to your next employer, how you can explain away your short stay in your last three roles, and what you might do differently to keep your next job. All of which is true, but finding another employer doesn't have to be the only option. What if your next employer was... you?

Pros:

You don't need to explain anything or justify what happened to anyone else.

If you are genuinely good at what you can do, your skills will be in demand, at a rewarding price.

You already have six months of savings - that's long enough to find clients and get started.

Once you have a few clients, you can pick and choose what you want to work on (i.e. which clients to take on), rather than whatever your employer tells you to work on.

Cons:

You will need to run your own business and sort out your own taxes, as well as developing software.

If you are not as good as you think you are - or if you can't find motivation to do what the clients want - or if you waste all your time making neat code with no technical debt when the client just wants working software - you might burn through all your savings and end up back exactly where you are now, except your savings are gone. This is a real risk. You will need to take a long, hard look in the mirror before you take this route. But I suspect you'll need to do that no matter what.

Hang in there. Plenty of people reach their 30s and find things haven't turned out as they expected. It's not too late.

Indeed - intended to be covered by "if you are not as good as you think you are". — Oct 18 at 15:21
I was in a similar situation as OP and for me self-employment is the only way I can make money with programming. I did two fixed-price jobs that my client was happy with. It was better than working for a boss, but I still didn't like it enough. Now I do all kinds of work to make a living. Some jobs are really not that bad, especially when doing part-time. Meanwhile I'm developing one big software program (no client, own idea) that I can sell and improve when it's finished, so I can even more do 'my thing' instead of following orders. Perhaps a similar approach will work for OP. — Oct 18 at 19:33
"Nobody likes poor performing contractors" - absolutely. And the fastest that I've seen a contractor fired for potential poor performance (i.e. he clearly didn't know what his resume claimed he knew) wasn't "2 months". It as TWO HOURS. He showed up at 9am on Monday morning, and had gone for good by lunch time. Contractors don't get kid glove treatment like being "on probation" or "put on an improvement program". They hit the streets unemployed FAST. — Oct 18 at 21:40
Pro: Contracting over many projects will allow you to see the "messy" code again and again on various assignments and on this pain point you will either totally fall out of business or you will learn not to care about it too much Ã¢Â€Â“ effectively giving you a cure of unhealthy detailism. — Oct 18 at 22:50

Ruadhan2300 3974 · Answer 11 · 2018-10-19 09:15:50Z

It seems to me that your problem is that you do things your own way. You have this pattern of behaviour where the way you're doing things is "the right way" and anything that indicates you need to change bounces off that. Fortunately, your way is actually pretty good, you have a strong work ethic, good ways of working and you're not wrong about it being The Right Way. The issue is when this clashes with the priorities of your employer.

Your first firing was by your own admission a lack of motivation, FinTech is pretty dry material, I certainly can't blame you for losing interest in it, I'm sure it wouldn't hold mine. I won't ask why you went with it in the first place, I was applying to FinTech jobs when I was applying to my current place of work, a job's a job.

Call it a bad fit and lesson learned.

Your second firing was down to being asked to do stuff you weren't originally hired to do (at least by your understanding of your contract) and being unhappy with that.

This is not uncommon, I've had to deal with jobs where a great deal of my time was spent not doing the material I'm trained and skilled at, this is definitely mismanagement.

However if you're required to learn a new skillset or toolset on the job, that's part of the job.

I'm sure I don't need to tell you that the software industry is constantly fluctuating and keeping up with the latest stuff is vital to success. Just this year alone I've had to learn Web Development from scratch and picked up Vue.js, JQuery and Bootstrap from scratch, last year I learned Xamarin and became an App Developer. Before that I was building mobile and Facebook games in Unity3d and Flash.

I've worked in Agile and Scrum, independently and waterfall model teams.

What I need, I learn.

If you can't currently do that, you need to learn to be adaptable to if you want to succeed in the software industry.

Your third firing is the one you write most about, The problem is much clearer there.
You knew that the right way to write code was to do it properly first time, spend the time up front and it'll save time and money later. You're not wrong at all. Good job on that.

However you were given (I assume) clear tasking and because you spent time off-task, you failed to consistently deliver the work you were asked to do.

Going off-task to fix related code is something I do all the time, however it's critical not to get lost down the rabbit hole. Remember that the last 10% of a problem takes 90% of the time. Open up the problem code, patch the part that's causing the problem, add a //TODO to fix it properly, write a note somewhere that it needs more attention later and move on. Usually 90% is good enough.

Your #1 task is always to deliver the material you were told to do, and as a new-hire, you have far less unilateral authority than you might like. I've gotten in trouble myself for this same issue and it's sometimes hard to go through the hoops to get it done by the book.

This is probably your biggest problem. You need to do things the way your employer wants you to do them. If you feel your employer is underestimating how important something is, explain it in terms of time and money and if they still don't agree. Accept it.

The employer is your customer, and as the pithy saying goes, the customer is always right.

In conclusion, don't give up. You've clearly got the skills and ability to be a great programmer, you just need to find a job that interests you and get better at triaging problems while paying attention to the priorities of your team.

I fully back this answer. On the long run, after that refactoring urge gets under proper control, the OP may eventually end in those companies which "deserve" values found in his approach and stay away of those which only continue rejecting these suggestions to their own bad. For me, openness of a company to reasonable refactoring (including how they are coping with their obviously messy projects) is one of questions which I ask the interviewer(s) when I am hunting for a new job. — 23 hours ago

IT_observer 391 · Answer 12 · 2018-10-18 18:04:59Z

These days, employment in the tech world is kind of a game.

I am going to guess your company follows the AGILE methodology.

They key is not to do whatever you feel like but to do what you are assigned.

And do not be shy about standing up for more points, and asking for more time.

It is MUCH better to demand more time and getting more points for your tasks AT THE BEGINNING than to slip.

Management has 0 clue about the difficulty of your tasks.. they just go by the initial estimates.

if you don't fight for points up front .. you are screwed.

Iron Gremlin 3476 · Answer 13 · 2018-10-18 19:32:02Z

You have issues maintaining focus and motivation when dealing with other people's code.

I sympathize with this - It's hard to continue shoving new features out the door without cleaning house and still feel like you're contributing to something you can be proud of.

But, unfortunately, that will be true of the vast majority of organizations that will hire you to write code. I'm not going to tell you to 'get over it' - I imagine that, unless you are profoundly bad at self reflection, this option has already occurred to you.

Instead, I would suggest that you consider using your technical knowledge for a career in software development that doesn't involve writing application code as a core focus.

You may find more enjoyment, fulfillment, and an easier time focusing as a QA Engineer and/or a DIT. You will still get to write code and solve many of the same sorts of engaging puzzles, but your CORE focus and responsibility is improving the quality of the product. That seems more in line with the initiative that you've shown here.

It is my experience that in these types of roles, you usually have a smaller team, a smaller section of the codebase you're responsible for, and therefor much more latitude to refactor aggressively. Additionally, if you do your job right, not only do you write code you can be happy with, you also help measurably improve the quality of what actually hits production.

It's also comparatively easy to sell that transition to a potential employer in those terms - You had difficulty as a software developer because you spent to much time focusing on what essentially amounts to quality control, so you decided to switch focuses to just doing quality control.

Dr Z 411 · Answer 14 · 2018-10-19 18:37:23Z

No answer so far seems to consider the possibility that you've been very unlucky and got 3 awful jobs in a row. There definitely ARE some really awful jobs and unreasonable managers out there. I've had several, but not so many in a row. Sometimes they are very hard to spot during the interview; in some cases, job descriptions and things said in interviews are totally inaccurate and misleading. So, it's POSSIBLE that this is not your fault; but only you have enough information to be able to judge this.

In the end, though, it's most likely that you'll have a bad job to start off with (tedious, poor management, low pay). You just have to tolerate it for a few years, so think carefully about what you are willing to put up with in a job, and perhaps lower your expectations.

virtualskill 451 · Answer 15 · 2018-10-17 22:44:55Z

Okay, so we can agree you've hit "the bottom" of your career path. So what? There's only one direction you can go from there, which is up!

Whether to continue in your current career choice or not depends entirely on if you actually ENJOYED it.

If you did NOT enjoy it:
I recommend that you do not continue this career path. You should take a small job elsewhere (even a menial one) to build up funds to pursue something that interests you more.

If you DID actually enjoy your work:
You're at the "bottom", right? So hit reset! Start again from the bottom, and this time do it correctly. Start applying for software jobs as a Jr. level developer (or even an intern, if you have to) at any software company whatsoever. This time, work really hard to rebuild your reputation & resume, as well as impress your new employers.

In either case - I recommend that you don't even mention those previous software jobs on your resume - they aren't doing you any favors. A hard reset is best here! And there's no shame in trying again and working hard at it!

Insanity is repeating the same thing over and over and expecting different results. Not saying that the OP shouldn't get another job in software development, but they need to get a better handle on what went wrong and how to avoid repeating it first! — Oct 18 at 14:56
@user3067860 I'd say this is the most important comment I've seen on this question. 1) Get a handle on why these jobs failed, 2) figure out how you can prevent it from happening in future, 3) get a new job and put that plan into practice, 4) Profit. — Oct 19 at 8:29
I'd like to point out that while @Johanessburg isn't in the best place, this is very far from being the potential nadir of their career path. Things can get a lot worse than this. Six months of savings, years of experience in the industry and a demonstrated strong technical mindset are all very good assets. What OP needs to operate without changing themselves is a project where the priority is robust code over quick results and they're given essentially free reign to work as they need. This isn't exactly common place though, it'd be better to adapt to the workplace. — Oct 19 at 8:36

Dan 5,85321323 · Answer 16 · 2018-10-18 17:10:28Z

It sounds to me like your only issue is not being able to do the tasks you were given. In all your jobs that you got fired from, you state that you did not do the task you were given and focused on doing something else (refactoring, etc). Unless you bring these things up before you get to the point where you'd miss deadlines, I wouldn't do it.

Always remember people think the worst in every negative situation. So if you miss the deadline, and have multiple files changed (even though it takes less than that), they're not going to think anything good about it. Be sure to communicate issues you see and get permissions to do something else from your manager before you even do it. Don't just start doing some other task.

I think if you follow that advice, you'd have a successful career. At some point, everyone would trust your expertise and focus on making the code better. But as the new guy, who nobody knows about not doing a simple task and refactoring unrelated code, that just won't fly.

Bombaybard 544 · Answer 17 · 2018-10-18 21:21:58Z

IÃ¢Â€Â™d advise to take a break and work on your self. Especially the lack of a positive friend circle and an inactive social life seems to be a huge contributing factor in your life.
Do you feel burnt out or lonely?
Have you tried reaching out to a therapist or a mentor to check if you are suffering from any kind of depression or ADD?
Are you comfortable working under authority?
Have you given thought to work freelancing or part-time?
A lot of people hit a plateau in their 30s/40s. And coding can be a soul-sucking job at times. Try and explore your hobbies or a related field close to your domain expertise.

The problem does seem more pertinent to your personality than your field of work. IÃ¢Â€Â™d strongly advise taking a break and go soulsearching until you find the motivation to be a part of another team.

SmallChess 1,4993620 · Answer 18 · 2018-10-20 09:17:56Z

Software programming is quite competitive. I mean anyone with a laptop can do it. Please don't feel sad for losing the job. There're things better than being a coding monkey.

Please consider commence a PhD degree on something you would like to do. Science is quite hot. A post-doc position in science will allow you to apply for your own grant from something like NHMRC. Nobody will be able to fire you if you are able to secure your own grant (it's your own money).

It'll be a perfect career for you. No longer any possibility being fired. Furthermore, everybody will be calling you a "doctor". "DR ..."

This. Some people are not a good fit for industry, but they are a good fit for academia. Perfectly addresses the question, "What to do" — yesterday
As far as I read Academia stack exchange, it is my definite perception that PhD is a tons more competitive path. Everybody bemoans shortage of good programmers, not so about post docs. — 5 hours ago

score 2 · Answer 19 · 2018-10-22 23:55:41Z

As a developer who also values clean, well tested code, and despises code debt, I can understand your point of view. However, you are being paid to complete tasks as assigned. Work isn't about doing the thing you want to do, but doing the thing your employer expects of you. It's a bonus when you can find enjoyment in doing the things for which you are being paid. Having a good work ethic requires the development of self-discipline to focus on the task assigned and get it done to the satisfaction of your employer, whether you enjoy doing it or not, whether you find satisfaction in doing it or not. The rewards you can take from this are (1) getting paid, (2) having some measure of security that you will continue to be employed, (3) perhaps learning something new and useful, (4) building respect in the organization that you might be able to leverage to eventually do things more to your liking and/or satisfaction.

If you think that important tasks are being left un-done (refactoring, reducing code debt, improving test coverage), by all means mention it to your supervisor. If it can be done in the course of completing an assigned task without delaying the completion of the work assigned, great. If it can only be done at the expense of the task assigned, leave it.

Something else to consider: business decisions are made based on whether they increase revenue or decrease costs, and generally have a short horizon. It's not uncommon for businesses to focus on results for the current or next quarter. A lot of investment money is moved around on the basis of quarterly results; this is what steers business decisions. The improvements you feel motivated to make to the code base are a longer-term investment without a quantifiable benefit. We both know it's a good thing, and for a business that is in business for the long haul, it's the right thing. However, businesses don't make decisions based on what is right or best in the long term, they serve their masters - the investors.

score 2 · Answer 20 · 2018-10-23 01:10:06Z

I know there's already way too many answers to this question but I just wanted to share my experience based on Joe Strazzere's suggestion you consider temp work.

You said you're based in the UK, the contractor market is booming there right now. In London you can earn around Ã‚Â£500 a day. The nice thing about this is that you will never get tired of the place you work and start dragging your heels, every 3-6 months you'll need to find a new contract.

This might be a solution but equally you might not be well suited to the fast pace of contractor work. Personally I really enjoyed it and after my first 6 months contracting for the BBC I had enough savings to go fully freelance and work from home.

Ultimately what you should aim for is to get some good clients and work remotely. Then you have complete freedom to refactor your code so long as you're delivering projects on time. Personally I was never more motivated than when I ran my own company. I would work 12 hour days, 6 days a week.

But I also get the feeling you're not 100% satisfied with your career, maybe it's time to take a break?

You have savings, why not go traveling and spend 3-6 months thinking about your next step? One awesome way to travel is using workaway, I've volunteered in Spain and Japan using it. You'll meet a lot of people. https://www.workaway.info/299958546294-en.html

Curcuma_ 374 · Answer 21 · 2018-10-17 20:04:25Z

This is a broad answer with many suggestions:

Try to lower your expectations, there must be a job position right
for you in IT.

Maybe you should question your agreement on responsibilities at
first time.

Communicate whenever there are blocking issues. Speak out your mind while staying professional.

When not enough motivated, this is generally your problem, so try
requesting short vacancies breaks dispersed along the year, rather
than taking few long vacancies (this may help, or may not).

Personally this helps keeping myself focus, energetic and motivated knowing that I don't always like my tasks and I am in IT.

You can try part time jobs knowing that you have savings for up to 6 months, then it could be extended to more ! while keeping competitive spirit, and an updated resume.

Changing roles, in big companies is sometimes easier, if it would be a possible case for you, this could be very motivating.

I don't know your background and profile, but there are missions in IT enveloping less technique like promoting IT products, organizing awareness sessions on new technologies for other colleges, writing documentation, cleaning old code (for developers), establishing new proof of concepts, project ideas, participating in challenges and trying to be on top for the name of your group ... etc etc, see there are many things a developer for example can do in IT.

This is a list of more freedom option I can imagine for now.

Jason Hutchinson 1194 · Answer 22 · 2018-10-19 20:44:15Z

There are a ton of really great answers here, but I do have additional insights that you may want to keep in mind when finding/keeping the next job.

First of all, do not ever give up on your dreams. You have invested a great deal of time, and money I assume to get onto this career path; quitting at this time is not the right thing to do.

The best thing you can do now is chalk all of this up to experience, and do better next time. A common belief amongst fledgling developers is that their programming skills are superior to their predecessors. This may be true in some cases, but even if that was true, other more senior programmers do take a great deal of pride in what they have created, and get offended when some new guy comes in and starts trashing their programs.

In the business world, software development is taken very seriously, and there are real consequences in putting out a bad product. Business depend on their products being reliable, and one tiny defect could cascade, causing huge problems downstream. You don't want to be that guy. In the financial world, a tiny mistake could cost millions, and even bankrupt a company. So... business owners are typically very protective of their code, and they don't want anyone tinkering around with something they are not supposed to be touching.

Try to just focus on the specific tasks at hand and have a clear understanding of the expectations. Do not try go above and beyond what is expected of you, at least until probation is over. Just show up every day on time, do your job without affecting others, and have a good rapport with your coworkers, and you will not get fired. Remember, you are not just being hired for your programming skills, that only gets you in the door. If you want to succeed, then you must also work on your soft skills as well. Your success hinges on having a good attitude, and getting along with others.

mathreadler 26119 · Answer 23 · 2018-10-19 21:05:12Z

You realized the code was bad.

You acted on it trying to improve the code.

The managers did not appreciate this.

Well in some places your real help just won't be appreciated and they just want you to solve made up problems just to feed their sense of accomplishment. This might be one of these situations - I don't know for sure. If that is the case then there is not much you can do. You realize it is made up mumbo jumbo and you choose to try and do your best whatever you can that could benefit company.

I would say keep at it. Until you find a place where that is appreciated. Such places do exist.

ErikRauch 1192 · Answer 24 · 2018-10-19 22:52:32Z

Don't give up!

To add to what others have suggested: Imagine you were working X years at a company and a new-hire showed up and started indicating (through words and actions) that the existing work (that you and your coworkers had been working on for years) was "sloppy"/"worthless"/"had to change so new employee felt comfortable", how do you think you (and your co-workers) would respond when asked by the managers for your feedback on the new employee? I can't imagine anyone responding with: "Yes, I love working with him, and he sure knows his stuff". I would imagine the feedback being more: "Arrogant, know-it-all, does not seem able to integrate with the team"

I've always cringed when I hear a new employee say something along the lines of: "Your existing code/product/process is crap/bad/wrong. My ideas/methods are better. I know right from wrong, but you don't. I can do it right, where you could not". I always have a sense that new employee is not going to make it past any trial period (& I've seldom been wrong).

There are many reasons for the code being the way it is, including bringing along legacy work, time constraints, sloppy programmers, adapting to shifting specs, working with legacy HW/SW/systems, etc. The code is, however the product of that group/company and they will have some pride of ownership and likely even some empirical proof that it works "good enough" to make them $. You might even be dismissing the efforts of other members of the group (or even the manager). You might even be spot-on in your evaluation, but that can be totally irrelevant. Programming in perm positions is also about working together as a group (and that group includes your manager).

If you want to work as a perm in similar groups, consider what you can change (at the core mentally) so the other members of the group give your manager feedback that confirms their decision to hire you, and indicates that you will make the group better with fewer avoidable unpleasant surprises (for both your manager and the company).

I vote this up since it gives a good perspective from the other side.. — Oct 20 at 9:41

score 1 · Answer 25 · 2018-10-20 21:35:25Z

If you decide you want to continue as a developer, and I sense you do, as you evidence pride in your accomplishments outside of these three jobs, take concrete steps to address your limitations, so that your strengths finally begin to shine for your employers.

First, may I suggest your lack of focus is caused by a lack of daily organization? At your next job, make sure you know the top three priorities your boss has assigned you (and their relative importance) at all times. At the start of every workday write down your current priorities, and at the end of it summarize what you've accomplished against them. Don't be verbose, make each priority and accomplishment description as short and sweet as possible with only the minimum required detail. Something like...

Start of day

Implement new feature A

Write unit tests for A

Build new A release with documentation for testers.

End of day

Implemented A

Wrote unit tests for A, and fixed bugs so it passed all tests.

Was not able to release A, as I spent two hours supporting Sales on a priority customer issue with product.

And the next day your first priority would likely be

Build release A and write documentation for testers.

...

Every Monday morning do something similar for the week. First write down your planned goals/priorities for the week, and then refer to it every morning when writing daily priorities so they are in sync with your weekly commitments.

Also recap and summarize what you accomplished the prior week, using your end of day notes from it. Then send it to your boss as your weekly objectives/accomplishments so they know what you did and are planning to do. This way they can offer course corrections if you are wrong or priorities have changed. And when you first start your new job, the first few weeks you could even send your daily morning priorities with yesterdays recap to your boss to build their confidence in you even faster.

Just make sure that you don't make weekly goals too aggressive, you don't want to constantly be missing any commitments your boss sees, even if they are artificial ones you set for yourself. Break them into "Commitments" that you are very confident you'll get done, and "Stretch Goals" that you communicate you are hope to get to if week goes well.

By self-organizing this way, it helps you accomplish several important things.

The start of every day you will be refocused on your assigned priorities and commitments, making it easier to resist refactoring and doing other unassigned work.

Forcing yourself to recap accomplishments at the end of every day makes it very clear when you've backslide, again helping refocus you on your assigned priorities.

Sharing them with your boss helps them view you as a dependable and predictable team-member that makes them look good to their boss and is helping them reach their own goals.

I actually do the weekly report myself for my boss every week, and he loves it. It's actually reduced the amount of communication we need as he has developed a lot of trust that he knows what I'm doing and can easily redirect me if priorities change.

I don't do the daily workday planning/recap, but I'm recommending it because after reading your post I realize we both need it. Like you I have a tendency to get misdirected into refactoring code and fixing problems that aren't necessarily high priorities for the company. And a week is a long time, it's easy to forget some key goals midway through the week and only realize they were missed when recapping the week on Monday. So as I wrote this to you, I also assigned myself repeating daily reminders to do both.

Lastly, if my recommendations don't seem like it will work to keep you focused on the right priorities every day, that's okay. But make sure you find another system that will. Even if you move to another field, focusing on your boss and company's expectations every day is a key factor in succeeding in whatever career path you choose.

When you have to explain why you didn't succeed at your previous jobs in your next interviews, a great answer is that I'm a perfectionist who had trouble staying focused on the right priorities, so I've dedicated myself to turning that weakness into a strength by organizing myself rigorously, and this is how I do it now and will do it for you.

Lastly, you are going to succeed! You've shown you have what it takes already by doing the self-analysis that led you to write this post. You have the desire, you have the ability, you only need to add the focus and organization. The problem is becoming clear to you and you have the ability to solve it. I look forward to your future success and hope you post updates so we can all share in it.

Best wishes,

Randy

Edit: Never forget that Steve Jobs was fired from Apple and the lessons it taught him made him a far better CEO the second time around. Edison was fired from Western Union, and failed a thousand times before perfecting his light bulb. Walt Disney was fired by the KC Star for not being "creative enough", so he started his own business and went bankrupt. You are still very young, take the lessons you've learned and use them to make your success.

score -5 · Answer 26 · 2018-10-18 21:52:36Z

up vote
-5
down vote

Just start your own business that way you can code how you need to without worrying about getting fired out of no where for virtually no reason.

The worst that happens is that you fail and have no one to blame but yourself. When that happens, you'll figure out what you did and then you can get another job if you want.

You might consider migrating to the EU for a new position. As I understand it the EU does not have enough developers. There are a good amount of remote jobs open so if you don't want to migrate you could also consider trying your luck at that.

edited Oct 18 at 21:52

answered Oct 18 at 15:36

Steve

1,097313

4

"The worst that happens is that you fail and have no one to blame but yourself." - The OP did not get fired for "virtually no reason." Each case lists a consistent lack of following the assigned task. That's something solvable.
â€“Â Dan
Oct 18 at 18:07

1

Migrating to a country where the OP probably doesn't even know the local language isn't going to help much. Even if the "official" working language is English (which might be the case for a multinational company) don't expect every employee will speak and write English all day just because some contractor can't understand anything else. Foreign contractors are the lowest form of pond life in reality, if not in theory.
â€“Â alephzero
Oct 18 at 21:49

3

"Just start your own business" - What on earth makes you think starting a business would be easier than figuring out what OP is doing wrong and fixing it?
â€“Â Ruadhan2300
Oct 19 at 8:23

3

I think this advice is dangerous. The OP's post showed a lack of introspection - they were fired three times in rapid succession, and they only took responsibility for one of the three (where, realistically, they were responsible for all three.) Proceeding with not only ignoring the root causes, but to actually raise the stakes (by trying to form your own business) seems reckless.
â€“Â Kevin
Oct 19 at 19:42

4

Okay, I'll be a bit more explicit. The OP is showing a lack of judgement, responsibility, introspection, and understanding. He's failing to be a useful piece in part of a business. Asking someone in that situation to form their own company requires them to have a much higher bar for those missing attributes. This advice is basically setting someone up to fail. Until they can be a productive member of a team churning out decent software, they're definitely not going to be able to run a business all on their own that churns out decent software.
â€“Â Kevin
Oct 19 at 19:54

Â |Â
show 6 more comments

score 209 · Answer 27 · 2018-10-22 13:52:05Z

Today I was fired from a software company.. for the 3rd time in 1.5
years. Needless to say I feel like I reached bottom and it's
impossible to get out without changing career. Should I change a
career? Is it even possible to find a job now?

Yup, that's pretty bad. But remember that you weren't sure anyone would hire you after being fired before - yet you ended up with this third job.

I think you need to look inward and determine for yourself why this is happening.

Don't blame "poor management" here. Something is going on in each case that resulted in poor performance on your part. In other questions you mentioned that you were fired for not asking enough questions and for not performing senior-level work. Hopefully there are things you can learn from all that.

It might be that you are choosing jobs and/or managers poorly. It might be that you haven't learned how to work hard, focus on what is important, and perform well in spite of issues at work. It might be that you are shooting for too senior-level of a position and are more suited to junior-level work. Or it might simply be that you are not well suited for this sort of job at all.

Spend some time on introspection. Try to come to a conclusion before acting. You likely can't afford to make the same mistake again.

You might consider taking a stab at temp work. Those might be easier jobs to get in your situation. Maybe you can motivate yourself to perform well when the projects are small and time-limited. Your past experience seems to suggest that you could.

I'm in my 30s without a fallback place, no family around and not many
friends.

That's something you'll want to work on independently from your work issues. We all need friends. And a good support group would help when you are having work issues.

Keep trying to be friendly and make more friends. Join a club. Socialize with folks from work. At least try.

+1 for Don't blame "poor management" here. - Even if that were true it is an awful pitch to a new employer. — Oct 17 at 20:53
@JoeStrazzere true but it's hard to be picky when you don't have a job in place already. Plus you can't tell what is going on internally until you work there. — Oct 17 at 21:34
Also you can still pitch yourself with those in mind. It's an easier sell saying "I perform slowly because of (thoroughness, refactoring, technical debt removal, etc.) reasons, and that has in the past been viewed as slow working" than saying "I was fired because poor performance". Be sure to refactor how you're selling yourself and ask questions in regard to pacing. It seems on first glance that you're in fast paced environs and that doesn't necessarily work best for you. Some employers don't need you to work super fast as long as the quality is there and the work brings value. — Oct 17 at 22:45
@JoeStrazzere, I feel your replies come from a somewhat privileged position. It's hard to be picky if you have no job and struggle to be able to buy food and pay your rent. If you're a person with plenty of experience in a field in which you don't need to fear unemployment longer than a month or two, that's probably hard to imagine, but it does happen. — Oct 18 at 7:36
The only things I'd like to add to this response: 1: while looking for your next place of employment, try taking courses to sharpen your skills, whether to be in refactoring, other coding practices, or even communication. 2: in the future, if you see code that should be refactoring, ASK BEFORE DOING. They may not want to spend the resources on refactoring. And finally 3: in future interviews, if they ask about the reasoning of 3 short employments, be sure to explain what you learned from it. "I learned to communicate more with my manager" sounds better than "I had 3 bad managers". — Oct 19 at 12:26

score 207 · Answer 28 · 2018-10-18 05:06:37Z

up vote
207
down vote

I spent a lot of time refactoring and trying to remove technical debt. I received a verbal warning for under-performing before going on holidays.

It seems here you were working on something that wasn't asked for. This is generally very bad, and can lead to termination. If you think the project needs refactoring, and I trust you that it did, you must sell it to the management before you can do it. If you had done that, I suppose the management would have acted differently.

You may have told yourself you can't complete your task without the code to be clean. Truth is, most companies' code isn't. They work with legacy, they try to move on with what they have...

I was placed to work with a technology unrelated to what I signed for

...and almost all of them will hide the legacy behind more appealing new technologies when interviewing.

I don't think this is in itself a signal you should change career. I would think you have no aversion to software engineering when it's done right. But engineering in a company is always a matter of dealing with software done wrong, with management pushing forward. If you want to last in a company, you must be ready to accept this.

edited Oct 18 at 5:06

answered Oct 17 at 20:45

Arthur Havlicek

1,7111312

20

I'd want to add that it would be good to get used to switching technologies. I'd say it's generally good to be able to adapt to any technology that comes along, and try to enjoy the challenge.
â€“Â Theolodis
Oct 18 at 6:20

100

This, this, this, this, this. If, as a relatively new hire, you're given Task A, do Task A. Don't look at the code and say "Oh, wow, that really needs refactoring" and work on Task B (refactoring) at the expense of getting Task A done in a timely way. Start making notes about what refactoring you think might be needed, sure, but wait. After several months of solid delivery on task and learning what the culture, start raising technical debt and refactoring with management on an as-needed basis, and get buy-in before spending time on it. (And be prepared you may not get buy-in.)
â€“Â T.J. Crowder
Oct 18 at 15:45

21

@T.J.Crowder exactly right. I don't know how many times in my career I have encountered awful kludgy code and found out it was done that way because seemingly more elegant solutions just didn't work. Anyone who would have rushed in to "fix" it would have broken it and wasted a lot of time in the process. Take the time to learn why things are the way they are. And remember your employer doesn't want "perfect" code, they want working code that lets you move onto the next thing. There is always a next thing.
â€“Â Seth R
Oct 18 at 16:53

11

TBH, I think the "tendency to clean up messy code" is a real problem in the entire industry, b/c messy is a hugely opinion based attribution. Many of our younger colleagues have that tendency. They often write code that follows some catchy rules from famous authors dogmatically (e.g. adding interfaces to literally every single class), which none of those authors would approve btw. Refactoring not a bad thing, but it isn't sth. managers hire people to do. Also: you shouldn't do it alone, w/o coordination and early after beeing hired. Also, not every messy piece of code is worth the effort.
â€“Â nozzleman
Oct 19 at 9:52

12

Also: there's a chance colleagues complained about you because they felt offended by your "optimizations" of their work. I once escalated a PR which removed all this-qualifiers in a C# codebase and edited the corresponding Analyzers, because the colleague found them to be superflous (which they technically are). While at it, he added underscore-prefixes to every private member variable as a "compromise". It would have been fine if the whole team agreed on that change of paradigm before it was done, but that way it was crap. He got fired for underperforming (finished not a singele feature).
â€“Â nozzleman
Oct 19 at 10:00

Â |Â
show 10 more comments

score 146 · Answer 29 · 2018-10-18 11:21:11Z

Understand why you're getting fired

You've said it yourself. You're focusing on rewriting, when that isn't what you're there to do. You have a really bad case of Not Invented Here syndrome. As far as management goes, the problem seems to be about whether you're prepared to do what your manager tells you and get your work done, or whether you're going to play about with things you think you'd like to do. And faced with a new challenge, it looks like you run away.

When you get over this, then you'll be employable. Until then, frankly you're just causing damage to your employers and to your own reputation. Your employers can usually survive this, but you won't.

Let's look at your resume...

Case 1: Fired from a fintech company on the 2nd month for not performing... lack of motivation.

If you knew this wasn't something which you could focus on, why did you take the job? And if you didn't know, why didn't you resign with dignity instead of wasting everyone's time? This is the one which really concerns me.

Case 2: Fired from a web platform company for not performing... technology unrelated to what I signed for...

The nature of a technical job is that there will always be things you haven't worked on before. If you've not seem that technology before, own up to that, and make sure estimates are adjusted accordingly.

But "not performing" doesn't usually mean that you missed deadlines, it usually means you've been caught slacking off instead of working. In a technical job, I'd expect someone to be excited about learning new skills, or at least be diligent about it. If you're going to run away from anything you don't already know, then find a new career.

Case 3: ... spent a lot of time refactoring and trying to remove technical debt... Have a tendency to cleanup messy code, refactor and ensure things are well tested...

And this is where we see you playing about with things you don't need to. You call it "messy code". The rest of the company called it "working code". I come from a safety-related engineering background. In this line of work, people can be disciplined for fixing bugs. Seriously. The problem with "fixing" a bug is that you need to prove your fix hadn't broken anything else. In the context of retesting an entire car engine and transmission, a minor bug which maybe causes a 1% error in fuelling for one processing tick after an hour's running is most likely completely acceptable, but the cost in money and time of a full retest of the whole system probably isn't. That's before we even get to fixing "messy" code, where your allegedly-non-functional changes may turn out to have side effects due to a missed comma or something equally silly.

In short, you're being hired to do a professional job. So far, you've demonstrated that you aren't able to be professional. When you can go into an interview and present those failures as learning experiences which have helped you turn your mentality around, then you're good to go.. Can you do that...?

This answer has good points about code cleanup you're not asked to do and the bugs you can easily introduce in the process, especially if automated test coverage is low. However, I think "Not Invented Here syndrome" doesn't apply to code refactoring; that's more about re-implementing an existing solution you could reuse from e.g. a software library. — Oct 18 at 3:03
This makes a super important point about this "refactoring". If you're new to a company and haven't spent time working within their existing code before you start to try to "refactor" it to meet your personal code quality standards, there is basically a 100% chance that your ignorance of the product will result in massive bugs. You're going to have to produce meaningful work before having the experience to know what you can safely refactor. Also, your coworkers are not going to be happy code-reviewing your sweeping non-functional changes while they try to actually meet their deadlines. — Oct 18 at 4:10
@JimG.Maybe I should be clearer and say "a 1% error for one processing tick". But yes, an occasional glitch which a customer isn't likely to notice and isn't going to cause problems during emissions tests is absolutely acceptable. I've been through enough bug triage meetings with various automotive companies. :) — Oct 18 at 11:20
I completely agree with this answer. If a painter came to your house, he wouldn't tear down the entire wall and start putting in a new one just so he'd have a fresh surface. He'd work with what he got. Part of being a professional is doing what you're told and working with what you got. If you have a problem, bring it up and get everyone to agree with you before you do otherwise. — Oct 18 at 14:55
To add to what @Dan said, I would expect the painter to recommend to me that I get him or her or someone else to apply a skim coat of plaster if the wall was in poor condition (this happened to me literally a month ago), and then it would be up to me to decide whether to go ahead with that or just let the painter do the best they can with what's there (this is what I did and it looks great!). The analogy is that you can recommend refactoring, but unless you have complete control over the project and time left to achieve the main goals, unless you have sign-off don't do it. — Oct 18 at 17:31

johncip 40927 · Answer 30 · 2018-10-18 09:09:29Z

I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

I'm going to go out on a limb and assume this is more than the usual boy scouting. So:

I have a tendency to choose to cleanup messy code, refactor and ensure things are well tested, whenever they are "adjacent" to something I'm writing, and to prioritize this over shipping, regardless of what I've been tasked with.

Tests and refactoring are great, but it's never 100% one person's call on how much emphasis they get. The code is a means to an end -- it's not just there for your enjoyment, it's there to serve business needs, and the folks who work closer to those needs (the management) are in a better position to set priorities. Plus everything you change is something that you could potentially break, tests or no tests -- to say nothing of the extra review burden.

Regarding a career change, I think that there are two things to consider. The first is that if you are consistently insubordinate, it won't matter what career you're in. Line cooks who "improve" recipes get fired too. In other words, you're potentially being fired for not focusing. Your impulsivity could easily follow you into a new career, so switching will only pay off if you address your focus first. The second is what you mentioned about lacking motivation. What might be causing a lack of focus is if you perhaps don't like coding beyond cleaning existing things up, which is completely understandable. But if true, it means that a fourth dev job would just be signing up for more torture (assuming it's working on a team & on an existing codebase).

But I would make doing what you say you're going to do your top priority, and go from there. Done properly, this also means not taking on obligations you don't think you can meet. Who knows, maybe you'll discover that you'd rather bake bread. (It's just an example, but I think it's a good one -- it's a craft, it involves troubleshooting, it rewards perfectionism, and you generally do it yourself from start to finish.)

Anyway, the important thing is that if you're asked to do a job, and you accept it, then you do it. Later, if it turns out it's not for you, then bow out gracefully and try something else. But doing that "something else" on someone else's dime, while they think you're doing what they asked of you, is just going to piss people off, in any line of work.

In general, developers don't really like writing tests and doing refactoring. At least not 90%+ of time. If that's something that the OP enjoys, maybe he can find a company where he gets to do that full time. I'm going to confidently guess that there are plenty of companies out there who want at least some of their developers to do such work but who find it difficult to motivate them in that regard. — Oct 19 at 14:52
Sure. A place with strong engineering culture will have higher standards, but at the cost of more opinions to navigate and more conventions to bow to. (I personally prefer enforced style rules that I "don't like" to none at all, but not everyone thinks that way.) I'm a neat freak myself, but have had to learn that not everything I write will be some objet d'arte -- esp. given that some "great" things I've written in the past make me cringe now. It's 80/20, as with everything else, and shipping comes first. All that said, maybe OP would dig being on a dedicated testing team? — 3 hours ago

motosubatsu 35.2k1591144 · Answer 31 · 2018-10-18 15:24:16Z

Ouch

You don't need me to tell you that this isn't good so I'm not going to belabour the point but it's worth a quick look at the three firings:

Case 1: Fired from a fintech company on the 2nd month for not performing. This was correct since I had a lack of motivation.

Nothing to say here - you know you messed up. Something tells me that lack of motivation won't be a problem for you now!

Case 2: Fired from a web platform company for not performing. I was placed to work with a technology unrelated to what I signed for, so this seems like poor management from my side.

While it's not ideal management to be putting new hires on tech they are unused to I'd be wary of blaming this all on that - it takes two to tango as the saying goes and I'd be surprised if there wasn't more you could have done to avert this as a firing but let's call it 80-20 their fault.

Case 3: Fired on 6th month for poor performance. During probation I received positive feedback. After that I changed project and I spent a lot of time refactoring and trying to remove technical debt. I received a verbal warning for under-performing before going on holidays. In the 4 days I had I tried to fix that by staying overtime and finishing all due work. However when I came back from holidays I received a termination letter.

Sorry but this one is all on you - refactoring as you go is not bad in of itself, and it can be a very efficient way to clean up a code base without completely stopping forward development for several months. But doing it when you don't have direction or at least approval to do so (including the additional time it takes) is not a good idea. From the employer's perspective it looks very much like you worked to get through probation and then slacked off afterwards (I realise that is not what you did - but that's what it looks like).

Generally the issue as I see it, is that I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

You've identified the likely cause of the "poor performance" views but seem to have not quite got there in realising that this actually is poor performance. Consistently failing to make estimations (assuming those estimations are realistic) isn't just "seen" as slow performing, it is, by any definition of the term slow performing! If a user story/ticket/whatever has an estimation of 6 hours to complete and it takes you 12 hours because you spent an additional 6 hours doing activity X then it doesn't really matter what activity X is, whether you were refactoring or watching cat videos on you tube it still took you 6 hours longer to do your assigned task then was expected.

The good news is that you basically have the skills and talent you need to succeed at coding - you just need to shore up a couple of things in your approach. Spot something that would benefit from a refactor when you're working on a task? Great! That skill can be turned to your advantage rather than a thorn in your side - all you have to do is talk to your manager/team leader or whoever manages the planning and resource allocation and say what you've found, what benefits you think it can bring to the business and how long you think it will take you to do it.

If they agree it's worth the time investment they can account for the extra time, you don't go over estimation, and you look like a rock star for being proactive in helping the company.

I love having coders reporting to me that do that!

However..

You have to accept that sometimes they are going to say "No" or "Not now" to these requests - that's because they deem the timescales for completing the original task to be more valuable right now, and like I say you need to accept that response because there's nothing wrong with them making that call, because that's what they get paid to do.

Unless you are 1110% certain that not implementing your proposed refactoring immediately will have dire consequences for the company then you don't push back, you don't argue. You do what you are being paid to do, if it blows up on the company later then, frankly it's the responsibility of the person who decided not to do it - again this is what they get paid for!

So where do you go from here?

I don't think you need to change careers right now - like I say it sounds like you've got the skills and while your recent job history is, to be blunt, pretty damning. It's not irreprable and with some hard work and a bit of luck you can get the ship righted and be back on course like it never happened.

Here's what I'd do if I were you:

Go contracting (this would be my recommendation) - work history matters less than having the skills in the contract word, and people are more likely to take a punt on someone for a contract then they are for a perm position as it's easier to drop them and get someone else if they make a bad hiring decision. You've got a fantastic buffer of savings that's going to give you time to give it a shot - set yourself a deadline: if you can't find (and be successful) in a contract in 3 months then you can widen your search to include perm positions. I've not had it take more than three weeks to secure a contract position so far, and I'm appalling at interviews, so you can do this! One good contract of 6 months and very few people will care about your last three perm jobs! And on top of all of that even if you have to look at the lower end of the market in terms of day rate for your first couple of contracts you'll probably be making very good money in real terms.

or if contracting really isn't something you want to do:

Stay perm - take a step down the salary ladder

At the moment getting some good work history under your belt is more important than maximizing wages. Work out the lowest realistic amount you need to live and start applying for jobs in that bracket. There's always companies whose hiring ambition exceeds their budget, and they tend to be less choosy. Even if you're taking a Ã‚Â£5k cut off your potential you'll be able to earn that back in the long run by just sticking it out for ~2 years and performing well. I'm not saying it would be fun, or easy, but it would be very effective.

Don't give up - you can do this!

I'd also like to add that refactoring can also be a significant risk. You are making major changes and any time that happens there is potential for things to go wrong. Even if they are a good and experienced programmer the OP hasn't been at these jobs long enough to have the context and history necessary to minimize the risk of these refactors. Most people don't find maintenance program much fun but it is necessary and a skill people should learn. — Oct 18 at 23:17

Andy Lester 892511 · Answer 32 · 2018-10-18 16:40:39Z

I'm guessing that not listening is a key problem. Not just hearing words, but understanding and taking them to heart.

This jumps out at me:

Generally the issue as I see it, is that I have a tendency to cleanup messy code, refactor and ensure things are well tested - something that can be seen by many as slow performing.

"That can be seen by many as slow performing" isn't the important part. Your company told you it is slow performing, because they fired you. If your boss says to do something, you do it. If your boss says not to do something, you don't do it. If you're unsure, then ask your boss and do what she says.

As a rookie in the business world, it's not your place to decide what the company should be doing. When you decide on your own to go doing code cleanup, you're telling them company you know better than them. Don't do that.

As a developer for 32 years, I know that it can be frustrating to leave tech debt, to leave messy or undocumented code. But if that's what the company wants you to do, then do it.

Phill 27917 · Answer 33 · 2018-10-19 08:37:52Z

I realise there are already 16 answers here, many of them excellent, but they don't seem to have addressed that there is a small possibility that there could be other reasons for being fired.

It might just be that these have been convenient excuses for your firing. It is never nice to point this out, but it's worth examining if you are fitting in on a personal level.

I've known (of) a few people who have been through several jobs in a short time and they can't see why. To me (and others) it has been obvious - they have a habit or trait that grates on the people around them. For one of the guys, this was a habit of loudly clearing his throat all the time, coupled with not taking the hint when people wanted to end a conversation. I worked in the same office as him and I can tell you, the atmosphere after he left was so much nicer. Another guy, it was a hygiene problem. They both got fired for what sounded reasonable, but you knew in the back of your mind these other traits definitely factored into it.

I'm not saying you have any of these characteristics, it could even be a culture clash, not something that's even your fault, but as other answers suggest, a period of introspection is very valuable here. I would extend that to look at things like personal habits and traits to check if they could be the hidden cause.

score 8 · Answer 34 · 2018-10-17 21:41:34Z

You could always teach computing in high school if you think your industry career path is limited. There are other things you can do like project management too.

But when you do apply for another position, don't explain your firings as management problems. Even if the manager was completely responsible for what happened, you will give the impression that you aren't capable of assessing your own mistakes and weaknesses.

Write a short cover letter with your new applications and explain what happened. Take responsibility for it regardless of the reasons. Explain why things will be different.

You might have to take contracts for a while. Trust me, I've seen contractors come and go a lot.

Once you've re-established yourself, you can start building your career as a successful employee.

NEVER think your options are limited because this will only limit your options. Its cliched but you have to keep a positive attitude.

Thanks for the suggestion. But as I see it.. who would like to hire someone who got fired thrice as a dev, as a project manager? — Oct 17 at 21:33
You cant think that way, even if you decide to become a teacher. You can always shuffle your resume around - you are only talking about 1.5 years. Fill the gap in your resume with teachers college or something similar. — Oct 17 at 21:36
Also i wouldnt necessarily abandon your current career path. — Oct 17 at 21:36

l0b0 1,8681913 · Answer 35 · 2018-10-18 07:20:54Z

I know the feeling of wanting to spend a lot of time improving code quality to increase the speed of development. They can absolutely save massive amounts of time, up to and including making complex projects doable in the first place. However, I would be careful to introduce those slowly when starting a new job.

Expect it to take months to build up enough context (from developers, users and managers as much as from code) to learn where the biggest (not just the big) pain points are. Once you have a solid understanding of these you should be able to present a case to your manager for working on one of them for a short period of time to massively improve some aspect of the code. And when you nail one of these you really show why they should keep you. You don't have to be a fantastic developer to do this - everybody with a bit of experience has skills that the rest of the team lack.

Before all of that, though, I would focus on getting the day to day stuff done. I've worked in places where developer quality assurance was so poor that we spent almost all our time putting out fires. It's not fun, but unless you can make the money roll in faster management isn't going to be interested in cleaning things up.

As a final note I've had several bad jobs as a software developer, but others have been great fun. Personally I would recommend research institutions and smaller companies, as they are in my experience flexible in how they work and at least somewhat interested in QA.

BittermanAndy 93115 · Answer 36 · 2018-10-18 15:16:23Z

Much of what I'd ordinarily say has already been said. But there's at least one path open to you that I don't think anyone has given as an answer yet.

Consider contracting / self-employment.

Many of the other answers have focused on how you can sell yourself to your next employer, how you can explain away your short stay in your last three roles, and what you might do differently to keep your next job. All of which is true, but finding another employer doesn't have to be the only option. What if your next employer was... you?

Pros:

You don't need to explain anything or justify what happened to anyone else.

If you are genuinely good at what you can do, your skills will be in demand, at a rewarding price.

You already have six months of savings - that's long enough to find clients and get started.

Once you have a few clients, you can pick and choose what you want to work on (i.e. which clients to take on), rather than whatever your employer tells you to work on.

Cons:

You will need to run your own business and sort out your own taxes, as well as developing software.

If you are not as good as you think you are - or if you can't find motivation to do what the clients want - or if you waste all your time making neat code with no technical debt when the client just wants working software - you might burn through all your savings and end up back exactly where you are now, except your savings are gone. This is a real risk. You will need to take a long, hard look in the mirror before you take this route. But I suspect you'll need to do that no matter what.

Hang in there. Plenty of people reach their 30s and find things haven't turned out as they expected. It's not too late.

Indeed - intended to be covered by "if you are not as good as you think you are". — Oct 18 at 15:21
I was in a similar situation as OP and for me self-employment is the only way I can make money with programming. I did two fixed-price jobs that my client was happy with. It was better than working for a boss, but I still didn't like it enough. Now I do all kinds of work to make a living. Some jobs are really not that bad, especially when doing part-time. Meanwhile I'm developing one big software program (no client, own idea) that I can sell and improve when it's finished, so I can even more do 'my thing' instead of following orders. Perhaps a similar approach will work for OP. — Oct 18 at 19:33
"Nobody likes poor performing contractors" - absolutely. And the fastest that I've seen a contractor fired for potential poor performance (i.e. he clearly didn't know what his resume claimed he knew) wasn't "2 months". It as TWO HOURS. He showed up at 9am on Monday morning, and had gone for good by lunch time. Contractors don't get kid glove treatment like being "on probation" or "put on an improvement program". They hit the streets unemployed FAST. — Oct 18 at 21:40
Pro: Contracting over many projects will allow you to see the "messy" code again and again on various assignments and on this pain point you will either totally fall out of business or you will learn not to care about it too much Ã¢Â€Â“ effectively giving you a cure of unhealthy detailism. — Oct 18 at 22:50

Ruadhan2300 3974 · Answer 37 · 2018-10-19 09:15:50Z