6 ms·

Brilliant post. Most of these points hit home for me. One of the things I've been honing in on recently - which you do as well - is effectiveness. Brilliant dev

by uuilly 12y ago

Brilliant post. Most of these points hit home for me. One of the things I've been honing in on recently - which you do as well - is effectiveness. Brilliant developers who don't ship aren't effective. People who don't distill a product down to just what's necessary aren't effective. You hit on this concept - and many others - in a number of spots. Thanks for sharing.

jdiomede 12y ago
True, and this is one of the harder lessons to act on. Brilliance in = brilliance out, right? At the most basic level shipping product can be the difference between fail-pivot-success and fail.
obastani 12y ago
I didn't really understand this one -- what does it mean to be a brilliant developer who doesn't ship?
- chudi 12y ago
  someone who can code complex algorithms in an environment like a topcoder contest, acm, etc. and can't finish something in the real world.
- r00fus 12y ago
  Perhaps someone who is brilliant but perfectionist and not interested or capable of doing the work to glue/shim a canonical example into a working product. Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.
- fudged71 12y ago
  This is closely related to the "Raw Technology Persona"[1] A developer who can talk you through an entire stack and why specific tradeoffs were made on specific pieces of the architecture... yet hoards code on their box without committing, works on stuff without telling other people, and claims that things are progressed much further than they actually are. It's an ego and accountability problem. Someone like this might prefer to refactor your entire stack multiple times, partly due to shiny-new-framework, and partly due to the lack of understanding that from a business perspective you often have to work with what you've got. I think it's less about perfectionism and more about inexperience with balancing business tradeoffs with technology. There's a great series in Forbes specific to CTOs undergoing this "meltdown" [2]. In it, they mention a few warning signs including: never saying no, missing deadlines, low morale, and poor estimation of timelines. [1] http://www.citoresearch.com/it-management/why-cios-and-ctos-suffer-raw-technology-persona http://www.citoresearch.com/it-management/why-cios-and-ctos-... [2] http://www.forbes.com/sites/danwoods/2013/08/26/avoiding-a-cto-meltdown-part-2-warning-signs/ http://www.forbes.com/sites/danwoods/2013/08/26/avoiding-a-c...
jroseattle 12y ago
I've always referred to this as "realized output". The brilliant engineer might have capacity for greater realized output, but there is little value in the potential. After a certain point, the output must be realized.

by uuilly 12y ago

jdiomede 12y ago

True, and this is one of the harder lessons to act on. Brilliance in = brilliance out, right? At the most basic level shipping product can be the difference between fail-pivot-success and fail.

obastani 12y ago

I didn't really understand this one -- what does it mean to be a brilliant developer who doesn't ship?

chudi 12y ago
someone who can code complex algorithms in an environment like a topcoder contest, acm, etc. and can't finish something in the real world.
r00fus 12y ago
Perhaps someone who is brilliant but perfectionist and not interested or capable of doing the work to glue/shim a canonical example into a working product. Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.
fudged71 12y ago
This is closely related to the "Raw Technology Persona"[1] A developer who can talk you through an entire stack and why specific tradeoffs were made on specific pieces of the architecture... yet hoards code on their box without committing, works on stuff without telling other people, and claims that things are progressed much further than they actually are. It's an ego and accountability problem. Someone like this might prefer to refactor your entire stack multiple times, partly due to shiny-new-framework, and partly due to the lack of understanding that from a business perspective you often have to work with what you've got. I think it's less about perfectionism and more about inexperience with balancing business tradeoffs with technology. There's a great series in Forbes specific to CTOs undergoing this "meltdown" [2]. In it, they mention a few warning signs including: never saying no, missing deadlines, low morale, and poor estimation of timelines. [1] http://www.citoresearch.com/it-management/why-cios-and-ctos-suffer-raw-technology-persona http://www.citoresearch.com/it-management/why-cios-and-ctos-... [2] http://www.forbes.com/sites/danwoods/2013/08/26/avoiding-a-cto-meltdown-part-2-warning-signs/ http://www.forbes.com/sites/danwoods/2013/08/26/avoiding-a-c...

jroseattle 12y ago

I've always referred to this as "realized output". The brilliant engineer might have capacity for greater realized output, but there is little value in the potential. After a certain point, the output must be realized.