Hacker News Reader

Comment by Jochim | Hacker News Reader

My last boss was a 10x developer. Fantastically smart guy, socially awkward but nice, really looked out for his team but an absolute nightmare to work with technically.

The majority of the team couldn't understand his code. We'd have newly hired senior developers just leave rather than deal with it.

He'd rolled his own code generator for our data model that did everything from model generation to the web controllers.

The result was that while he could pump out work quickly, what would've otherwise been a quick fix for a graduate developer now required a deep understanding of a complex system.

This had the effect of turning what would have otherwise been a team of 1-2x developers into a team of 0.2-0.5x devs with a retention problem.

View on HN

As a junior, I worked with a senior who was considered "10x" and working with him was a pain: he decided the rules didn't apply to him, and management tolerated his repeated violations of conventions instituted to make our dynamic-language codebase manageable.

Anytime he "improved" a module, no one else could maintain it as that would entail additional rule-breaking, which was verboten for mortals, so only he could maintain code he touched. Combined with the fact that he didn't add any tests: the net result was he was slowly and surely subverting the codebase into his personal, brittle domain that no one else could change. He was slowing everyone else done, but all management was looking at was his velocity at closing bugs or rolling out new features while creating tech-debt. His boastful personality was just the icing on the cake.

How is he 10x if no one understands his code? An expert at quick and dirty?

Imagine that instead of developing an app in a popular programming language, someone implements an idiosyncratic domain specific language suitable for the kind of app they need to build, and then builds the app using that. The result would work and maybe even let them be very productive churning out more features of the kind that were envisioned when the DSL was developed. If they need to extend or fix the DSL, as the original author, they can. Someone else will need to learn the DSL before they can do any work on the app.

wolf550e summed it up pretty much perfectly.

There was a great deal of thought put into it and he could extend and modify the output really quickly.

The complexity of the system basically made it so that what would otherwise have been a simple task achievable by a graduate required a deep understanding to carry out.

> He'd rolled his own code generator for our data model that did everything from model generation to the web controllers.

Heh, I've actually done that... twice. Luckily it was a team of 1 and I wouldn't expect anyone else to understand my mess. The code generation was extra ugly since I planned to get rid of it eventually to craft out smaller details. It was great at doing repetitive work in bulk. Not sure if it was actually faster but at least it was less boring doing things that way.

That sounds to me like any framework nowadays.

The difference, of course, the framework has extensive documentation.

So that was the missing ingredient.

He made a framework, but wrote no documentation. Writing documentation would have made everyone an n*x developer, for some value of n > 1.

Reply on news.ycombinator.com