Speed matters: Why working quickly is more important than it seems

Take time to pause, reflect, think, and enjoy your life experiences.

Even when it comes to work-related activity, there are times and places to do things quickly and there are times and places to do them deliberately. If nothing else, just for sanity's sake, it is important to pace yourself through a day, through a week, through a month, through a year, through a career. Even if speed were exactly correlated with maximum productivity and effectiveness, it is vital that you have times when you simply feel you can enjoy being at work, being with people, doing your activities, without everything feeling you have to work like a machine that will be evaluated by engineering standards only.

Even more, we all have different personalities and some people do not work well if they feel they are forced to work at some arbitrarily quick pace as opposed to one that suits their style.

Finally, even speed as a factor can vary with your activities as you develop skills in those activities. When I began years ago to try to write things, I was agonizingly slow about the process. I felt I had a quick mind but the process of getting what was in my mind down on paper made me feel plain stupid. Whatever I did, it would never come out right. Through a very tedious process of writing and re-writing, it would eventually become passable and that was it. It might take me a week in such cases to write something expository of modest length. Yet, realizing this was a weakness, I worked damned hard to fix it and, through a process of many years and countless hours of effort, I reached a breakthrough point where I could do "walls of text" (in the phrasing of some) in 10-15 minutes and produce quality stuff. I now write very quickly and effectively. But had I tried to do so years ago with my limited abilities at that time, all I would have produced was hash.

So, lighten up and do it in your own style. Yes, speed does matter. But it is only one of many factors that will determine how you do at work or, even more important, at life itself. By all means, apply yourself well - be diligent, hard-working, etc. but do it fast or slow as suits your needs and your own style. At least that is how I view it.

It's not faster today - if you kept working, you'd presumably get more than zero done. But you'd also create more bugs, and you'd come back more tired tomorrow. Coding is not an assembly line; your brain needs to be fresh.

Taking time to pause, reflect,and think is the same. It's slower in the next minute, maybe in the next hour. But stopping to think and realizing what is the right thing to do can save you days of waste.

My first boss said, "You need to learn when the most productive thing you can do is go look out the window for 15 minutes." After 30 years, it's still good advice.

I'm ignoring your point about work-life balance here. All I'm saying is, too much emphasis on speed slows you down, even only considering work.

If I prioritize quick responses and turn arounds to requests that are important, provide value, and allow me to improve important skills, that is not incompetence.

If you de-prioritize items, regardless of their importance and value but simply because you don't want to do, that could quite conceivably be called incompetence. However that rests on the assumption that you don't want to be competent.

I generally want to be competent. When there are things I don't want to do, it is usually because they are part of a bad, inefficient process that I haven't managed to change yet.

The idea is that any decision that is straightforward or easy to change should not be sweated over for any appreciable amount of time, and in fact can be deferred indefinitely (deciding not to decide).

Meanwhile, any decision or indecision that will have long term repercussions should be considered at length and with all due haste.

I mention indecision here deliberately, because things like deciding not to put authentication into your application in version 1 counts as a decision, one with far reaching and usually fairly aggravating (IME at least) long term effects on the project. Others would include thread safety, the ability to cluster or shard your design, multilingual support, audit trails, etc. If you are the only solution in the space then you often have time to correct these mistakes. But if one of your competitors figures these things out before you, you can find yourself in real trouble (one of the aspects of the Innovators Dilemma).