Can confirm. This is literally what happened in a codebase in the past:

  // OLD CODE WITH COMMENTS:
  // check ...
  4 lines of code
  // drop ...
  4 lines of code
  // read ...
  4 lines of code
  // do xxx ...
  4 lines of code

In total, that method was like 16 lines of code, with some short commented sections. And the sections used variables from before.

Situation: New coder comes in, sees comments. Says "comments are bad, they get out of date, yadda yadda". So proceeds to change comment names into method names:

  // PROPOSED: COMMENTS => METHODS
  check()
  drop()
  read()
  doxxx()

What coder forgot was the variables and context. As said before, the total was 16 lines of code with simple variables used between it. Not a big deal. But now when it has to be split into functions, it became like this:

  // ACTUAL 1: COMMENTS => METHODS
  a, b, c = check()
  d, e = drop(b)
  f, g = read(a, d)
  i = doxxx(e, g)

And this was a language that didn't support multiple return types. So the code was actually:

  // ACTUAL 2: COMMENTS => METHODS
  class X { a, b, c}
  class Y { d, e }
  class Z { f, g }
  X x = check()
  Y y = drop(x.b)
  Z z = read(x.a, y.d)
  i = doxxx(y.e, z.g)

So now coder added 3 more classes, with more lines of boilerplate. Then the coder decided, to manage this problem better. So they created some more interfaces and did some DI. The result was around a 250 line PR, which I cannot ping here anymore. When we pointed out the same logic was now 250 lines, the answers were: "It's inherent complexity which we didn't know how to manage. His/her solution scales better, and he/she has shown us the way".

All for what? Because comments were considered a smell. Go figure.

I guess this is why this other HN post trended – "Please do not simplify this code": https://news.ycombinator.com/item?id=18772873