True story: A family has a problem with their new car. Every sunday the whole large family meets for lunch, then someone drives to the ice cream parlor and buys ice cream for everyone. And then a strange thing happens: Whenever they buy vanilla ice cream, the car's engine won't start. If they buy any other ice cream, the car's engine starts. Mechanics couldn't find a fault.
Finally, the family invited someone quite higher up from the manufacturer for sunday lunch. And the guy drove with them to the ice cream parlor, vanilla ice cream was ordered, and the engine wouldn't start. This guy would have made an excellent software tester: He checked out the ice cream parlor. It turned out that they had a huge tub of vanilla ice cream that could be served quite quickly, while any other ice cream took longer. The fault had nothing to do with the ice cream flavour, but with how long the engine was turned off. Once they could reproduce the problem, the fix was easy.
But in the end, a bug that appears always and under all conditions is easily fixed. These bugs are most likely already gone before a tester ever sees the software. What is hard is problems that only happen under certain circumstances, and that will not appear 99% of the time. In that case, your bug report is not helping at all if you can't describe how you got the 1% case.
Good tools would also allow you to specify how reproducible a bug is. You may have a bug that even with your best efforts can only be reproduced 10% of the time. What does that mean? It means the developer won't give up if he tried it out three times and the bug didn't appear if he knows it is rare.
And when you write down steps to reproduce a bug: Consider that a developer cannot read your mind. If you don't write it down, he doesn't know about it. If you are not precise, he doesn't know what you are doing. If you are inaccurate, the bug may not be reproducible at all with your description.
PS. I've had bugs that would only happen to testers or even specific testers. For example: Tester does step 1, checks the screen, compares it to what his script says, does step 2, checks the screen etc. And there's a bug that only happens when you do step 1, 2, 3 and 4 several seconds apart, by the exact right amount. A second tester writes down the results, therefore takes longer, bug disappears. The developer knows all the steps, does them quickly in a row, bug disappears. Developer and Tester 2 go to Tester 1's desk and see him reproduce the problem. They ask him to do it slower, problem goes away. They ask him to do it faster, problem goes away. He does it at his own speed, bug comes up. This does happen.