I’m always amazed how long people spend trying to figure out software by fumbling around with it, rather than reading the manual. Now, I know what you’re thinking. You’re thinking “Golly Martin, reading manuals is all swell and good, but I’ve got to write code and fix bugs. If I spend an hour or two reading those manuals, well jeepers, by the end of it I won’t have written a single line of code, or fixed a single bug. Not one line! I don’t have time to read them, I need to get things done!”
So here’s the thing: you should only spend two hours on something boring (like reading manuals) if it will save you more than two hours over the course of your life. And usually, you spend a lot more in the trial-and-error — commonly called floundering — than the two hours it would take to read the manual. Not the whole manual of course, and I don’t mean to memorize the parts you do read. But for three different people in three different jobs, I’ve had to point them to the first two chapters of the Subversion manual, titled “Fundamental Concepts” and “Basic Usage.” Despite the fact that they have “fundamental” and “basic” in their names, people seem to think it’s ok to not know this stuff. Until they get some <<<<<<<<<< in their source code, and they don't know where it comes from, and subversion won't let them check in their code. And then they spend a couple hours trying various things to figure it out, and nothing works, and they have to read the manual anyway. I've also seen someone spend hours trying to lay out an image in Word to conform to a conference's layout guidelines, and several people trying to get resizing working in Swing without understanding Swing’s layout managers. Note: I was one of those people.
So, if you think you can learn a tool’s mindset — the kind of hammer it is and therefore what sort of nails it thinks everything is — by trying things without understanding, you should. But typing random svn commands, or calling random layout-related functions when building a UI, or is like playing Battleship or Mastermind: you only get a few bits of information on each attempt, and the information you get is more like clues in a puzzle than a clear explanation of what you need to know. Please pay attention to the time you spend in trial and error. Because if it’s more than the time it takes to read the manual, you’re actually getting less done than you could. And it’s easy to notice this time: it’s generally frustrating, unproductive, quality-of-life sucking time.
If you find you’re working that way, please don’t feel bad. Most people do it. I’m not sure where it comes from. Bad, “results oriented” managers? Most people learn it before the first job. Bad managers depicted in movies and TV? Parents? Teachers? I don’t know.
But if you really want to spend the most time on the fun part of your craft — creating stuff, not debugging it or pounding your head against the wall — then you need to invest in yourself. It’s in your best interest. And it’s in the best interest of your company.