Think versus Blink

Question

How often do you hear people say things like:

That’s easy just do blah.

Can’t you just do blah?

And how long do you think it took to come up a solution like that? And the answers are too often and not long at all.

Some people will argue that it’s a good thing because it saves time. However putting this into the context of software I will say I disagree totally. In real life scenario, decisions are often made in a blink of an eye, the consequences are however extraordinary, in a disaster way. Whenever there’s a problem that needs to be solved the Quick Thinker (QT) always gets the most eyeballs because they appear to be surpassingly good to be able to answer the question straight away. Thorough Thinker (TT) will often sit back, think about the problem over and over again to come up with a proper solution however this will often require more time, but the end result is extraordinary, in an excellent way. But the world doesn’t work the most optimal way as we all know it and have made TT almost facing extinction (my experience has shown more people are shortsighted and this is how the world has become).

Now the question is how I should balance between being a QT or a TT? If I spend too much on researching the solution my boss would often look down on me and think I’ve been wasting my time. If I spend as little time as possible and finish the problem quickly, all the shits will get back to me pretty quickly and end up rewriting most of it (spent more time, and the boss...). A simple example can be doing TDD or not (we are doing TDD by the way). I am kind of stuck in the middle that doing what I am being told and trying to do a better job, but it's very hard, especially from a mental point of view, it's driving me crazy. I know life is all about how well you can balance but I just haven’t been too good at it just yet. I would like to hear what others have to say about it. Thanks!

Updated:

Another related question can be that what happens when a senior/architecture guy "blinked" a solution and ask you to implement but by heart you know it’s the wrong way to go and needs more time to think about it. This has happened a lot. Business people will say just do what you are told because he is “title blah” and this saves money and time, we get a better ROI blah... And managers will often follow what their bosses they and likely to think. This is just too bad.

Answer 1

It seems that your perspective may be a product of the environment you are in. My boss has no problem if I tell him "I have to think about it", or if I say "off the top of my head, we could try this, but it will take some further analysis/research to know if it will work."

An experienced manager should know that good solutions take time. Not only that, but good solutions are usually backed by some kind of more detailed analysis, not just knee-jerk reactions to problems.

Answer 2

The word "just" always frightens me. Too often it means that the person saying it doesn't want to think about the actual problems at hand, and think that it can be solved by simply using some pat answer.

In some cases, it's true, but more often than not it's a sign of intellectual laziness.

OTOH, sometimes it's too easy to overthink a problem. And in those cases, getting something working to give more data to use to further refine your solution is probably a good thing...

Answer 3

There are a bunch of articles about this debate... It's sometimes termed the "Think (TT) vs Blink (QT)" debate...

http://www.google.com.au/search?q=think+vs+blink

A popular book which expounds the QT view is Malcom Gladwell's Blink.

There was an article about it in Australian Science recently... There's a copy of it available online: Think, Blink, or Sleep on it?

Another interesting article: Blink or Think? which mentions the book Think! by Michael LeGault

Answer 4

Not really an answer, but you might want to read The Parable of the Two Programmers. If nothing else, you can rest assured that roughly the situation you describe isn't new.

Answer 5

I hope you're doing TDD instead of TTD (not sure what that is).

TDD isn't so much about quick thinking as it is about incremental design. It breaks a problem down into small steps and attempts to build up the solution incrementally, refactoring as you go. You want to do the simplest thing that could possibly work and build up your solution methodically, continually improving the design. In that sense it is a very thorough method.

What you don't want to do is have a complete solution prior to beginning to do anything. Perhaps this is what is tripping you up. You don't have to quickly think of an entire solution, then build it up via tests. It's enough to have a rough idea of where you are going with it, enough to get started writing some tests, then let the solution evolve.

Stop trying to do BDUF (big design up front). Relax and simply do EDUF (enough design up front) to get you going and to make sure that you're starting down a sound path. Then continually evaluate where the solution is taking you and refactor to improve your design as you go along.

Answer 6

It's part of your job as a developer to say "no, I can't just do that", or "no, it's not so easy" and give solid reasons why.

It can be frustrating if you don't have those reasons at hand. But if you've put any thought into the problem already you have probably already evaluated the "easy" routes, and are aware of at least some of the gotchas. If for whatever reason you haven't had time to think about it, "I'll get back to you on that" works well.

Answer 7

I don't claim to be experienced at all (I'm still in college! :-), but I had a couple of thoughts...

• I think that one middle ground is to try to make sure you're working in a place where, sure, they'll want to see some kind of output every day (week, month, whatever), but that it DOESN'T have to be code. In that way, you can try to be more on the thinking side, but you'll have something to show for it on a regular basis. And it doesn't have to be code.

• Maybe also try to be as open with your manager/supervisor as you can with regard to what you're doing. That way he can get a better feel for your strengths, and thus your value for the company. This is as you try to work on slowing yourself down or speeding yourself up, whichever you need to do.

• In defense of the blinkers (of which I might well be one), I want to believe there IS a place for us on the team. I just think that, if the managers are worried about having code be well-structured and not just quickly hacked together, they shouldn't assign projects to just one hacker. Instead, the hackers should work on larger products as an integral part of a team, with a couple of thinkers on hand to think of the big picture and help guide the blinkers (who then produce modules etc. for the project at a ridiculously fast rate). Of course, for new hires, this is hard for the managers to figure out right away.

Actually, with regard to the last point, I'm wondering if it's worth noting that maybe you want to balance blinkers and thinkers over the whole company, not per person? That is, if you have 10 pure blinkers and 10 pure thinkers and they work in a manner a bit like I'd described above, then I would wager you have greater throughput overall... if everyone works together seamlessly.

Then again, in order to deal with the potential trouble of the blinkers and thinkers arguing it out over how coding should be done, you should have SOME middle-ground people who work not only as coders but as intermediaries who help calm things down.

Better still, of course, might be if the people promoted to managers were all this type... while still somehow being good managers. But what are the odds of that? :-)

Thoughts, anyone? I'd love to hear what people with more experience think about this. Maybe I'm barking up the wrong tree.

Answer 8

My natural reaction to this is a sort of hybrid approach. When given something, I tend to quickly pick various edge cases that may give the requester pause in asking for something as there is a good chance something either wasn't well thought-out or wasn't fully communicated. Finding the edge cases quickly is a skill that can take some time and practice to develop. At the same time, being able to get the time to do a more thorough job is a separate point that at times because of giving those edge cases can buy one some time as it can usually take someone a few cases to get what is happening and that it isn't a stalling tactic. Part of this is understanding the other person's view of the problem which may be overly simplistic and/or optimistic, e.g. someone learning that criminals actually don't follow laws which most would see as an obvious.

As for the architect giving something that doesn't feel right, why not go talk to this person and have these concerns addressed? There is also something to be said for ulterior motives in doing some tasks, like intentionally sabotaging someone by getting them to do the wrong thing without telling them it was wrong. There can also be office politics where someone may want to make a point to someone else and do something less than stellar for them. Other times though, the band-aid solution one has to implement may just be part of a multi-pronged approach where the better solution is coming but isn't going to come overnight.

Sometimes I have just followed orders after being shot down for alternatives, but sometimes bringing something up can cause a, "Oh, I didn't think of that," reaction that can be quite handy in some cases. Sometimes doing what feels right can bring surprising results. Conventional wisdom can sometimes be really really dumb and common sense rather rare sometimes.

Answer 9

One think that I think most people underestimate is that the experience of implementing something, no matter how bad it ends up being, often gives you insights into some of the finer points of the problem that you would have never gotten just looking at it on paper or at a theoretical level. I'm a firm believer in diving right into the prototype and then either throwing it away and starting over with the experience gained or incrementally improving it as you eat your own dogfood and understand the problem better.

Almost every piece of code I've ever written that I can sincerely say I'm proud of had a version 1 that was frankly terrible, but the learning experience of doing it wrong was what enabled me to do it right.

Also, when it comes to detail stuff rather than big picture stuff, I think that already having an actual implementation to tweak, rather than trying to discuss things in the abstract, often helps speed up progress.