Finish the work you're assigned, and deliver it with high-enough quality and at a decent pace. Over-deliver when you can, shipping more and better than expected.
**good engineering requires having reliable shallow intuitions about how things work**.
It's not fully shipped until it's fast.
to go fast, do less
The CPU," he said, "runs at a certain speed. It can execute a fixed number of instructions per second, and no more. There is a finite limit to how many instructions per second it can execute. Right?"
"Right," I said.
"So there is no way, really, to make code go faster, because there is no way to make instructions execute faster. There is only such a thing as making the machine do less."
He paused for emphasis.
"To go fast," he said slowly, "do less."
Kas Thomas, I can explain
Don't think in terms of making a slow piece of code run faster. Instead, think in terms of making it do less.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Personal note:
Have you noticed that Git doesn't confirm anything when you use some commands? This is due to the Unix Philosophy which aims for simplicity and provides feedback only when necessary. Git adheres to this philosophy, so when no confirmation message appears, it means everything went as expected, allowing you to focus on your work without distractions.
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' . . . I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
Don't be afraid to fail. There's a wonderful poem by Rainer Maria Rilke that talks about the biblical story of Jacob wrestling with an angel, being defeated, but coming away stronger from the fight. It ends with an exhortation that goes something like this: 'What we fight with is so small, and when we win, it makes us small. What we want is to be defeated, decisively, by successively greater things.'