3 ms·

The best is have both types on the team. You give Coder 1 projects and in a week they have a working version that starts generating revenue, albeit with cut co

The best is have both types on the team. You give Coder 1 projects and in a week they have a working version that starts generating revenue, albeit with cut corners and limited scope. After it bakes for a month or two and we are sure we want to keep this thing, you hand it to Coder 2 to improve quality, integrate with the rest of the stack, etc. If it was a bad idea you throw it away and C2 never needs to support it. C1’s fast velocity is largely a product of the high quality codebase curated by C2. C2 is always spending their time on known-profitable projects, thanks to C1. We also make sure C1 and C2 are both involved in deciding what we build and in deciding architecture. Usually C1 is a more business-motivated type who is excited about the domain. C2 is usually more of a technical purist who is excited about building great software. On a team with good leadership this is a very powerful combination, everyone is valuable.

valeness 5y ago
This is weird to me in a thread about requirements gathering. The OP isn't making the case weighing good, but slow, programmers and bad, but fast, programmers. They're specifically calling out C2 moving slowly to gather requirements and talk with the product/design team. Which is very likely NOT a "technical purist" type, since I doubt the technical purists are the kind to give two shits about the domain (I'm one of them, even though I realize caring about the domain is now my job as Lead, doesn't mean I have to like it). If C1 delivers quickly on bad requirements, there is no guarantee that product will make revenue. Ask any startup founder who started building a product before doing market research and validation. I think when we add the archetypes of "fast but sloppy" and "slow but clean", we end up with more permutations than C1 and C2 since the matrix looks more like: [ Business Oriented, Technology Oriented Quick/Sloppy , Slow/Clean ]
dalbasal 5y ago
I kind of agree, but for different reasons. C1 isn't for fast-but-low-quality. It's for instances where you have a detailed spec. Maybe there isn't much ambiguity. Maybe there is, but you're working with an iterative process or something where building the wrong thing right is ok. In my experience though, there's a never enough C1 type of work to go around. C2 is always the bottleneck. Requirements, specs, stories or whatnot do not reliably make good sense at the point where someone is actually making thee thing. So to OP's question, I'd take the C2. Not because you don't need C1s, because you probably already have enough.

valeness 5y ago

This is weird to me in a thread about requirements gathering. The OP isn't making the case weighing good, but slow, programmers and bad, but fast, programmers. They're specifically calling out C2 moving slowly to gather requirements and talk with the product/design team. Which is very likely NOT a "technical purist" type, since I doubt the technical purists are the kind to give two shits about the domain (I'm one of them, even though I realize caring about the domain is now my job as Lead, doesn't mean I have to like it). If C1 delivers quickly on bad requirements, there is no guarantee that product will make revenue. Ask any startup founder who started building a product before doing market research and validation. I think when we add the archetypes of "fast but sloppy" and "slow but clean", we end up with more permutations than C1 and C2 since the matrix looks more like: [ Business Oriented, Technology Oriented Quick/Sloppy , Slow/Clean ]

dalbasal 5y ago

I kind of agree, but for different reasons. C1 isn't for fast-but-low-quality. It's for instances where you have a detailed spec. Maybe there isn't much ambiguity. Maybe there is, but you're working with an iterative process or something where building the wrong thing right is ok. In my experience though, there's a never enough C1 type of work to go around. C2 is always the bottleneck. Requirements, specs, stories or whatnot do not reliably make good sense at the point where someone is actually making thee thing. So to OP's question, I'd take the C2. Not because you don't need C1s, because you probably already have enough.