This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
IMO, the phrase "what won't kill you, will make you stronger" really applies with projects like this. There is a reason why EFH don't think that 300 classes is huge. It is likely that he got burned with very difficult problems, that had 300+ classes before. Now, to him, it is easy.
It is too bad that you quit. If you hadn't, the next time you faced a problem like this... you'll know what to do. In fact, you'll think, "hey, this is easy. Its just a smallish (300 class) application".
Why are you guys assuming that he left only because of undocumented code, or having to work with VB code.
To me, it looks like it was his boss's attitude that made him quit -
ting yun wrote:
By then it's been two hours. My boss wasn't too happy and kept asking whether I had fixed that "small error" yet. When I said to him it references objects and methods all over the places and it is gonna take days to analyze where the error came from, he said "oh, i don't want you to spend days, that wouldn't be productive." and left. Ten minutes (or 20 minutes) after he came back asking "how is your progress?"
Later when everybody was leaving, I was tired and asked him whether he wants to come back tomorrow to analyze the code or wait to hear from the last guy who maintained the system, he smiled and said something that annoyed me very much "Came back only if you are making progress!"
Ting Yun, this hardly sounds like the worst job you will ever have. It is quite common to end up working on huge code bases with no documentation. And it is also common enough to get requests to do something that is totally out of scope of your current skills or knowledge. As long as your manager understands how much work it is to get started on something like that, and supports your effort, it is all good.
Give some thought to how you would handle a situation like this if it happens again, and keep looking for another job.
You can't be too choosy right out of the university, but as you go through your first couple of years, try to figure out where you want your career to go, and what kind of work you want to be doing a few years from now. Try to understand how you use an interview to evaluate the company, just as they evaluate you. Then use this knowledge to pick a job that is more suitable for you when you change jobs again.
The future is here. It's just not evenly distributed yet. - William Gibson
Consultant @ Xebia. Sonny GillTweets
This is unfortunately indeed common. Documenting costs time and time costs money. Because maintaining would be much costlier, they look for an cheap developer to maintain it.
Ask the details about the projects you'll got during the interview. Ask what exactly you ought to do, ask how well documented it is, ask if you'll got support of a more experienced colleague (or someone who developed it), etcetera. This really sounds like that you're thrown in a too deep hole tbh.
If I (with my 8 years experience) would get such a project, I would either have denied it or asked for more time to document it so that future maintainers can save time. No more time? Then it's bye and up to the next challenging project.
Echoing the comments above, there are two parts to this:
1) Dealing with people - it sounds like the boss expected of you what an experienced person would know. Whereas you are a college student and haven't been exposed to it yet. It's hard to know what to say at a first job. It is going to take time to understand an undocumented system when nobody around can explain it to you - that is just a fact. And that's something to talk to the boss about if he/she has different expectations. I wouldn't expect anyone new to have fixed a bug on the first day.
2) The technology - while documentation and structure is nice, it can't be relied on. The systems I work on happen to be clear. However, many places are not. I agree with Ernest that 300 classes is not big. Not because I've gotten burned by one. More because it takes a lot of code/work to do something complicated. (I work for a large organization - we have big problems to solve via code.) Thousands of classes are a normal sized project for us. They are organized into projects and layers so you don't need to keep everything in your head at once.
At the same time, I can understand why the boss would be annoyed. He spent some time training you on the first day. That time is an investment that pays off after you have been there for X amount of time. If you leave before then, he doesn't recoup his investment.
As an aside, what's so special about Java that you MUST have your career on it? Visual Basic is a language too.
I had similar experience at my first job. The code was written in dbaseIII which I did not know. I was just out of college know ing Basic,C,Pascal,Fortran,COBOL,Prolog,Unix and all theory about OS, compilers, loaders,DBMS etc what you learn in college. I was given software development in dbase. No one to help me. Boss's attitude was more or less similar. I did same thing. I did not go on second day.
Today I feel I did right thing. Because I started searching again and I landed in job which was also small consulting company, but I had experienced people to help me, and I learned lot from them.
Joined: Oct 23, 2003
ting yun :
I do not want to discourage you. Many ranchers will tell you most of the projects are like that. In most of the projects you will not get documentation and code will be ugly without comments. Thats true. But I will never expect a fresher to handle this kind of project independently. And Boss's attitude like that. I would advice you, not to think on what has happened. Just take it as bad luck you got such a project and Boss together on your first job. What I can see from your post that you have very good attitude towards work you will certainly get success. Start looking for next job forget this job.
I have to agree with what Rajesh just posted. In addition, consider this: It's quite possible that the manager didn't know that the project was large and complex and hard to understand. Most likely the person who wrote it did understand it, and when he or she was asked to make a change, was able to do it quickly. Now you are there and of course you can't do it quickly.
It's your job to manage the expectations of your superiors. If something is going to take a long time, or an unpredictable amount of time, then you have to communicate that. Easy for me to say... but in the real world that isn't easy to do. You're a beginner so when you say something like that, it sounds like you are making excuses. And many bosses aren't ready or willing to listen to that kind of advice from anybody. And, a lot of programmers don't have the interpersonal skills to do that job of managing expectations. That's a skill they don't teach you at school and it isn't one that programmers naturally have.
As you have seen, when the manager's expectations conflict with the realities, things can end badly. This is unfortunately very common, as several others have said. So try not to take it too hard. It's going to happen again and again in different forms.
Your boss seems to be a person with unreasonable expectations..I think you did the correct thing...With such a kind of boss you wouldn't have enjoyed working, even if you had continued there...Forget what has happened and move on..You will get better opportunities...All the best 
Helping hands are much better than the praying lips