A tale of POCs, tech debt, and working with rockstars who moved too fast
Meeting the 10X Dev
In my web development career, I've so far worked with three quote and quote "10X" (or "cracked") developers across three different projects.
They are amazing at work, complete more tickets per sprint than the rest of the team combined, work 12+ hours a day, skip weekends, rarely take any leave, and most importantly, they can get you a POC in less than a week or two (a bond they might be cursed with forever).
POC Hero
A 10X developer’s relationship with POCs often begins with an ambitious feature request.
The lead proposes that we first make a POC, do some feasibility analysis, and run user acceptance tests. "But we don't have much time", says the product manager. They look at the 10X developer and ask, "We can do this in two weeks, right?".
The 10X developer grinds for two weeks and delivers a prototype that's “good enough.” It goes into testing and passes with flying colours. The prototype is merged into the main project. Success.
A new feature request comes in. The POC is assigned to the 10X developer. This time, the prototype didn't pass testing, and the feature is marked not feasible, saving us months of development time. Success again.
Over time (sprint after sprint), the 10X developer gets assigned more and more POC work. Eventually, they stop doing any bug fixing, enhancements, upgrades, or maintenance. All they do now is create POCs.
Every big and small feature now needs a POC, and who handles that? Correct: the 10X developer.
From Hero to Bottleneck
As more and more POC work gets assigned, they get less and less time to actually work on it.
The prototype quality drops from good enough to barely functional, and they start writing clever but garbage code that's hard to understand and a nightmare to maintain. Once the prototype is merged, they don't have time to continue working on that feature, as they have five more POCs to work on. That work is assigned to someone else in the team (yes, sometimes it's you).
You realise the prototype that was “supposedly” built to handle edge cases barely works even on the happy path. Product believes the prototype accounts for the future specs (developed by the 10X developer), but you only know that it barely covers the current ones.
They grow out of touch with actual, real-world project work. They now live in the POC world, where everything is a green field project. Their system never breaks; it's always someone else's faulty code. Anyways, they don't have time to fix it. They’ve already got ten more POCs to work on. And now it’s your responsibility to fix it.
They start shipping more features in a quarter than the rest of the team combined in a year. Meanwhile, you get less and less time to stabilise the prototype and get it into production. The 10X developer assures you it's already “production-ready.” You just need to iron out the cloth, the only issue being, the cloth has multiple holes.
Team Fatigue and Burnout
Eventually, everyone on the team starts resenting having to pick up the pieces from the 10X developer's prototypes. No one wants to work with them anymore.
What was once an outlier becomes the baseline. People start burning out, start leaving the project, and with each departure, the project slips from bearable to broken.
What was once a thriving codebase and a colourful team becomes a barren, forgotten land.
Top comments (0)