My wife hates it when I say this. (She's QA, I'm dev.)
One of my best skills is assuming. I have to make tons of assumptions, and if I stopped working whenever I didn't know the answer for sure, I'd never get anything done.
Instead, I make my best guess. If I'm unsure enough, I'll also send off an email stating my assumption and asking for direction, but I'll still keep coding based on that assumption.
I am almost always right, and I get a lot more done because of it. Even if I'm wrong, it's going to be a lot quicker to rewrite what I've done than to have done nothing and have to do it all after I get the reply.
I'll answer a question you didn't ask, too: What do my bosses wish I'd known when I started?
That saying, "no," isn't a good answer. Never just reply "no" when someone asks if something can be done. Find out what they're actually trying to do, or suggest an alternate way to accomplish it that can be done.
"but I'll still keep coding based on that assumption."
That's terrible advice. If you're unsure of what you're supposed to be doing, you should close the computer and start exploring your options with pen and paper before doing more damage.
If you keep going based on assumption, you drive halfway across the country in the wrong direction like in Dumb and Dumber.
Sometimes it's better to do nothing at all than to inflict damage because you didn't know what you were supposed to be doing.
Personally, I don't view "wrote a bunch of code based on an incorrect assumption" as "damage." At worst, you have to revert to what you started with and rewrite it. What were you going to be doing in that time anyway?
Basically, when I hit a roadblock that I can't get around by working on something else while I wait for clarification, my process is as follows:
1. List my options.
2. Pick the best one.
3. Send an email to my boss outlining the possible options, and note that I've picked what I think is the best possible option.
4. Continue coding and know that I might have to rewrite that feature if my assumption was incorrect.
If you're right, great - it wasn't a roadblock. If you're wrong, you modify or rewrite... which isn't too big of a deal, as you would have been picking your belly button lint while waiting for an answer anyway.
It's not like driving the wrong direction. Lets say you build 3 systems and only one gets used. You are still getting 3x the experience and your revelations could end up being very valuable for the system that does get used.
I agree with the grandparent 100%, but there can be risk as you indicate. The implication is the risk is situational and hardly ever applies. I too drive forward on assumptions, and I get a lot done, more importantly, I get a lot done that my boss CARES about. Thus, even though I only actually work a few hours a month, I'm perceived as a high achiever. There's a lot of wisdom in what the gp says, take heed!
One of my best skills is assuming. I have to make tons of assumptions, and if I stopped working whenever I didn't know the answer for sure, I'd never get anything done.
Instead, I make my best guess. If I'm unsure enough, I'll also send off an email stating my assumption and asking for direction, but I'll still keep coding based on that assumption.
I am almost always right, and I get a lot more done because of it. Even if I'm wrong, it's going to be a lot quicker to rewrite what I've done than to have done nothing and have to do it all after I get the reply.
I'll answer a question you didn't ask, too: What do my bosses wish I'd known when I started?
That saying, "no," isn't a good answer. Never just reply "no" when someone asks if something can be done. Find out what they're actually trying to do, or suggest an alternate way to accomplish it that can be done.