I take a slightly different perspective on the issues you raised than most other commentators. I apologize for a long response, but I wanted to draw as many examples as well as issues because these issues can make a significant difference in one's careers. I have had to personally go through hard times in my career, and thus I wanted to share what I learnt.
The majority of my bugs are most often not algorithmic (such as
mistaking one var for another, a forgotten line, a missed method
An old saying goes that programmers code bugs. When code is written it will be buggy. However, when it is delivered, what kind of bugs exist and what do not is the difference (i.e. requirement mismatch, major security flaw, etc.) It also depends on whether you deliver turn-key projects, work on a product, or a service. Each uses a different model, and expectations vary.
In a nutshell, what you are stating seems to be a symptom of the difference between expectations and individual performance.
If I were in your place, I would try to understand why the management thinks these issues should not be there. I would also get feedback from my peers, especially those who are senior to me. I would also look at how they are checking-in and delivering code to see whether I am just doing it differently, or if I am actually missing something important.
This is also very confusing (and troublesome):
I am currently in a situation where a lot of people criticized me for
making bugs (on my first local try, not on a committed repo though,
management look at me very closely).
Why is someone looking at your local code before it is committed? Are you being micro-managed? Is that because you are stuck and asking for help? Or is it part of code reviews? Or is it a standard practice in your company? This can only be answered by your or those around you. If you are starting on a new technology, and getting stuck as a result, you may need to educate your management and tell them upfront about these challenges. However, if you have worked on this particular area or technology, and they expect more from you, then you need to reconcile either why there is difference or how you can meet their expectations.
Developers usually work in teams. Teams have cultures. There are teams that will have the classic waterfall model of doing a 6 month milestone with code complete in 40% of time and spend 60% fixing bugs (change the ratios to your suiting). In one of the teams I know of, when a developer checks in code, it is in production the next morning. Their scale is relatively small though. Another team does 10 billion plus transactions in a week, and once the devs check-in features, they are in production within 1-2 weeks. If they had checked in bugs, those are out there sometimes resulting in very serious business impact.
Without understanding what model and team you work in, what are the expectations from the devs in your team, and what are the specific issues that your management sees, it is very hard to give any blanket answer whether the management is right or not. It also makes a difference if your management is technical (esp. programmers or ex-programmers) or not. At some point in past, when I was a manager, I used to review others' code, make my own check-ins, as well as hold my team (including myself) accountable for quality. It was our business need.
Doesn't it mean it's rare to have things right right away?
Depends on what's right. In our current team, we write unit tests, functional tests, integration tests, and then live site 'runners' that check the live site is working. Before check-in, all the existing tests must pass, no exceptions. It slows us down for sure: check-ins are sometimes delayed for days because of code review feedback, broken tests, etc., but there is almost never an exception. We have ship schedules and pressures and need to sometimes work late or weekends. But we cannot check-in functionality that will NOT work the next day, or we have to provide explanations, and fix the process so it won't happen again. In some other teams I know, if a check-in leads to a service outage, the developers need to participate in post-mortem, which is then presented to the upper management: how it happened and why it would not happen again.
Does it mean that the people demanding correctness right off the bat are unreasonable?
In my opinion, this question cannot be answered without more information, and without understanding the work environment. If I were you, I would get more data from people around me (I mentioned in my post earlier), and even find a mentor if I needed to. Sometimes, in-house mentoring does wonders.
Or is it because USA CO participants code the problems in 10-15 mins?
so it's normal for them to make mistakes (also they are highschoolers,
professional software developers have to be better than them)?
I do not know their market and can't comment, but many such website are tailored towards average users and not professional programmers, and thus, what may be an excellent response from an average user or a learner, may be the basic expectation of a professional.
And now, what is the way to avoid making mistakes now? (Other than
practice more and focus on a particular area)
Depends on what's a mistake. Of course, the more code on writes, the better they become. However, a few things one can try (roughly in the order of highest impact first):
- Definitely seek out a mentor even if you need to find it in the wider community instead of your company, although if you find within the company, it is likely to be far more beneficial.
- Ask your manager to help you especially if he's technical. Talk about both the expectations as well as what needs to be done.
- If you are being micro-managed, talk about the results and not activities:
- Result = what you deliver in how much time with how much quality
- Activity = how you deliver (and work through issues)
- Take courses or training in the area you are the weakest in (technology, domain, process, productivity, quality, whatever)
- See if there are any professional associations you can join where you can get help, attend workshops etc.