Hacker News Reader

Comment by Xcelerate | Hacker News Reader

Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style.

We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand.

We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge.

What I take from this is yet another situation of people arguing about something highly subjective that is closely tied to their identity. Good programming is not an objective concept. People respond differently to different programming techniques and what works better for one person may greatly confuse another.

View on HN

Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)

A lot of programmers are insecure. They were the nerds in school, not popular, not good at sports, etc. Programming is the one thing they can do where they feel in control, and confident. So they naturally tend to be defensive about it.

> A lot of programmers are insecure.

You mean a lot of persons? If you don't, I wonder where you got this from. Personal experience maybe?

Anecdotic: I have always been good at sports, popular, and confident, and I criticized this article because he used a kind of link-bait title (should have been "Today I learned about inheritance and it's awesome", something like that), and he also turned out to be selling programming books like he was an expert, which is scammy, and reinforces the fact that you can only find good books through recommendations from your peers.

So he didn't know some aspect of polymorphism. Is that pertinent to his book? It's not as if using if/else constructs is bad or wrong. In some fields of development it would be preferred, for blatant clarity.

Does it follow that his book is bad or wrong because it was not written with understanding of this aspect of polymorphism?

"You can reuse code with inheritance. Absolutely crazy. Brilliant.

All of this blew me away."

I don't rightly understand why you would choose to assume the worst possible interpretation of that line and take it as grounds to heap scorn upon the writer (it strikes me as a tad uncharitable, and needlessly hostile), but

http://news.ycombinator.com/item?id=5160287

> Anecdotic: I have always been good at sports, popular, and confident,

I'm fairly certain this is a lie, given the way you've presented yourself in this thread.

I'm fairly certain you don't think it's a lie, and you are just envious.

Either way, I don't see how any of this matters. I explained why I criticized the guy, and instead of working on that, you tried to undermine the anecdotal part.

anecdotal

-1 for the ad hominem: "... and you are just envious"

Are you kidding me? I was copying his style, to show him how irrelevant and childish the statement was.

Also, it wasn't an ad hominem, since there wasn't any argument being debated. Get your fallacies straight.

I guess this is why you have 9999 submissions with 1 point. To be able to go around downvoting and incorrectly calling people out on a fallacy (the new trick you have learned).

> Also, it wasn't an ad hominem ...

I don't get it. What's the point of replying to a perceived false accusation of ad hominem with three more ad hominems?

"Get your fallacies straight", "I guess this is why you have ...", "(the new trick you have learned)"

Let me give you an honest advice on how to not be a fallacies noob. Try explaining what's wrong with their argument, without incurring in the arrogant attitude of just mentioning the name of the fallacy and downvoting. That way you will stop trying to make every argument fit into a fallacy, and start truly understanding what (if anything) is wrong with it.

I must have corrected the 'ad hominem' thing at least 5 times today, so I'm tired. It's not ad hominem if it's not trying to undermine an argument (it's just insulting or trolling), and it's not ad hominem either if it's relevant (eg: programmer does not know the basics, that fact comes to light, and is used against him in a programming discussion).

No undermining, I just think you're lying about being popular and confident and good at sports.

It's ok if that upsets you.

It's really weird for you to jump to that conclusion.

-1 for the ad hominem: "... given the way you've presented yourself in this thread"

I spent a few years as the sole maintainer of a moderately complex enterprise app written prettly much entirely in PLSQL. Hundreds of thousands of lines of it. By the time I left a reasonable proportion of that was code I'd added.

A few months after I'd left I got a phone call from the guy who'd taken over the project - he rang specifically to compliment me on the code and how easy it was for him to understand what was going on and how much better that had made his work. Didn't really know how to respond as I've never had that before, but it was nice.

Not blowing my own trumpet, so to speak (although it is something I'm kinda proud of) but to provide a counter data point to your PM's

Although I've never gone to the effort of actually calling somebody up to thank them, I have gone out of my way to thank colleagues whose code I've been maintaining if I have found it easy to work with.

Code that is: consistent in style and approach (even if it's different to mine) easy to to reason about has clear comments detailing why something was done the way it was

is hard to do consistently, and very often stands out from the spaghetti code that's present in other parts of the system.

The reason I do this is firstly to let the person know I appreciate the effort they have gone to, and secondly to signal to the other developers on the project that this is something worth trying to attain, and at least one person values these things.

Thanks for sharing your story! Now that I'm a freelancer, I see lots of different code bases, and I've seen a few that are really nice. It feels great to see and appreciate someone's else good work. I make a point of letting the people in charge know that the previous/other contributors have done a great job.

One of the great things about joining a well-written project is that usually I learn something new. If that guy was so struck by your code that he called you up, I bet he learned a few things, too.

As in the OP's story, sometimes the code I learn most from isn't immediately obvious, and I have to "go with it" for a bit before I see what's happening. But that takes some openness, perhaps something like what Zen folks call "beginner's mind."

There are times when, like you, I have to start tearing things out and rewriting chunks of functionality, but in general I think programmers are too quick to take that step. My PM anecdote taught me the importance of reading other folks' code charitably, really trying to understand why they made the choices they did, and doing my best to respect and follow their approach. Textual interpretation has the "principle of charity," and reading code probably should too.

I maintain an old ircII script. The guy that originally wrote it (srfrog - the LiCe script) is just an amazing programmer. The whole thing is clean and beautiful.

I feel ashamed when I touch it I dirty it up.

Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimizations that can be made to actually improve machine performance; these can be found reasonably simply through profiling. At the end of the day, most arguments revolve around "style".

It's actually a very tricky subject. If you're working on SMe apps, including startups, most often a given project'style will flow from the lead (or the person/people who initiated the project). They may be good, they may be bad. Invariably, less experienced developers are hired and learn Ro code following this style. Eventually, those less experienced developers become experienced, and leave to persue other projects. And they take that style with them.

Depending on the role they have, there is likely still a lead above them. And this is where the arguments begin. The lead had his/her style. The new dev has experience with another style, and it may or may not mesh with the new lead's style.

And so the problem perpetuates.

It can be very difficult to work with those devs in the early-middle stage of their career. If they are good people, they learn to be flexible, adopt the best parts of all the styles they are exposed to, and eventually become great leads. But many will not, are confrontational, and ultimately poisonous to the teams they are on.

If I can quote my favorite philosopher, Ted "Theodore" Logan: "if the only true wisdom lies in knowing, then you know nothing"

A programming argument that can be convincingly shown to be only a matter of personal preference is irrelevant, but I strongly disagree those are that common. Various programming language constructs have various properties and if you had the opportunity to maintain a single project for some 5-10 years, to experiment with different implementations of same functionalities etc. you learn that certain techniques prevent problems and certain others provoke them.

Look at the writing of Joshua Bloch based on his experience with designing the Java standard libraries, you will find plenty of arguments that you could think are about "style", but in fact he always includes a very detailed and concrete discussion about why one way is superior to the other. Similarly with some of the articles of John Carmack from idSoftware. For me the revelation was that there is indeed no such thing as "style" so that some techniques are just "prettier" than the others, it is all a matter of consequences a given implementation has for other developers using the code and for its maintainers.

When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted.

There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.

If any programmer is certain of the superiority of 'his programming style' (singular), then that programmer is insufficiently humble and lacks knowledge of multiple programming styles. Tragically, if you don't know what you don't know, you can think you know everything and can thus speak with confidence on a subject.

One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. My suspicion is that a pretty consistent picture would emerge, with a number of caveats and YMMV's, with an eye for the actual, intended and possible future use cases, the language, the maturity of the project, etc.

I can agree with some of your points; however, I believe you make too many simplifying assumptions.

> There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.

Hardly anyone on here would disagree that these are good programming practices (or so I think...), but the question becomes: what is the best way to favor immutability? FP solves that problem but many people don't like the all-or-nothing approach. Same with referential transparency.

> One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language.

Programmers under 30? Think how many languages exist that aren't even 30 years old! This is one area where I highly disagree. I have found that age matters very little with regard to someone's ability to write code. I have seen code written by "veteran programmers" that is worse than some teenager's weekend project. I'm not denying there is a correlation, but I would say it is a very weak correlation that probably isn't worth mentioning.

I do agree with programming experience, although I'll add the caveat that programming seems to be interesting compared to other subjects in that the rate at which different individuals become better at it seems to vary very dramatically.

  but the question becomes: what is the best way to favor immutability [..]

To which my answer would be: it doesn't matter, as long as you consider it and try to apply/enforce it wherever it makes sense.

  I have found that age matters very little with regard to
  someone's ability to write code. [..]

I was thinking of their greater (life) experience; in my experience they tend to be more nuanced and open to different ways of doing things, which makes for nicer, constructive, conversation.

You're talking about the Dunning-Kruger effect, it's everywhere!

I think that programming is very close to how we actually think. Programmers tend to be objective people who like distinguishing good from bad and better from worse. They're generally analyzers to the core.

But we all have some personal aspect of how we see the world. How we organize logic, view priorities, and such, is all personal and unique, no matter how much we may feel that it's objective.

Programming is an expression of that inner thought life. It's how you organize, categorize, and optimize, all laid out in bare raw form. It's an expression not just of our identity, but to an extent of how we exist. Being who we are, we usually tend to think highly of ourselves and our way of doing things, so it's only natural that we think highly our code style.

both arguments are right, but not because of a subjective goodness. because they're talking about 2 different parts of the patch:

- the "bad" part is RowType.for(), where a type is dynamically called forth based on manipulations on some string. I agree that a more concrete mapping from string-to-type would be preferable (I'm assuming the use of a string is required for some reason).

- the "good" part of the patch is that he replaced a conditional with type dispatch. I agree that this is a basic technique of object-oriented programming.

I knew the comments were going to be exactly as you described before I clicked the comments link (and had this in mind http://xkcd.com/1053/) and I'm really glad your comment is on top and visible for everyone to digest before they start handing out their own judgements.

+1 for Good programming is not an objective concept.

== Programming sucks nowadays.

There is not even a consensus on what is good in programming! Take a look at other professional cultures: people work extremely hard to develop the skills that everybody else in their profession have. What does a software developer do? Whatever they like on their own, there is no professional culture whatsoever: "Don't give a crap about the humankind's experience, I'll invent everything on my own the way I like".

This is actually unbelievable how different programming is in this aspect from other disciplines. I don't even mentor Junior Developers because of that, as I can't refer to anything authoritative and say "Do it like this" because there is always a bunch of folks that do it the opposite way. There is almost nothing to rely on.

The nature of programming is that any consensus solution can be automated. That's a good thing.

I'm always amazed though the extent to which that isn't followed through on. Consider the code for logging in and storing user credentials. The level of collaboration on this is at the level of a list of best practices. Why are we still letting anyone (re)write this code?

Okay, how do you use /bin/login over HTTP?

Situations change. So do languages. I hope you can find an Algol compiler, but not Algol-68---that's too new for this code.

If you can't draw upon your past mistakes, or techniques that have failed for you before, you shouldn't be mentoring.

Put more positively, use your experience to guide others.

It's not that there's no professional culture in programming, it's that programming has a problem/solution space orders of magnitude larger than any other profession that has ever existed. If we could agree on some constraints of what software does and what the priorities are then we could develop more concrete professional standards, but that's not how it works. Software is the stuff of pure thought; it is layer upon layer of abstraction that towers up to henceforth unknown data processing tasks. As messy as it is, we can only strive to further the state of the art as it applies to the task at hand. There's no way to definitively pit NASA's process against Facebook's against a random perl data cruncher. None of this means programming doesn't have a professional culture, just that it will take a while longer to distill the strongest knowledge and it will necessarily be a broader than the other professional standards.

Another thing we can expect is further specialization with different standards.

> There is almost nothing to rely on.

You could rely on your experience.

I would have thought www.swebok.org (Software Engineering Body of Knowledge) represents some consensus on what is good in programming?

There's stuff to rely on, it's just that mostly nobody wants to spend the time reading it.

I dont agree with that.

There is a confusion about programming though, an idea that it is a purely technical discipline, like laying bricks when in reality its a design discipline, like designing a building.

If you wanted to build a house you wouldnt just hire a couple of bricklayers and tell them "do it". Yet thats what happens in programming...

These two statements are not mutually exclusive - the technique is basic and sometimes its drawbacks may outweight its benefits. While applicability of the technique in a particular situation may be a matter of discussion, ignorance of its existence is shocking considering that the author has reportedly written a book on programming.

A technique can be both basic/obvious and not a course of action that everyone would agree upon.

The surprise isn't that he didn't make the choice to do it that way. The surprise is that the choice didn't occur to him. The feedback would be very different if he simply had made a different choice.

Reply on news.ycombinator.com