Reddit mentions of Nakamichi Over the Ear Bluetooth Headphones BT304 - Retail Packaging - Black

Going to grab a few things from some of your comments and pitch in some advice. I hope this comes across as earnestly as I mean it.

> I will never quit next time.

I'm going to suggest a slight change to this. The problem isn't that you quit. It's when you quit. It's okay to quit if your job dead-ends. Please don't feel that this isn't an option. I know a COBOL programmer who learned that the hard way after being downsized from a decade-long job, and spent years unemployed. There are also several studies that suggest looking for a new software job every 1.5-2.5 years just to get a pay increase from your new qualifications, since it's hard to get it at the same job. And there are cases where you tell your boss that there's nothing new left to learn at your job and you need a chance to grow and he just shoots you down. But you didn't give it time to dead-end. It'd be understandable if you had something better waiting, but...

>My friends and family thought I overreacted and the company was bound to create new products eventually, the thing is the commute was long and when I came home with massive pounding headache for riding public transportation , I didn't have the energy to work on my side projects or learning ASP.net.

Valid concerns. Was your commute much longer than an hour? I've had hour commutes from two-bus trips with 15 minute layovers. It was not awesome. But you get some comfortable headphones, take a book, and learn to enjoy it. public transportation takes longer than driving, but you're also not dealing with traffic and having people cut you off. Even telecommuting has its downsides. It's hard to find a job that's all roses. You have to learn a positive outlook as much as your job skills, and eventually you pick your favorite compromises when you've seen the alternatives.

Also, ASP.NET isn't rocket science. There are new/advanced techniques in it (MVC, Razor, etc), as with anything. But having basic .NET experience for a junior is more than enough. Sometimes it's just as valuable to pick up a new guy without any bad habits as it is to hire someone with experience. ASP.NET has evolved significantly enough that I'd check how modern those skills are before hiring based on them, anyway. You'll find it an unfortunate reality that few employers want to invest in training a new person. That's why the first jobs tend to underpay and underwhelm.

> I accepted the offer not because the need of money ... but because of social pressure to get a job, any job.

Agreed that this was not a good idea. Did you also consider that, when you quit, you quit because of someone else's perception of the value of your job? It's still peer pressure, and you're also operating under pressure to get a job that you feel fits your self image. And now you've submitted to the external influence here. You haven't left the external influence - you've just picked the advice that you thought was more valid. External influence isn't bad - everyone who has given you advice has done it in your "best interests". But if others are the sole reason for your decisions, you're always going to be unhappy.

Might I suggest that you consider that work is just work? We don't do it for fulfillment - we do it to pay the bills. It's a means to an end. You're looking for the best-paying, highest-growth, least-stress position you can find. One where you can work hard and then leave work at work to go home and live. Don't get caught up in living your employer's dream on your own time.

> Through his connection and network he bought the source code of two different softwares, which he sells on the side. My job was simply to maintain the softwares.

There's a decent chance that, given no external input, he wouldn't make anything new. However, that doesn't mean you wouldn't get the chance to make new things. In jobs like that, I've built maintenance tools for easier install/support, I've refactored things into a cleaner base, I've practiced new implementation/deployment technologies in branches, migrated old codebases to Git, etc. I've even made product enhancements and suggestions as I got more familiar with the business needs. Even if the owner didn't have any vision (which is pretty common), it doesn't mean that he's utterly blind. Just ignorant.

Not only that, but if your task is just maintenance, you could have kept a steady progress on fixing those bugs while learning on the job. You could have been learning not only code skills, but valuable employee skills like contract negotiation, and how to manage your boss. Seeing the bottom of the barrel does wonders for your career motivation, if you need it.

And you could have been scheduling interviews the entire time at new places while building your resume. Pro-tip: don't put this job on your resume. Quitting your first job after 20 days doesn't give a prospective employer a good impression. Working for 6 months and catching a more exciting job is understandable. Or jumping ship once you've got a better job.

> the only tasks I was given were fixing bugs.

> I realize that I always have to fix bugs as junior

Sometimes this isn't just about giving the shitty job to the junior. Some times it's about giving them a low-pressure way to get familiar with the code base while still being productive. I let a junior write some new functionality in a 20 KLOC-ish project. That was in a branch that eventually made it into production for one customer. Unfortunately, he changed a lot of the base classes despite all my ominous predictions, and I was too busy putting out fires to stop it before it got too far. Soon it was 100 commits behind master and I had to merge it myself to be sure that it didn't break functionality for the other 40 installations using that code. Some lessons have to be learned the hard way for everyone, and fixing a feature has less risk than adding one. Especially on a new codebase.

Maintenance might not be the most glorious thing, but it's something everyone needs to know how to do. Write-only coders aren't as popular as they think they are. Being able to deal with an existing codebase and refactor/repair without breaking it is an extremely valuable skill in a team. Honestly, you'd probably be hating and rewriting your code regularly at any job, even if it was brand new. It's just something about coders that we always feel like the job's never done.

Not only that, but there are consultants who base their entire careers around being able to walk into a terrible codebase and clean it up. It's a basic skill, not a lesser skill. And there's an art to it beyond the function.

> What done is done, but did I really over react

I don't want you to feel like your concerns weren't valid, because they were. It was an overreaction to a legitimate concern, not a completely wrong reaction. There's just maybe a bit more to the picture that you'll learn with experience, which will teach you how to weigh those concerns. If you have a tendency to overreact or let people push you into bad decisions, find a friend who can help calm you down and analyze without pushing you into something. And then don't jump into a decision without their advice.