[kayodelycaon]

When it takes 3-6 months to unfuck someone’s caffeine-fueled, no-sleep weekend bender that got squeezed in under the radar, the value that person is adding to the team and the company is quite questionable.

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.

[BlargMcLarg]

Read my other comment, as your story is a far-too-often-used extreme used by the other extreme party to justify bizarre situations. For every one of those anecdotes is another anecdote of a team of seniors/architects pissing away half the development time only to come with an inadequate solution at the end of it. Guess what, it leads to the same 3-6 months of 'unfucking' with said feature now having to be juggled in prod, where it could have taken half a day of user-testing in a safe environment. When both extremes lead to the same problem, the anecdotes of 'how going fast destroyed my mental sanity' are not an excuse to endlessly bash the other extreme.

The key problem is always the same. The business wants to move as fast as possible, and developers are extremely concentrated in either the overly defensive "let us discuss ad nauseam" camp or the willing/passive "let's develop something and deliver it" camp. I don't agree with either, but frankly, I've had far more trouble convincing the former of their problem (analysis paralysis and wasting time) than the latter of theirs, and the former group is extremely convinced they have the high ground over the latter.

>I’ve dealt with this half a dozen times (maybe more) in my career.

And I've dealt with 'seniors' willingly sitting in meetings not achieving anything and pushing silly refactors more than half a dozen times only to run into performance issues, bugs and terrible deployments. User complaints don't lie, the grass ain't greener on the other side.