In general daily life, I find that I run across two kinds of people: those who think before they act, and those that act before they think. The folks who think before they act (henceforth “thinkers”) seem to be easier to deal with than the folks who act first (“actors”). I appreciate the thinkers. I have a problem with the actors.

The actors never seem to realize that you can’t always necessarily fix bad action with more action. Quantity doesn’t make up for quality.

Let’s apply this to development. Say you’re writing some business logic with an API that will be consumed by other developers. Even if it’s simple logic, stop and think: If you were the consumer of the API, what would you like out of it? Is it robust enough to support all the cases it’s going to need to? (Did you ask your potential consumers to verify that?) What about doc? Consistency of naming and usage across methods and classes? Don’t make it so that some methods return true on success and others return false…

Or how about defect fixing: The actor will start coding before figuring out all the ramifications of what they’re doing, then realize that the fix they just made actually breaks three more things. The thinker will follow the related code paths through and apply a more correct fix.

Sounds common sense, right? You’d be surprised.

Got a question on how something in a standard framework (.NET, Java, etc.) works? Stop and think! Dropping your laptop on a coworker’s desk and interrupting them with a question or five isn’t always the best way to go. You could try searching Google - chances are you’ll find what you’re looking for. Are there docs you could look at? It might take a little more time, but maybe you’ll learn something along the way… and the stuff you learn will probably help you out in the future (and save your coworkers some time).

Now, I’m not saying that people shouldn’t help other people. I’m all for everyone carrying their own weight toward a common goal, and if sometimes folks need a little help, that’s fine. What I’m saying is… help shouldn’t always be the first resort. Try to figure it out. Stop and think for a second. Still can’t get it? Stop and think just a little longer - this is the part most folks miss. Your first failure does not necessarily equal “blocked.” If you still can’t get it after puzzling on it for a while and you’ve exhausted the standard methods of helping yourself (doc, search, etc.), then ask for help. Folks will be much happier to help you if you have already researched the topic yourself and legitimately came up dead-ended.

Building something with weak requirements? Stop and think! If you don’t know what you’re building, you can’t build it. Even in an Agile environment you have to have some sort of direction before coding. Too many times people code before planning. I’m sure you’ve seen it - spaghetti code that makes absolutely no sense, grown in upon itself without hope of ever being untangled. Stop! Think!

Got a small feature that needs to be added? Don’t just tack code on the side. Refactor your code if you have to. Test it! Especially in the case of an API, you can’t just throw some code in there without testing it - frequent releases of your API to fix bugs that appeared because you didn’t test your new feature not only causes churn in consuming products but also makes people lose confidence in the API.

Yeah, that was more of a rant than anything else, but I’m really tired of actors. At the store, at the sandwich shop, in the tech world… come on, people. Stop and think. I promise I won’t dock you for taking a couple extra seconds to get it right the first time.