The author said that most comments in code are duplication, not all. And that is true in the average case. Most code comments explain what the code is doing and how it does it, and so need to be updated when either of that changes. Then they get out of date, etc.

Typically, comments can just be merged into the code directly by extracting well named methods, and using better names for variables.

Good comments tend to not be redundant, they tend to tell you "why" information and be written at the level of intent rather than at the level of implementation. And thus they don't need to be continually updated when the implementation changes.

> Good comments tend to not be redundant, they tend to tell you "why" information and be written at the level of intent rather than at the level of implementation. And thus they don't need to be continually updated when the implementation changes.

This. The exception being when things have to get messy for reasons of performance or other non-obvious constraints- at which point, the comments should document why it's messy, but may also provide some guidance around the messy code.

While I can't disagree with your statement, that's not what I got as the focus of his comment. The part about code duplication is the last sentence of the comment. Before that he does state that it would be better to write precise readable code, which no one disputes (I hope), but I don't see that as a reason to discount proper comments.

I have written comments as he described where they practically duplicate the code they are describing. But when I do that it's because I'm working with multidimensional arrays and I use comments to remind me what section of what array inside what array I'm currently working on. If I change the structure of the array and don't update the comments then that's my fault.

I was reacting more to the first sentence, where he said that "poor, incorrect, outdated, misleading comments" must be the most annoying aspect of comments. I believe he is right in this regard, but this where I feel he is blaming the tool for someone misusing it.

> His questions are not about writing code, they are about writing algorithms.

What's the distinction between those? He isn't asking the candidates to invent algorithms, just to implement simple ones. The answer to the second question is "return Pi * radius * radius", isn't that just writing code?

Maybe it's just having participated in too many programming contests in college, but when I saw this:

Given that Pi can be estimated using the function [...], write a function that calculates Pi to an accuracy of 5 decimal places.

...my first inclination was:

    public double answer() {
        return 3.14159;
    }

It passes the stated requirements.

The first one (find pi to 5 decimal places from the sequence) is asking candidates to remember or invent algorithms - in fact, I'm not immediately sure how to generate the error bound there.

No, he provided the algorithm. What he's asking for is an implementation of it, which seems reasonable to me.

No, he provided the sequence. There remains the question of how you make sure that calculating n terms of it puts you within 10^-5 of the true value of pi. If he provided that as well, then yes, it should be a trivial exercise. If not, it's nontrivial (although not, I think, hugely difficult) mathematics followed by trivial programming.

The sequence is enough, you just keep going till your fractions (multiplied by 4) do not change 10^-5 any more. You do not need the actual value of pi.

As soon as 4 * 1/(2n+1) < 0.00001, then you can stop looping. The sequence is the algorithm.

This is not true for the general sequence, and I would be hesitant to give that answer without an understanding that it is true for the given sequence. It is, and I sketched the proof in reply to your sibling comment, but it takes more figuring out than I could do before coffee.

Keep the previously calculated value of pi in "oldpi" and you can do:

while round(oldpi,5) != round(pi,5)

as your loop.

You are correct, but I think underestimating the insight required for it to be "obviously" correct.

That the error must be less than the nth term does follow from 1) the fact that he says "more terms giving greater accuracy", which means the error must be monotonic, and 2) the fact that the sequence is alternating. Together, this means the two must be bouncing around the answer instead of inching toward it, and so the sum of the tail must be less than the current increment.

It won't work, however, for the general sequence (or even the general convergent sequence).

This is a worthwhile point. The non-alternating sequence, 1/(2n + 1), when summed, diverges. So if you cut it at the 100th term, or the 1000000th term, the sum of the tail will not be negligible, it will be infinite.

It's only the fact that it's alternating that makes it summable. The alternating series converges like 1/n^2.

This is the kind of thing that, if it's noted in an interview situation, marks a better than average candidate. It could also allow such a candidate to go on about problems with summing series, and really show off. (One secret to interviewing well being to make the given question into a question you know something about already.)

I think you're overestimating my intelligence. I'm neither a mathematician nor a developer.. My "insight" was simply realising that:

a) the numbers alternate between higher than pi and lower than pi

b) if you have a number between, say, 41 and 48 then the answer must be forty something and therefore start with a 4.

No more than 2 minutes insight really required! :)

Ah yes, the old "it's simple to me therefore it must be simple to everyone else" thought.

I didn't say "invent" algorithms, I said write them. If I didn't happen to have that "simple" algorithm in my head already then it would not necessarily be trivial to implement it. Especially if it's been a while since you've worked with similar equations.

Now, if the goal is to see how the person would try to work it out allowing for questions to take the place of research then I could possibly see the benefit.

I'm still fuzzy on the distinction you are trying to make between "writing algorithms" and "writing code". If someone told me they were "writing an algorithm", I'd understand it as them trying to come up with a new algorithm, either on paper or in code.

If you're given the outline for an algorithm, and asked to write code to implement it, is that writing algorithms or writing code?

This is just me, but in the two examples the first one is algorithm and the second is code. The difference being that in the first one he starts to explain the sequence he wants but apparently expects you to complete the sequence to code the function. Granted he does give you enough of the sequence that you can probably see the pattern. The second he basically tells you the equation he wants to see in code.

The first one requires an ability, even if minor, beyond just coding while the second is all about coding. I also find it interesting that he says the second version was more difficult for his applicants than the first. Maybe instead of "algorithm" it's more about pattern recognition that leads to minor math skills to then coding.

> The kind of code I write on a day-to-day basis does not require working with math equations of this type.

Normally I agree that algorithm-heavy CS problems are not representative of day-to-day software development, but this is pushing it. We're talking about a "return pi * r^2" here, in the latter example at least. The former example is a bit less realistic, but I could still see that type of logic being required occasionally.

Yes, this was my reaction, too, but after some thought, the first question is about seeing a pattern and converting it to an algorithm. I don't have a background in CS or math, so my initial reaction to a problem like that is "math! No fair!" but after some thought, it is just about patterns.

And, yes, if you've had high school geometry, you should be able to answer question #2 without much trouble.

Assuming one didn't graduate high school twenty years ago and may need some research time to recall equations that haven't been used since college.

Although, after reading the second one again I can agree that it shouldn't be too difficult to complete since he essentially tells you what to do; you just have to write the actual code. Well, assuming you don't have to write code to estimate for Pi and can just have 3.14 in there.

> I agree that one should make code very readable but comments can be very useful. Just because someone uses the tool incorrectly doesn't make it a useless tool.

Actually, I think the problem is people tend to make comments which attempt to explain the function of the code at more than a high level. This is the mistake.

Your comments should explain the "why" of your code but seldom go into the "what", because the "what" will almost certainly change. And in fact, in many cases the "what" may not be entirely determinable from a single point in time with properly uncoupled code.

You can sit here and say "Oh yeah well its the developer's problem to update the comments don't blame the comments." but the observation that "what" comments get out of date is so universal that we should probably accept it as the norm.

I can't disagree, but I still feel that the comment blames the tool instead of the misuse. If you feel explaining "what" in the comments is bad practice, then it is the fault of the developer that wrote the "what" instead of the commenting.

Based on responses to my comment on this, I'm beginning to wonder if I need to approach explaining my thinking on this in a different way.

> If you feel explaining "what" in the comments is bad practice, then it is the fault of the developer that wrote the "what" instead of the commenting.

Do you think misleading comments should stay in place then? I'm confused why this matters.

I don't see how it could be seen I was saying that. I thought I was clearly saying that misleading comments are the fault of the person who wrote them and not the thought of comments in the first place. The original controversial thought was that comments were too annoying to be useful, my reaction was that was blaming the tool instead of the person misusing the tool.

To answer your question, a misleading comment should of course be removed or changed. Again, I fail to see how I was suggesting otherwise.

I'm interested if you could solve it if you gave it some thought. The interviewer is presumably not expecting you to write it instantly and perfectly, but to reason your way through it over a few minutes.

(I will try it now.)

it can be answered in about 10 lines of C# is an unhelpful way of expressing how difficult a question is.

It took me 6 minutes to code something that I think solves this, mainly spent on thinking about what the end condition of the loop should be.

I remember very well the first time I tried a programming exercise like this. I probably spent 2 minutes writing the loop, and then I must have spent another 20 minutes wondering what I’d done wrong, until I realised that the sequence I’d been given really did converge that slowly. :-)

In the spirit of helping anyone who’s at that stage now, if you’re running on a slow machine, I suggest you try this sequence instead:

π² = 12( 1 - 1/2² + 1/3² - 1/4² + ... )

It converges much faster.

If a tool is continuosly missused... that means the tool is badly designed.

A tool, any tool must make it easy to use, hard to missues and most importantly protect you from damage when using it.

Based on that criteria, most comments make more harm than good.

One of the weaknesses of dynamic languages is that certain classes of errors aren't caught by the machine until run time. Now a think about comments, where errors are never caught by the machine.