While I agree with some of the premises here, I personally disagree that comments are even mostly a problem (a code smell). IMO they’re just as often bad as code is. A developer in a rush, or simply not taking enough care in their work, can produce both bad code and bad comments.
Perhaps someone who is trying to take care can do more harm in the comments area, when they should be perhaps looking at writing self documenting code, but in my experience they usually go hand in hand.
I use quite a lot of comments in my code and I wouldn’t regard it as code smell or even messy. I often use comments to logically separate more complex sections of functionality.. or discussing how it works and why it’s necessary to exist in the first place. Code can’t always tell you why it’s there..
I also use docblocks in some libraries, even though types are available, as the published package benefits from having an API document published alongside it. The comments there facilitate its construction.
I know this article wasn’t bashing every use of comments in code but I feel like it didn’t account for all the positive uses of them either. Teaching developers that a language feature is just mostly bad is irresponsible - we should be encouraging good comment use alongside clear code.
I personally refuse live coding sessions during interviews, including whiteboard programming. If they require this during an interview the company’s not for me.
Don’t mind code challenges where I have a timeframe and can submit. It’s not how you code normally so why should it be how you’re hired?