I’m a doer. And being a doer, I’ve done hundreds of projects. I will be the first to admit that most of my projects fail, or don’t even get finished. Many of them are also just one time things (eg. I need to do such-and-such process to solve a lot of problems today, so I make a program that does JUST that). However, I’m also a redoer! When a project of mine shows promise, or gains support, I do it all over again. I examine the project, looking the good, the bad, and the ugly. Rethink most of it, and make it great, brilliant, and beautiful. That, I think, is the most important reason why I have any success at all while still being a doer.
I’m considering moving into research / teaching.
That way I can be a full time “talker” in the programming field 
This is precisely what I’m suffering from at the moment (well for the past few months). I’ve been reading a lot about the new .NET 3.5 framework, C# 3.0, MVC platform, but I have hardly done any actual coding. So, I’m a reader/talker and not a doer. I probably know more about these .NET technologies than those who are coding but I have practically nothing to show for it.
2008, a time to change.
I’m definitely a doer, to a fault. I don’t plan enough ahead for things to come out as well as they should. But at the same time, the one major success I have had would have been lost had I not just dove in. So I’ll stick with it and see if I can be a slightly more deliberate doer.
I’m a thinker. I think through and plan what to do well in advance. I do not rush. Where does that place me? I do not believe in dichotomies, in fact, they are convenient, attractive, suggestive, and the cause of most of humankind’s evil.
There’s a reason why governments are required to do studies: if they make a decision that turns out badly, they’ll be held accountable at the next election. On average this means huge waste, but in each individual instance a study that says “do nothing” costs less than the highest estimated potential cost of a failure. And there’s always plenty of expensive failrues to point at and claim that an additional study would have prevented the problem.
Waste six million dollars on a study for a bridge that will never be built or risk building a bridge that you can’t offer a 105.35% chance of having no accidents until after you’re dead and buried and can’t be held accountable. Go on, you choose.
And despite the miracle of private enterprise, when you have 83 levels of vice-presidents between the guy doing the work and the guy who owns the money used to pay the guy doing the work, you’ll find most people will value appearing to save the owner’s money over risking something that might make the owner some more money.
“Doing” is important.
“Talking” is safe.
Put your job on the line when success means the owner gets a new porsche (and you get the promise of a 2% raise at the next leap-year review) and failure means you get fired (but the senior VP in charge of product planning coordination still gets his annual bonus for elimination of unproductive works who do stuff instead of planning) and then you’ll understand why safety is a popular choice.
I’m not saying that talking is better than doing - just explaining why the 80% of programmers who never read blogs are going to keep on putting their own personal interests ahead of, for example, actually producing working code.
For that matter, I bet it’s not a coincidence - the people who don’t care about getting actual products into the hands of actual users have nothing to gain from learning ways to do that. But if they get a job at an I-Bank instead of a Web 2.0 startup, the ability to play the meetings-and-planning-and-talking-and-UML-and-so-on game can keep them safe for a long time.
Me? I’m a talker. All bluster and eyebrows, and precious little code.
… Buahaha!
More than that, writing actual code is often a way to “win” the endless architecture debate.
The KDE project has a saying: “the one who does the work decides”. As with any major project, there’s a lot of discussion going on - but while some people discuss endlessly, others produce working software, artwork and documentation. This seems to work quite well.
(gotos in my C# code because they are faster than restructuring my loops)
@KTamas: this is the thing for you: http://xkcd.com/292/
The more I read this blog, the more I see posts like this:
"You should think of this aspect, it is improtant. But surely, other aspects are also important."
For me, such posts don’t have any value.
Current software is bad. If working code is so important, why there are many clones of same class apps and they all are bad?
“Start code, start open source”.
Yeah, I started. But when I wrote a big chunk (almost finished) of it I realized it have complex parts and bugs that are above my abilities to track and solve. So, maybe I better think first next time and make better design/do something simplier.
On the whole I’m probably more a talker/reader than a doer, which is OK, as I’m not a professional programmer (far from it). The few times I ‘have to’ code for my work it’s often very short and simple stuff. However, the biggest programming project I ever did came out of a frustration with too much talking and also showed me the benefit of actually getting something to work. Part of the problem was that the specifications where highly unclear (think small research related software), partly by design (it was supposed to ‘evolve’). However, we spent months talking about what we want to, should and could do without ever getting anywhere. It was exactly what has been described above - we kept talking about the same ‘what ifs’. Time was running out, and I simply took over the coding process (it didn’t help that our main/single software engineer no longer lived and worked in the same geographical area), and started to get stuff working. Of course it was a pain to later bugfix and change things, and in retrospect I probably should have done some things differently, but at least we had something we could work with.
“You cannot plough a field by turning the soil over in your mind” - anon
I’m a listener. I listen to what the user/customer/manager says he wants and why he wants it, then I go code the appropriate solution (which is usually much different than what was asked for). I think talkers use up a lot of time trying to make sure everyone is on the same page, which is fine, but if you have the right ‘architect’ (no matter what their actual job title is) talking directly to the person with the problem to be solved, the amount of talking necessary should be greatly reduced.
One major point is most of us write software for private companies who have to think about the money they spend. You cant not compare goverment agencies/Public sector with real work. The amount of money government agencies hemorage on doing nothing is really quite amazing.
A doer I guess.
High level architectural talks are lost on me sometimes if they can’t really contribute to anything practical and down to earth.
At some point it just becomes too abstract to see the point of it all.
You hit the nail on the head when it comes to the Open Source projects.
If there’s one thing I hate it’s finding this l33t looking SourceForge project which doesn’t have a single line of code in the repository and is still in the “planning phase” when you look at it in detail.
I want working code dammit!
“In my 12 years, I have seen a lot of talkers. They all had one thing in common, they got fired.”
In the Public Service they get promoted.
Think…Code it…Find Faults…Think…Code it…Find Faults…Think…Code it…Find Faults…
Excellent insight and a great article. One of my biggest sources of frustration is dealing with self-annointed “gurus” who talk a big talk about architectures and methods and other obscure and bizarre ways of doing things in software applications. And when it comes right down to getting an answer to the question: “yea, but why would you want to do it that way??” the answer is invariably: no reason, except maybe add another layer of complexity.
I have heard about analysis paralysis, but I think that it is rare. I have never experienced it in any project that I have been on. Planning and design are shortchanged, or skipped altogether, far more often than they are overdone. I am fairly certain that the continued popularity of the term “analysis paralysis” stems from the need for cowboy coders to justify themselves while denigrating the efforts and concerns of those who advocate a more reasoned approach to software development.
Tim Dudra said it for me, in his post above:
"Talking up front is essential to do something that is worth doing. Yes, if you just dive in and do you will likely get something but virtually never what was intended, never on time, never on budget and always with an excess of bugs. "