And no, I am not exaggerating the time needed to fix. The weekend bender, maybe. Average case is started on a weekend and in production two weeks later. The code did not improve over those two weeks.

I’ve dealt with this half a dozen times (maybe more) in my career. Enough that I want to struggle the next “rockstar” that shows up in Slack. They generate problems and support issues faster than a room full of monkeys on typewriters.

I get even more cranky when they decide to use the opportunity to learn Go or Haskell, a programming language no one else on the team knows. And of course they fuck it up because they haven’t used a statically-compiled, strongly-typed (or functional) language before.

I’m generally a careful programmer, but I can definitely write fast and cut corners if necessary. The difference is I know what corners to cut and how to document them.

It might take me 3 weeks instead of 2, but the reduced support cost is far worth the extra week of development.

No, as far as the star dev goes, he's done with the project and has moved onto the next one. He's far to valuable to the company to be fixing bugs. The buggy code is already in production because he promised it was done. The fact that others have to fix the problems implies that the star dev is done.

I wrote about a specific problem, not a generalization that all fast phased development is bad. Also, nothing in my story implies that I'm justifying overanalysing.

I've seen cases that if code is not ready by Monday then the company goes bust. The code is shipped riddled with bugs. Totally justified in that case.

But more often than not "people are done after their code hits production".