[RalfWausE]

Oh, i know him... it's me!

I do "computer stuff" as my profession for about 20 years and always for rather small companies. I do everything from wiring a network, any level of supported, programming and administrative stuff... oh yeah, and in my current job I sometimes drive a forklift in the warehouse.

I work now for about 10 years for the same company and have built significant parts of their software ecosystem, and in my professional opinion: Its a Rube Goldberg machine fixed and extended with duct-tape, hotglue and tons of wishful thinking. Nothing, absolutely nothing in the system I had to build was carefully planned, implemented or tested. Most new feature requests were handed in by an stressed out boss on a Friday afternoon telling me that we need feature X / solution for problem Y / bugfix Z ABSOLUTELY URGENTLY because something went terribly wrong. Its not uncommon that this visits were the result of some prior hotfix backfiring.

And I build it. And it works.

I have often told my boss that it would be best to drag the whole system behind the warehouse and shoot it to relief it of its misery... but, well, it works...

Perhaps I should work on having this 'Pete skill' of leaving ship for the raise and promotion thing ;-)

[pyrale]

The key issue of Petes is when they don't stay and make sure management knows that it's a prototype that needs more love.

They milk the credit and move on, leaving the next engineer explain to management that what they have is not what they believe they have.

[motorest]

> They milk the credit and move on, leaving the next engineer explain to management that what they have is not what they believe they have.

I worked with a Pete. He was brilliant. He wrote all proof of concepts that drove major flagship products. He showcased them. He proved the concept worked. He delivered with lightning fast time-to-market.

He also made it abundantly clear to management that his proof of concepts required major architectural overhauls to make them maintainable. That was the tradeoff. This was clear from the start.

Managers didn't listened. They could not or would not understand why you'd need to rearchitect a service that was working, in spite of the very creator of said service saying it. They believed, or wanted to believe, that the project was done and over.

The problem aren't the Petes. The concept of technical debt is either foreign or tabu for managers. They have to sell the higher-ups the need to spend more resources fixing something that works. It's bad for careers.

[torginus]

The weird thing is management knows who the Pete-s are (either directly, or they know a guy who knows the guy), and once the awards ceremonies are over, and things start breaking in prod, you can bet you ass Pete's Teams will start chiming.

[bombela]

I don't think you are the same Pete.

People like you acknowledge and understand the engineering trade-offs. Which you might smirk at, but is true nonetheless. If there is only one example of you not being op's Pete is that you tell your boss about the reality of the situation.

The OP's Pete I have met many. It is exactly as described.

[motorest]

> The OP's Pete I have met many. It is exactly as described.

I don't think they are different, or at least that far apart.

I have a couple of Pete stories of my own. The last one I had a manager wanting a year's worth of work released in 3 months to meet nice-to-have deadlines. I explained that it was impossible to meet that requirement, but I offered an alternative solution that delivered a MVP in a couple of months but we would still need a year of intensive manual intervention alongside development work to get the system running. I repeated over and over the technical debt. He accepted the tradeoff.

After I delivered the MVP, that manager completely axed any follow-up development work and replaced it with four more ambitious projects. Now we have engineers wasting a few days of work per month doing manual maintenance tasks on top of project work because actually finishing the MVP is no longer in the roadmap.

Here's the kicker: what would happen if I left the company? Would I be singled out as the scapegoat for the MVP being a mess that's missing critical features? Would I be blamed for the project not working as presented by the manager to higher ups? Would I be vilified by the engineers tasked with doing grunt work for something that could be easily automated if a team worked on it for a few months?