4 ms·
You're funny in the "Enterprise developers aren't famously top-notch developers in general." and "But I'm admittedly a few sigmas above average, so my experi
by aprdm 10y ago
You're funny in the
"Enterprise developers aren't famously top-notch developers in general."
and
"But I'm admittedly a few sigmas above average, so my experience is probably not typical."
I strongly suggest you get off your high horse :)
I also suggest that you read some of the Kent Beck books! Mainly on TDD, he also wrote the JUnit for Java. He considers himself as an average developer who follows good processes... perhaps you're above him as well.
- SomeCallMeTim 10y ago>I strongly suggest you get off your high horse :) :P My "a few sigmas above average" comment was to just point out that I'm not typical. It's literally true, though. I really am that good. At least when I'm not writing comments on HN. ;) Relative to Kent Beck: I've never met him, much less worked with him. But being famous doesn't automatically make you a top 0.1% developer. A great manager and process person? Sure, I'd buy that, based on his books. But based on the relative skill of developers who I've encountered through my career, I'm at least top 1%, and maybe 0.1%. I've met hundreds of developers, and only a very few were in the same league. I did read Extreme Programming when it first came out. I actually feel that many of the practices in XP, including test-first and pair programming, are actually far more important for average to below-average developers. I think Kent Beck himself said that XP was best for broad-but-shallow problems (things like accounting software with a million simple rules). Broad-but-shallow just doesn't require the same strength of programmer to conquer -- though it does require good process, especially if your team size (and breadth) is large, which is Beck's strength.