When I had my first internships, I remember that I was really hesitant to push code. I'd meticulously self-review my own code dozens of times before pushing my changes, rewriting the same components in a way that was slightly cleaner or more efficient. I distinctly remember a conversation with a more senior engineer on my team that went something like this:
Me: "I'm not sure if this is going to work."
Them: "So push it."
Me: "What?"
Them: "That's the fastest way to see if it's going to work."
And they were right—there ended up being some corner case in production I never would have thought of, and no test would have caught. The only way to really learn was to put the code out there, potentially make a mistake, and learn. This isn't to say you should never test your code or try to refactor anything, but spending too much time trying to get something to be perfect is often a lot worse than calling it done and moving on to the next thing. Making mistakes is okay as long as you're learning, and so don't become paralyzed because you're afraid of making one.
spending too much time trying to get something to be perfect is often a lot worse than calling it done and moving on to the next thing
When I was a scientist in a biochem lab we had a similar way of thinking.
There are times when you need to do a quick and dirty experiment to see if "it" works. Then there are other times when you need to find the precise answer.
Or put in EVEN another way...
"Do you need an answer right away?" versus "Do you need the right answer done to a high degree of accuracy?"
It requires a little artful thinking to learn which response is needed and when.
When I had my first internships, I remember that I was really hesitant to push code. I'd meticulously self-review my own code dozens of times before pushing my changes, rewriting the same components in a way that was slightly cleaner or more efficient. I distinctly remember a conversation with a more senior engineer on my team that went something like this:
Me: "I'm not sure if this is going to work."
Them: "So push it."
Me: "What?"
Them: "That's the fastest way to see if it's going to work."
And they were right—there ended up being some corner case in production I never would have thought of, and no test would have caught. The only way to really learn was to put the code out there, potentially make a mistake, and learn. This isn't to say you should never test your code or try to refactor anything, but spending too much time trying to get something to be perfect is often a lot worse than calling it done and moving on to the next thing. Making mistakes is okay as long as you're learning, and so don't become paralyzed because you're afraid of making one.
This is so inspiring & true! Thanks for sharing :D
When I was a scientist in a biochem lab we had a similar way of thinking.
There are times when you need to do a quick and dirty experiment to see if "it" works. Then there are other times when you need to find the precise answer.
Or put in EVEN another way...
"Do you need an answer right away?" versus "Do you need the right answer done to a high degree of accuracy?"
It requires a little artful thinking to learn which response is needed and when.
I think that's exactly right! A common saying at many tech companies is "done is better than perfect".