More important than filing a bug report is to create a test case that will trigger it.

If it takes only two minutes to fix a bug, how quickly would you forget about it?

Create that test, fix the bug, and it won’t raise its ugly head again.

The test case is a living bug report, in the sense that no-one has to browse through a bugs database to evaluate what might need attention.

See also this inspiring lightning talk by Jon Arild Torresdal: Why you shouldn’t track bugs

Both @Karl and @Andrew mention an important caveat: After code is released, any bugs that are not (easily) fixed are now part of the product, and should be documented.

At school, I guess it doesn’t matter so much…

But out in the big-wide world then without a doubt you should record the bug. There are a number of reasons for this.

1. Once code has been released, changes should only be made for traceable reasons. This is especially appropriate in regulated industries (aerospace, medical etc) where type approval includes software audits.
2. It means that the code-change is traceable through the whole lifecycle – particularly testing and release documentation. eg in a tdd project you’ll also want to extend the test spec
3. It may not actually be a bug – you may have misunderstood, or maybe it’swhat the customer wants
4. It ensures that only one person is trying to fix the bug
5. It ensures management visibility – when asked why you haven’t finished what you SHOULD have been doing, you can show what you HAVE been doing
6. Doing it properly reduces the risk of accidentally adding in a different (bigger?) bug
7. There is the chance that the cause of the original bug leads developers to learn lessons
8. etc

For last 10+ years I always use bug reports in cases like you describe.

Thing worth keeping in mind is that with sufficient practice, this will take you very little time and effort (that’s a matter of fluency).

Another important thing to consider is that using bug tracking should be convenient. Purpose of bug tracking system is to make developer more productive, not less. If it’s easier to achieve the same goal without bug tracking tool than with it, this kind of trashes purpose of the tool.

• ^{To be precise, it can be somewhat cumbersome at first, when you are getting used to the tool, but if after substantial practice it still doesn’t feel easy, this indicates there’s something wrong – either with the tool, or with the way you use it, or with the way how bug tracking process is set up in your team.}

Taking into account how important is the convenience, have to note that one thing in the title of your question feels really slippery: “always enter a bug”.

This appears to assume a new bug report has to be always created – a typical newbie mistake; I made this mistake myself, it gave me quite some pain and it took a while to figure this ain’t necessarily so.

It could be sometimes more convenient to just add the bug you discovered to some existing report, or, if you found several bugs, list them in a single report.

• In one of the past projects I was assigned to fix issues discovered in code review performed against particular component. Review document listed about 180 (one hundred eighty) items; I sure as hell was going to use bug tracker because I knew it’ll be a nightmare to track work progress otherwise.
   
  But I was not going to create 180 separate bug reports either (why would I?) – I just created one for the whole list bug report #123 address code review comments submitted 20.10.2010 against component XYZ.
   
  In the course of my work, some of the items turned out to be worthy dedicated bug reports; no problem I created these when needed. “Progress table” in bug #123 looked about as follows

  review item  status
  -------------------
  item 1       fixed
  ...
  item 11      not started
  ...
  item 21      in progress
  ...
  item 31      extracted to bug report id #234
  ...
  

it does seem silly that you’d have to enter a bug which could be fixed in 2 minutes

Silliness here depends on how much time does it take you to register the bug you discovered.

• If it takes say, half an hour, it’s definitely silly. If it takes 5-10 minutes, it’s not too smart but may be OK if happens infrequently. Finally, if it takes less than a minute, why not – I see nothing silly here.

Actually, in cases like that it just takes me less than a minute, and here’s why. Look, here’s what you have

the part you’re working on at the time needs that bug to be fixed

As for me, the part I am working on is always registered in the issue tracker. When I find a 2-minute-bug needed to be fixed for that part, I just add a comment in the bug report I am working on, like

discovered and fixed <this bug>

Heck I do this even if the fix isn’t needed right now. Why wouldn’t I?

You generally don’t need a bug report unless a version of software with the bug exists outside of your development team. If you don’t need one, you might still want one if there’s a chance you might forget about it before getting around to fixing it. For me that means if I haven’t fixed it by the end of the day, and it’s not in a file I currently have checked out for other reasons.

A paper trail can be useful to cover your ass if things go tits-up and management start asking questions. An official bug will have the details of the bug, the name of the person who fixes it, the names of the people who reviewed it and a way of identifying the actual source code changes.

Managers love processes, it’s a good idea to follow them.