I have been fired from two jobs in the last year. Should I quit software development ? am I that bad ? I was fired from the last position because I think I was asking questions about the framework that the other colleague has written, its not my problem to work with undocumented code, but I tried my best to finish tasks and wrote the software. I'm so depressed, and don't want to do software work anymore, I feel bad, I feel that I'm useless programmer, and not good. I have no other career opportunity.

I was fired from the last position because I think

It doesn't really matter why you think you were fired, it matters why you were actually fired. Why was that? Were you told? How was your termination communicated to you?

I have no other career opportunity

This seems unlikely.

Should I quit software development ? am I that bad ?

This is not a question we can answer for you. If it doesn't make you happy, maybe stop doing it. If it does make you happy, keep trying.

It can be really hard on the ego when one gets let go, even if it's a mass layoff. It is possible to recover, and even be successful. I've seen folks go from being fired for not working out, to working someplace new, and getting promoted to a lead in a short amount of time.

its not my problem to work with undocumented code

I don't mean to depress you further, but unfortunately, it is. We work in an industry where a good deal of code isn't documented; in fact, sometimes even intentionally so! I have worked with at least one group that specifically prohibited documentation comments on the ground that they often become out of sync with the code and can make the code less readable. Of course, some software is simply so poorly written that you do need documentation or "tribal knowledge" to understand it, but a good company should know that and take it into account when "on-boarding" you. But approaching work tasks with the belief that you are entitled to people doing things the way you think is best is a recipe for disappointment and nothing getting done.

I say this from personal experience; on my first day on at work after I finished school, I was given my door key, shown where my desk was, and then told to that I needed to make a feature work on the project to which I was assigned. They showed me how to access the codebase I was to work on. Then I was left alone to either ask questions or figure things out on my own. No real documentation of how the code (written in archaic, pre-standard C++) worked besides comments from about 15 years ago. Largely speaking, I was able to figure things out on my own; I did ask questions, but my coworkers were busy trying to ship a game, so I did my best not to ask too many of them. The last codebase I worked on was probably at least an order of magnitude more complicated, and though it had somewhat more documentation for some subsystems, it was large enough that most didn't have any beyond the code itself.

But keep your chin up - the good news is that working with undocumented code is a skill you can develop with practice, or at least I believe so. You can do this by reading and debugging a lot of code - especially code you didn't write. Fortunately for you, there is a lot of open-source code on the internet just waiting for you to read, download, and execute it!

The best approach I've found so far is to take a scientific route - look at code, form a hypothesis about what it does, then test that hypothesis to see if you're right. If you prove yourself wrong, change your hypothesis and try again. Keep doing that until you prove yourself correct.

edit: Note that I'm not advocating never asking questions or never documenting your code as good ideas. I'm simply pointing out that very often you can't depend on others to do things the "right" way, so it's not a good idea to get your expectations up.

I think if the person who wrote the code still works for the company and its not clear what the code does to the extent you have to ask an anal amount of questions then that person should really be carrying some responsibility for maintaining it. No doubt the person who wrote it has been in the company for some time and his/her opinion carries a lot of weight. Better for that person to indicate you don't know what you're doing than to admit their code sucks.

getting fired for asking to many questions is absurd. Would a company rather you made the incorrect assumption or wasted time debugging code when you can "just ask"?

So, here is the thing.

There is a balance between "dig into this yourself" and "ask an expert in house". If you spend a week trying to find the source code, you've clearly gone too far. If you ask a question about every function, you've gone too far in the other direction.

The problem is, this is a balance that people find *by* working in professional environments, it isn't something that gets taught in school, so far as I know.

This is why entry level engineers are basically a loss early on; a big part of the ramp up is how things work in a professional environment, not just "how we do things differently here". Better companies know this, and the manager will either mentor the engineer, or assign a mentor. Worse companies, well, leave you to sink or swim.

its not my problem to work with undocumented code

I don't mean to depress you further, but unfortunately, it is. We work in an industry where a good deal of code isn't documented; in fact, sometimes even intentionally so! I have worked with at least one group that specifically prohibited documentation comments on the ground that they often become out of sync with the code and can make the code less readable. Of course, some software is simply so poorly written that you do need documentation or "tribal knowledge" to understand it, but a good company should know that and take it into account when "on-boarding" you. But approaching work tasks with the belief that you are entitled to people doing things the way you think is best is a recipe for disappointment and nothing getting done.

I say this from personal experience; on my first day on at work after I finished school, I was given my door key, shown where my desk was, and then told to that I needed to make a feature work on the project to which I was assigned. They showed me how to access the codebase I was to work on. Then I was left alone to either ask questions or figure things out on my own. No real documentation of how the code (written in archaic, pre-standard C++) worked besides comments from about 15 years ago. Largely speaking, I was able to figure things out on my own; I did ask questions, but my coworkers were busy trying to ship a game, so I did my best not to ask too many of them. The last codebase I worked on was probably at least an order of magnitude more complicated, and though it had somewhat more documentation for some subsystems, it was large enough that most didn't have any beyond the code itself.

But keep your chin up - the good news is that working with undocumented code is a skill you can develop with practice, or at least I believe so. You can do this by reading and debugging a lot of code - especially code you didn't write. Fortunately for you, there is a lot of open-source code on the internet just waiting for you to read, download, and execute it!

The best approach I've found so far is to take a scientific route - look at code, form a hypothesis about what it does, then test that hypothesis to see if you're right. If you prove yourself wrong, change your hypothesis and try again. Keep doing that until you prove yourself correct.

edit: Note that I'm not advocating never asking questions or never documenting your code as good ideas. I'm simply pointing out that very often you can't depend on others to do things the "right" way, so it's not a good idea to get your expectations up.

It's still a serious problem that the code is undocumented. It's seriously unprofessional for who ever hires you to expect you to be able to do without a decent supply of comments, and a "documentation" that was the equivalent of a list of cryptically named functions.

I've had that happened, and basically left in a year (Non-profit project at least, and one that my name is not on. So it doesn't matter to me). They held a big thing about the code should be self documenting... but a good amount of the code and api that they had created were not obvious at all to what they did. There were abbreviations all over the place, some of which were too complicated for what they were supposed to be. Non-sensible API. Overcomplicated problems to simple solutions. And a degree of abstracting that was unnecessary because they were either trying to avoid hard coding, or something else.

In order to do my portion of the job, I had to rely on a few other systems that was programmed in... but low and behold I could not find the actual base of the code in either the documentation or the actual code. And for the longest time, I couldn't test my stuff even when they expected me to. Because the API I had to work with was not complete or non-functional.

This sort of crap is usually caused by people who think they are the best programmers in the world, and all inexperienced programmers like me need to catch up. Which is not feasible. That's like writing an entire fictional novel by slamming your hand repeatedly on the keyboard to make a jumble of letters, and then expecting editors to be able to understand the stupid thing.

I have been fired from two jobs in the last year. Should I quit software development ? am I that bad ? I was fired from the last position because I think I was asking questions about the framework that the other colleague has written, its not my problem to work with undocumented code, but I tried my best to finish tasks and wrote the software. I'm so depressed, and don't want to do software work anymore, I feel bad, I feel that I'm useless programmer, and not good. I have no other career opportunity.

Mirroring Josh Petrie on this first part:

WHY were you let go? How was this communicated? It is important in evaluating what steps are next.

If both times the companies came to you with something like a "Performance Improvement Process" or PIP, both times they told you that you needed to do better in specific areas, and both times the areas they communicated were the same, then yes you probably have an area you need to correct.

If both times you were let go because there was a RIF and 30 others were also let go, not so much.

Always look for ways to improve your skills. If you are told by a boss you need to improve a specific skill, ask them for help. If you are told by multiple bosses you need to improve a specific skill, ask for help both from the boss and seek help externally.

It is possible that you don't currently have the necessary skills. Not knowing you, not knowing why you were let go, not seeing your abilities, I cannot judge them. I have seen some people who are capable of doing the job, but in practice they take so long and introduce so many small errors that it is not worth it to the company to keep them around. Some times it is because they need training on a specific aspect of their work, other times it is just because they don't have enough practice or skill. If you can gain those skills you can succeed.

For depression, that is normal after getting laid off. Many people consider their work role as part of their psyche and getting terminated from a job is like losing a large chunk of your identity. Consider getting some counselling if you can for the depression. The negative downward spiral of depression can be absolutely terrible and sometimes requires professional help in order to return to regular productive live.

I was fired from the last position because I think

It doesn't really matter why you think you were fired, it matters why you were actually fired. Why was that? Were you told? How was your termination communicated to you?

Well, not saying Josh is wrong, I do think it is important to get to know how the company rationalizes firing someone.

But at least around here, companys will come up with all kind of bullshit reasons to fire people. Sometimes they sound like bullshit, but are actually true. Only people directly involved with the fired person, or the person being fired themselves do know.

But I know often higher ups just want to get rid of someone for reasons they do not want to make public (maybe their own job would be in danger), or for reasons that do not warrant firing someone by law.

They will come up with all kind of lies and accusations to fire someone. Often the hope is that the guy just sucks it up and looks for a different job as he no longer wants to work for the company anyway. Some do fight, and often win their case. Which then usually means the company has to pay them some money, as they most probably still do not want to work for the company anymore.

So being fired once means not much. You yourself should know if the reasons you are being fired for are bogus, or not. You yourself know if there is a weakness to work on, or not.

It could also be that you just stood on somebodys toes once too much, and that somebody happened to be quite ruthless.

In the end a job contract is a two way street. If a company fires you for the wrong reason, clearly you don't want to work for said company anymore. See what YOU did wrong in the whole thing. Ignore what you think is just lies and accusations for being able to fire you. Move on, and try to make a better impression in the next job, maybe think twice before stepping on peoples toes if that was what led to you being fired once.

Being fired twice in a year sucks, and yes, would also give me more to think about. But I don't think that the software industry is any different than any other industry in this regards.

There are black sheep among companys just as there are black sheep among employees. Being fired twice doesn't have to mean you are the latter, could mean you had the bad luck to be employed twice in a row by the former.

Learn something from it, move on and find a new job. Easy to say, but unless you really want to leave the software business for good, it might be the best thing you can do.