[defdac]

With 10+ years of being a professional programmer I think you will automatically get the insight of being agnostic is really the only way of surviving and keep your passion for your work.

Those who fail at this will stop working as a programmer, move out in the woods, build a cabin and live happy as a farmer.

When you're young you will inevitably always have an attraction for styles that ring the most true to you. You have one single hammer you have learnt to use or even worse, have heard really good programmers at Hacker News prefer to use, and therefore you use this hammer for everything.

You are a poser.

Most programmers have been there. Posers can be extremely sharp and useful if they get to do what they're good at, but they are posers nevertheless and at the start of a humbling journey to agnosticism - getting shit done instead of bickering and posing.

[j_baker]

You're missing the point. The purpose of this post was to illustrate how silly little differences in coding style cause lots of unnecessary work. The agnostic's version was the best in this illustration because they knew what the requirements were. You can easily adapt the ascetic's, the librarian's, and the purist's version into the "right" code as well.

The point is that we each have our own different style of doing things, and frankly, I'm a bit incensed that you're using this post to hold up your way of doing things as the "one true" way of doing things while calling everyone else a "poser". I think this comment is exactly what the author is trying to say is bad.

[gbog]

I don't know. Greatly influential hackers such as Torvalds, van Rossum, pg, rms, etc. do not seem to illustrate agnosticism very accurately to me.

[voidlogic]

Sure, but these guys each have the benefit of being King of their Kingdom. Most people writing code have neighbors they need to get along with and cannot rule by fiat.

[sliverstorm]

Not only the benefit, but the responsibility. By mandating a certain "way" and ending the discussion, they essentially nip "the narcissism of small differences" in the bud. As the leader, this is one of the useful things only they can do.

[michaelochurch]

My opinion: there isn't one single good way to do programming. Often, you want your interfaces to be referentially transparent (stateless). Usually, it's best for source code to be in the functional style as well-- but not always. Sometimes, mutable state is exactly what you need. But it shouldn't be the default, unless you're working at a very low level.

There are, on the other hand, a lot of bad ways to do programming: FactoryFactory nonsense, software-as-spec systems, waterfall methodology. We've seen them several times in our careers and have a hair-trigger sensitivity to stupidity, because we've seen it cripple or kill projects.

Great programmers tend to be unforgiving in their condemnation of the bad ways of doing things, but hesitant in accepting one programming model-- even a very good one like Lisp-- as being the One True Way of doing things. As soon as you have a One True Way, some very smart people disagree with you-- and that's a good sign that you're at least partially wrong.

In other words, it's good to be passionate about using the right tools for the job. It's a problem when people think the same tool is right for every job.

[pionar]

It seems that in saying that having a One True Way attitude is wrong, you've developed a Not True Way attitude. Waterfall methodology might work just fine in some situations, software-as-spec works on smaller applications moving to a different platform, and I haven't found one, but I'm sure that the FactoryFactory nonsense can work to keep order in extremely large codebases (I work on a large codebase, and haven't found a need for super abstraction, but that's just me).

Calling these unequivocally bad is counter to the argument you're presenting (which I happen to agree with).

[sliverstorm]

software-as-spec is out of vogue now? I may have misunderstood, but I thought software-as-spec is the same thing as test-driven-development, which I could have sworn is still lauded.

[RogerL]

Can you explain why you think they are the same? SW as spec is problematic because whatever the sw does is interpreted as being what it is supposed to do. So how do you identify bugs? At least with TDD the tests serve as some kind of documentation.

I'm no fan of either, generally, but I also don't work on "move fast. break things" type projects.

[sliverstorm]

I'm not a software developer, so I could easily have misunderstood what sw-as-spec is.

I definitely do not work on "move fast break things" projects.

[edgarallenbro]

Either you're being sarcastic, or defdac's point has flown completely over your head.

Trying to imitate them does not make you them. It makes you a poser.

[e40]

How about he's not being sarcastic nor being a poser??

[pnathan]

Note: This is a created dilemma, with one horn being a strawman (with namecalling of those who chose that horn), and one horn occupied by the chosen "good position". This is a rhetorical device used to force decisions to the chosen "good position".