4 ms·

The most difficult thing is a culture insisting on passing the buck as not their responsibility. I find there are 2 extremes of developers: 1) Ones that deve

The most difficult thing is a culture insisting on passing the buck as not their responsibility. I find there are 2 extremes of developers: 1) Ones that develop very fast (and does not think about what is being developed, sometimes blindly). There is no reward to speak up to ambiguities in requirements, or even mistakes. So the mindset here is "can be fixed", "QA" will find, etc. 2) Ones that develop much slower, overly reviewing requirements, use cases, etc., and spending more time with product / designer throughout development. ________ For those who are team leads, managers, hiring managers, which of 2 above would you prefer? ________ EDIT: I am not a super star coder (more a "jack of all trades"), but I have very good intuition on product so many times I wonder if there is a better job field for me. I would be interested to hear ideas along this path.

vsareto 5y ago
> So the mindset here is "can be fixed", "QA" will find, etc. There's an alternative mindset here as well: let's get something in front of the users because they don't know what they want (because they gave us vague requirements), and this lets us iterate more accurately. This is a strategy if you have developers with certain freedoms like talking to users directly vs. having product owners to distill requirements, and more or less running the entire development lifecycle.
- guelo 5y ago
  IME the "get it done" devs are not interested in following up with customers or looking at metrics to see how things are performing. They're on to the next task that they think will get them the promotion.
  - freeqaz 5y ago
    This definitely depends. I'm at a startup and I'm close enough to the business that having features DOES matter, so releasing them has material value. There are metrics to follow, but there are also individual customers asking for stuff too. I think it's bigger companies where this mentality starts to become pervasive with promos.
heurisko 5y ago
> For those who are team leads, managers, hiring managers, which of 2 above would you prefer? A blend of both can well work in a team.
tasubotadas 5y ago
1) everyday - fast iterative process beats everything
- postalrat 5y ago
  Iterating twords what?
caffeine 5y ago
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.
rramadass 5y ago
You need both. I used to work in a place where (1) was called as "Customer Engineering" and (2) as "Product/Standard Engineering" (i was part of this group). The former allows you to hook in the customer and keep him engaged with quick feature deliverables in separate code branches some of which are then rolled into the "master" branch (with due diligence like refactoring, making it robust and more general etc.) after due consultations with Marketing/Sales. I was a skeptic initially, thinking (1) would be producing crap code which would need extensive rewrite but that didn't happen in reality. They were experienced developers themselves (this is the key for (1) ) and so the code was mostly okay and needed little tweaking. Everything worked surprisingly well. I believe every Company needs to have these two groups in Engineering.

vsareto 5y ago

> So the mindset here is "can be fixed", "QA" will find, etc. There's an alternative mindset here as well: let's get something in front of the users because they don't know what they want (because they gave us vague requirements), and this lets us iterate more accurately. This is a strategy if you have developers with certain freedoms like talking to users directly vs. having product owners to distill requirements, and more or less running the entire development lifecycle.

guelo 5y ago
IME the "get it done" devs are not interested in following up with customers or looking at metrics to see how things are performing. They're on to the next task that they think will get them the promotion.
- freeqaz 5y ago
  This definitely depends. I'm at a startup and I'm close enough to the business that having features DOES matter, so releasing them has material value. There are metrics to follow, but there are also individual customers asking for stuff too. I think it's bigger companies where this mentality starts to become pervasive with promos.

heurisko 5y ago

> For those who are team leads, managers, hiring managers, which of 2 above would you prefer? A blend of both can well work in a team.

tasubotadas 5y ago

1) everyday - fast iterative process beats everything

postalrat 5y ago
Iterating twords what?

caffeine 5y ago

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.

rramadass 5y ago

You need both. I used to work in a place where (1) was called as "Customer Engineering" and (2) as "Product/Standard Engineering" (i was part of this group). The former allows you to hook in the customer and keep him engaged with quick feature deliverables in separate code branches some of which are then rolled into the "master" branch (with due diligence like refactoring, making it robust and more general etc.) after due consultations with Marketing/Sales. I was a skeptic initially, thinking (1) would be producing crap code which would need extensive rewrite but that didn't happen in reality. They were experienced developers themselves (this is the key for (1) ) and so the code was mostly okay and needed little tweaking. Everything worked surprisingly well. I believe every Company needs to have these two groups in Engineering.