Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently in a situation where a lot of people criticized me for making bugs (on my first local try - the first time I run the code for the first locally done test - , not on a committed repo though, management look at me very closely). The majority of my bugs are most often not algorithmic (they are more like mistaking one var for another, a forgotten line, a missed method call).

The people criticizing me say I need to be able to make code without bugs. Correct on first try.

I have been practicing to improve my coding skills. While practicing with the USA CO set, I saw a message:

YOUR PROGRAM ('xyz') WORKED FIRST TIME! That's fantastic -- and a rare thing. Please accept these special automated congratulations.

  • Doesn't it mean it's rare to have things right right away?
  • Does it mean that the people demanding correctness right off the bat are unreasonable?
  • 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)?

For more info: I could finish at least half of the USA CO set is about 30-60. I am not sure if that means slow or bad coding or not. Some difficult ones require about 2 hrs for improved correctness.

And now, what is the way to avoid making mistakes now? (Other than practice more and focus on a particular area)

EDIT: This is mainly to ask so that I know what a typical good developer would exhibit in coding error, and coding speed. I want to evaluate my performance based on that of a good developer. Sorry about the feeling of resentment or displease that this question might convey.

FINAL EDIT: I come to the conclusion that this is simply a way they use to teach me their work style which then makes everything seems reasonable. In addition, a good answer was that I should use random experimentation less when I learn new things. That really makes people feel uncomfortable. The traditional approach of reading the book should be employed more and would often have many additional benefits besides just acquiring new knowledge.


share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

closed as primarily opinion-based by gnat, GlenH7, Jim G., MichaelT, ThinkingMedia Jul 4 '14 at 19:42

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

One measure to reduce bugs is to slow down and take the time to do things properly. Management often do not like this because they want things done as fast as possible (and, of course, they complain if there are bugs afterwards). On the other hand, it is more efficient to do something slowly and get it right the first time than to do it fast and get it right at the fourth attempt. So, slowing down in the short term can mean a speed up in the long term. So you could concentrate on doing things properly instead of doing them fast. – Giorgio Jul 4 '14 at 5:45
"Efficient" coding makes my alarm bells ring. If you told this with regard to the code itself. Code plain and simple. The numbers of bugs will reduce, and rectify them will be easier. Optimisation has it's time. Later – Lord_Gestalter Jul 4 '14 at 6:02
on my first local try Then how do they know you have finished? They expect it to work properly as fast as you have hit "CTRL+S"/compile? Or is it you telling them "I think I am done"? – SJuan76 Jul 4 '14 at 7:05
Don't know about that USA CO stuff, but "making mistakes" is the first step to "learning". All people make mistakes, sometimes silly ones. Myself included. Whoever demands "always bug free code on the first try", should prove it themselves in real-world scenarios. I'd love to see that. – JensG Jul 4 '14 at 7:54
It is not possible to answer this specifically without seeing the code that you have written and that was criticized. It is unreasonable to have all code correct from the beginning. But it is reasonable to expect you to chose the right general approach and a solid coding style from the beginning. Maybe your general approach was not liked? Maybe your superiors don't view the tiny mistakes you make as a problem at all. – usr Jul 4 '14 at 8:48

14 Answers 14

Doesn't it mean it's rare to have things right right away?

Exceedingly rare. In fact, if things run 'right' the first time, I normally assume that something is drastically wrong.

Does it mean that the people demanding correctness right off the bat are unreasonable?

Completely and utterly.

And now, what is the way to avoid making mistakes now?

Slow down, think, before you type anything think. Talk to another programmer before starting something big. Know your language, your framework. Then relax. Mistakes are guaranteed. It's how you fix them that makes you a good coder.

share|improve this answer
I've been programming for over a decade now. I recently wrote some networking code which worked, first time, perfectly. Zero flaws throughout the whole project. Every time anything went wrong, my first thought was that I'd finally discovered the bug in that piece of code. – Phoshi Jul 4 '14 at 9:39
Using mistake-preventing technologies also helps. E.g. using a language with a strong type system like Haskell. Developers shouldn't be testing things a compiler can verify for them. – Den Jul 4 '14 at 10:58

Personally I'd be most concerned about the "forgotten line" and the "missed method call".

Everyone makes some mistakes, and like everybody says the most efficient way to find things like typos is with the compiler, not with repeated manual proofreading of all your code before you present the first version to the compiler. Some IDEs help with this too.

However, there are certain kinds of mistakes that suggest there's a problem with how you're producing the code in the first place. A forgotten line means that you didn't manage to transfer all the parts of your plan for what you were going to do, into the actual code. What if you're following some other process, like setting up a new server, and you forget a line in the instructions? What if you're writing test code and you forget to test something? It might be caught by code coverage tools, but then again it might not because line coverage isn't the same as branch coverage, and even branch coverage doesn't necessarily cover every important input. What if you miss the part of your plan that was "run the tests"?

Such problems get caught eventually, by code review and integration testing and QA and so on, but you should still be aiming to keep the number of your bugs that other people have to spend time on, reasonably low.

Also, consider what your "first local try" is. Are they looking over your shoulder, and when you type something incorrectly they say "aha! that's your first try" before you have a chance to hit backspace? That would be totally unreasonable, and the only way to even start to conform to their expectations would be to become a much better typist. I doubt that's what you should be spending your time on.

But if you're presenting code to them before you've run it, then you're being unreasonable and they're correct that you shouldn't be calling that code your "first local try". What they want to see from you as your so-called first attempt is something that works as far as you can determine locally. If it doesn't do that, then there's an avoidable bug in your first try.

It's entirely possible that your colleagues are being unreasonable, and there's nothing you can do other than learn to code in the apparently inefficient way they code. Or maybe (very unlikely) they actually are outrageously awesome and think they can teach you to be that awesome too.

It's also entirely possible that your colleagues are seeing errors that they think you should be able to learn to make only rarely, but are expressing themselves poorly in saying that your code should be "without bugs" and "correct on the first try". It seems really unlikely that their code never fails a test and that they've never had a bug report on their product, so that standard would be unreasonable. But you should aim to produce code that works perfectly when it leaves your desk at least sometimes, and that always mostly works.

[Edit: what you're saying about them going through your old code and events from your past job makes me start to believe they're picking on you for the sake of it. Could be hazing, could be they're sadistic jerks, could be they don't want you or don't want any junior dev at all, so they're trying to build up a case to get rid of you by judging you on past mistakes instead of (or as well as) present ones. If this is it then it doesn't really matter whether you make more or less mistakes than a good developer, because they aren't judging your mistakes fairly anyway. Watch out for other signs of bullying: do they give you a hard time about things other than your code? Call you by nicknames you don't like? Try to provoke reactions from you? Leave you out of group activities or conversations and make sure to let you know you've been left out? I don't want to make you paranoid, but try to step aside and take an objective look them: are they unpleasant?]

share|improve this answer
Answers like this are the reason why I am glad I joined this site and ask for advice here. Thanks – InformedA Jul 4 '14 at 9:58
+1 OP should clarify what is a "first local try". Looking at the first thing you compile is senseless and doesn't show anything. But having missing lines in something you actually show someone for review before committing is plain bad and wastes a lot of time. And the fact that colleagues might actually be saying "You shouldn't be making THESE mistakes", rather than "You shouldn't be making mistakes" is very valid - most devs I know can't properly explain the way they work and think or transfer that knowledge concisely. – Ordous Jul 4 '14 at 10:10
@randomA: it sounds like quite aside from whether these criticisms are reasonable, you have an unusual workflow that you can't discuss. It's really hard for us to judge how many mistakes there would be in the code produced by "a good developer" in your situation since we don't know the situation, so be sure to treat all answers with great suspicion :-) – Steve Jessop Jul 4 '14 at 11:09
@randomA: it's starting to sound like these people just want a reason to pick on you. They can hardly believe that it escaped your notice at the time that deleting that production index was a mistake, and they need to bring it to your attention now so that you can learn from it. This isn't normal for the industry. I'm sure you can't afford to be rude to them, but perhaps internally you can take a "yes, and?" approach. They've dug up another line of code you wrote when you were 14, that was wrong. Yes, and? Other than they enjoy mocking you about it, this has no conceivable effect on you. – Steve Jessop Jul 4 '14 at 11:53
@randomA: they might just want that, but I'm saying that in my experience, there is no style of programming that you can only learn if they comb through your old code. So the more you say, the less likely that "might" seems to me. – Steve Jessop Jul 4 '14 at 12:03

The people criticizing me say I need to be able to make code without bugs.

Those people are wrong. There is nothing bad at making bugs on the first try. In current days of quick, incremental compilation and intelligent IDEs, that mark errors without compiling, first-time methods are not that big problem. It is much more profitable to put your energy and focus into actual errors in logic of the program, than focusing on putting correct interpunction. Because compiler will tell you where the error is and fixing it is quick and easy.

share|improve this answer
They are in control. They are the axioms of the system. I cannot argue that they are wrong and I am not really saying that they are wrong. And it doesn't really matter if they are right or wrong, I have to find a way to make them feel comfortable. I really don't know how other good people would do in respect to coding mistake and coding speed. – InformedA Jul 4 '14 at 6:22
@randomA This kind of mindset is what breeds bad habbits and work environment. If you think something is wrong, say it. If they are rational people, they should be open to debate and criticism. If you can provide good counter-arguments to their arguments to why you should always be correct on first try, then they should admit that such thing is not necessary. And if they are not open to debate, then find better place to work. – Euphoric Jul 4 '14 at 6:46
The thing is with so much misinformation and obfuscation, I don't even know if they are wrong. In particular, whatever they know, they see, they want to see, I have no idea. Maybe what they want is not in the code and the software, but the code and the software is just something they use to determine what is there in the developers making those code and software. In other words, the objective might not be the software, it's something else. – InformedA Jul 4 '14 at 6:53
There is a significant difference between not being flawless and coding by trial and error (a bad thing). – JamesRyan Jul 4 '14 at 14:07
@JamesRyan This is perhaps the best line I receive here. Now I can imagine this is what I need to do to make people happy. Try not to make it like I code by trials and errors. This means a reduction in working in things I am not very fluent in (otherwise, I have to do trial and error, that's how I best learn things) – InformedA Jul 4 '14 at 18:19

The majority of my bugs are most often not algorithmic (such as mistaking one var for another, a forgotten line, a missed method call).

I used to make this kind of mistakes, a long while ago. This happens due to rushed code, spagetti code and too tight coupling (resulting in having to keep track of too many things at the same time, while writing an algorithm).

The people criticizing me say I need to be able to make code without bugs. Correct on first try.

This can only be true for code you have written a lot of times, or that you find utterly trivial. There are (very) few programmers who can do this, and expecting it from someone is unrealistic. For example, in 15 years in the industry I have had one coleague who could do this, and I've heard of two others (that's less than three in a thousand).

For the rest of us, there are unit tests.

•Doesn't it mean it's rare to have things right right away?


Does it mean that the people demanding correctness right off the bat are unreasonable?

Yes. You can search online for bugs/KLOC. These usually measure how many defects were present in a released project (i.e. after developers went through a lot of testing and bug fixing).

And now, what is the way to avoid making mistakes now? (Other than practice more and focus on a particular area)

Test your code.

share|improve this answer
+1 for testing. The only effective way to remove bugs. – Kramii Jul 4 '14 at 8:31
One of the tests of TDD is to actually check that the test does fail (one way to see this is that it's "buggy" until it's fixed). So +1 for testing – Pierre Arlaud Jul 4 '14 at 10:04
  • Doesn't it mean it's rare to have things right right away?

It is usually normal to not get everything right right away. Case in point, if you are working with a client, sometimes not even they know what they want, so potentially they could come back to you a couple of times to fix parts of your code.

Also, people with different job descriptions tend to understand and prioritize things differently, for instance, as a developer, you could focus more on the logic of your program, you do not really care the buttons are all over your interface, cosmetic changes, in your opinion, can be made at a later point.

On the other hand, an end user or a person in management could be willing to sacrifice some of the functionality for something which looks more like the end product. Meaning that they will ask you to fix certain bits of the UI and to postpone certain other coding tasks for later.

  • Does it mean that the people demanding correctness right off the bat are unreasonable?

That depends. I would always expect that there will be some fixing to be done. What varies is the experience of the developer. A junior developer is bound to make more mistakes than a senior one. As you work on different projects, you eventually start to learn what it is that people are usually after and learn to ask the right questions.

  • 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)?

Although it is important to get things done quickly, it is vital that you take your time for each task. In my opinion, programming is 80% planning and designing and 20% actual coding. If you rush the design, you will most likely be quick to deliver, however, the solution might not be easy to maintain. So, you save time in the beginning but eventually end up wasting more time during the lifetime of the project to adapt it. When working for companies, software could potentially last for years before it is re-written (maintenance in my experience costs more than the delivery of the project), so some extra weeks at the beginning of the project could save months in trying to adapt it to the new business rules.

share|improve this answer
Thanks for the advice, for small and simple things, I often design in quite details as concepts/algorithms/logic in my mind before I code. For more complex things, I often 'experience' different paths to take in actually coding and running app instead of in my mind. I realize a few problems, dos and don'ts when I do the experimentation. But I don't commit these to the repo. – InformedA Jul 4 '14 at 6:17

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 call).

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.
share|improve this answer
Thanks for taking lot of time to write this advice. Yes, I am being micro-managed for reason that I don't know (maybe it's non technical). I have seen people much worse than me (both at works and schools). However, for some reason, they leave other people alone and only look at me. Anyway, I will take the best I can from your careful advices. Thanks! – InformedA Jul 4 '14 at 8:52

The notion that professionals never make errors is ludicrous.

Professionals do two things that amateurs do not.

The first is that they shorten their feedback loops. Have you ever made a typo? Would you finish typing the document, discover it, and then decide to throw out a document if you did? It's crazy right? This was a real problem for professional writers for centuries. The key is to discover the error as quickly as possible. If you catch it early enough you can avoid wasted work or think of a creative way to incorporate that mistake. Another thing you can do is to build a set of tools and techniques that will give you rapid feedback. Luckily you and I work in software and such tools are absurdly easy to find and build. When I approach a problem, I first think of what feedback I need to determine that my approach is working or not working. Usually TDD and a unit testing framework will do that job. Once the feedback loop is in place I can safely make as many mistakes as I usually do and still end up succeeding.

The second is that they practice. They do meaningful, challenging practice that is fraught with error. The point of that practice is to learn to recognize the feedback of what a mistake look and "feels" like. Then they learn to quickly and effortlessly correct those mistakes, usually without an audience knowing. Whether it's holding a breath a touch too long, a nervous twitch, or a faulty mental calculation, professionals intuitively know how to make the imperceptible adjustment that keeps that mistake tiny.

I'd argue that the best code comes from an environment where mistakes are accepted, embraced, and corrected without fanfare. A place where failing is such a common and trivial thing that it's a non-event. Please don't waste energy trying to be perfect. It's far more useful to practice failing until you can't get it wrong.

share|improve this answer

Remember that training sets are meant to encourage learning. I see that message as just a morale booster to encourage you to continue.

For simpler programs, it is often a matter of focus to code without any bugs. For complex tasks with many interacting classes, there is always the possibility of a bug even with expert programmers.

Proper coding practices can catch 90-95% of these potential bugs. The type of bugs that you mentioned (wrong variable, missed code, etc.) indicate that you are not paying enough attention to your coding.

Slow down. Take the time to understand the overall behavior of a class or function. This is natural when you first start coding and will only improve as you practice more.

There are some steps I like to follow for any coding task:

  1. Break down your overall task into simple steps.
  2. Write those steps as plain English comments in your code.
  3. Now, each of these comments can become a code block. If it is simple enough, like "print value to console", replace it with the actual code line.
  4. Repeat the above steps to break down more complex blocks.

If you introduce a bug, it is you who will have to wade through hundreds of lines to debug the exact issue. It is often in your best interests to code right the first time. :)

share|improve this answer
Thanks for the suggestion. I am a pretty decent coder, I often have a very concrete idea of the logic/algorithm before I actually code. I always break things down into small steps. I once said methods need to be 120 lines or less if possible. For anything more than 20 lines, I need to write test cases to make sure things are good. – InformedA Jul 4 '14 at 6:13
@randomA: A method can be as long as it needs to be, and if you follow the style of your organisation you're probably OK. But time permitting, I'd say that methods should be 20 lines or less if possible, and that for any number of lines you need test cases. It depends on the language, though, and any frameworks you're using, but I think that's a reasonable number for common languages that call them "methods" rather than "functions". I write methods longer than 20 lines, and if they work correctly I might ship them like that, but I'm usually not happy about them. – Steve Jessop Jul 4 '14 at 9:47

It's possible to create perfect code the first time. It just takes some years of practising and writing large amounts of code. How it works is that you'd verify the code correctness while writing it. Instead of randomly writing code and hoping it would work, you write the code and immediately verify the correctness. Any errors you find need to be fixed immediately instead of delaying the fixing. There is like 2 seconds time after writing the code to verify it's correctness. Good plan is to keep the code logic in your short term memory while verifying the correctness. This is how quickly it needs to be done for this to be effective.

But of course requirements need to be perfect, before this is going to work. Ensure that your requirement is perfect, and start writing the code afterwards. If you write code using fuzzy requirements, then end result code is going to be fuzzy too.

share|improve this answer
"Instead of randomly writing code and hoping it would work" I actually do this when I have to face with problem that I have never seen before and has no known solution. Like the other day when I try to figure out a way to use generic to get the object out of a list and return a close typing without actually using any casting at all. But just because I do it once a while doesn't mean I often 'randomly' write things and hope them work. To avoid 'random' completely, I guess I have to avoid everything that I don't know for certain. – InformedA Jul 4 '14 at 10:28
randomA: You're right about this. Relying on language features you don't know well, or if the requirements have unknown parts is a big red flag for writing correct code. Good plan is to use your free time to experimentation of different primitives, so that you don't need to do guesswork while writing the code. – tp1 Jul 4 '14 at 10:31
I don't rely on them. I practice and exercise with them. If I am not allowed to experiment on things I haven't mastered, the only other way is reading books repeatedly. But I find that randomly experimenting things in 1 hour (with some interleaving documentation reading) helps me understand and learn things much better than reading alone. – InformedA Jul 4 '14 at 10:39

I couldn't disagree more with the people who say "code should work right the first time". It's nonsense. You can write code very carefully and very slowly and have code that works right the first time after four hours. Or you can write code very quickly that compiles and runs after an hour, with all the bugs fixed after two hours. So what is better?

My brain power is a scarce resource. And when I write code, it goes through the stages "runs without obvious bugs", "passes unit tests", "has been reviewed by me and found to have no bugs that the unit tests missed".

Spending time on making the code work right the first time it runs is a waste of my brain power. It is much more efficient to run it, and fix it. And "running right the first time" is worthless anyway, because unit tests have to be written, and when all is done the code needs to be properly reviewed. Which is the time where my brain power is actually needed.

What would be right to tell you: To avoid coding patterns that are error prone. You can write code in such a way that the compiler will tell you about inevitable mistakes. You can write code in such a way that bugs will be visible and not hidden.

share|improve this answer

A popular method nowadays is Test Driven Development. You start by writing the test case, which obviously fails since the actual code is still missing. This is thus a perfectly normal situation while you're developing. But to finish your task, the test cases you added must pass.

As a result, you go from "code still in development" straight to "all tests passed". Of course, an any future point you may find that you've missed a test case, but that problem also exists if you write the tests after the code. But if your tests are good, your code will also work right the first time you try it on real data.

share|improve this answer

In this business, be really careful about taking others' criticisms too much to heart -- be attentive, of course, and always try to improve yourself, but don't just accept others' characterizations of you. There are lots of people who play stupid power games in order to favor their position in the organization, or else favor their personal technical preferences.

In this case, it's pretty simple: writing code is equated with making errors, at every moment. That's one reason that unit testing is such a prevalent practice these days, because the presumption is that your code is not right.

You could adopt a test-first practice, in which case you're writing code to suit the tests. Then, almost by definition, your code will be correct the "first time". ;) ...although bugs will still creep in.

share|improve this answer
If you write the test first, then by definition your code will be /incorrect/ the first time, since you first have a test which tests code which does not exist yet. – Pete Kirkham Jul 4 '14 at 18:07

You mentioned nothing about the scale of the projects you have to work on. Eitherway writing large amounts of flawless code is impossible, trying to is a good thing but it should not be compulsive because that will slow you down.

When you are confronted with a new problem, you must grasp it intuitively and start writing, gradually you will figure out what the end result should look like. You may have to refactor (alot), but that means that you're learning from your mistakes and that is good.

Don't try to approach professional software development like a theoretical scientist, because in practice, it is experience that matters.

share|improve this answer

I want to address a valid scenario for why the feedback to "...make code without bugs. Correct on first try." is a reasonable expectation.

Please think about the situation I will describe, as it may not be the one that OP is in!

The principle here is: When have you completed your first try?

  1. Does it end when you have stopped tying, after your first conception of the solution?
  2. Does it end when you have finished testing locally and are ready to commit to the trunk/repo?

#1 is about Laziness

If you lack motivation, or executive function, to do more work than simply your first impression, then there is an issue. If you haven't tested things on your own, iterated, done integration/contract testing — then you are just pushing your work onto others.

#2 is about being organized and self-sufficient

Coding is more than writing what you remember about the functions of the language. It's also reference-work, spikes, unit tests, acceptance tests, iteration, and transparent or documented style.

Make sure you are not doing #1.

However, you have also described careless things. Others may ask you to 'do it right the first tie' in order to set an unreasonable expectation that will get you closer to 'doing well' as you attempt the 'impossible'.

You should be able to remember most, if not all, basic conventions of the language, even if you must look them up to remember their nomenclature, options, etc. You should 'know the primitives' so that you can formulate a plan in your mind.

The 'moral of the story' is that you should be able to think-through the entire problem, on the first go, despite the unreasonable effort required to do so.

One of my most satisfying and edifying programming experiences was also one of my first; when I wrote an entire basic game on paper during a grade school vacation. I only had pencil and paper, and had to think, and think, and re-think, and re-write — so that when I got home and typed it in: flawless.

Practice these things, even in the face of their unreasonability, and you will improve.

share|improve this answer
I completed my first try when I cannot see any conceptual/high-level problem with the code I wrote. And I definitely do more work than my first impression when the first impression does NOT lead me to believe that it is the certainly correct path. I have to say though that I do follow and attempt my first impression many times (otherwise, how do I know my first impression is wrong?) – InformedA Jul 4 '14 at 18:37
What exactly is a "first try" was a major question in one of the answers and the comments to it. In it the OP tried to explain what is his situation: "Looking at the first version when I locally run the code to test (for the first time) is what can best describe the situation." It doesn't seem to fit your examples by a long shot, although those are actually valid. – Ordous Jul 4 '14 at 18:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.