3 ms·

I think it's much more domain-expert vs non-domain-expert rather than programmer vs non-programmer. I've regularly seen very experienced developers make exactl

I think it's much more domain-expert vs non-domain-expert rather than programmer vs non-programmer. I've regularly seen very experienced developers make exactly the same sort of mistakes when talking to people outside of their field (Sales, Design, etc.) because they miss things like: * Sales is about building stories and relationships - it's not just listing features and meeting people. * Design is about understanding the user, iterating, testing and experimentation - it's not just making things pretty. I wish technical folk were naturally better at this sort of thing - but they (and I :-) keep making similar sorts of mistakes. (It's also amusing to see the "it's not like building a bridge" analogy turn up. Go talk to some engineers, architects and builders - and find out how many of those projects ended up matching the original time and cost estimates :-)

DanBC 15y ago
> (It's also amusing to see the "it's not like building a bridge" analogy turn up. Go talk to some engineers, architects and builders - and find out how many of those projects ended up matching the original time and cost estimates :-) That's an important point. I used to work in sub-contract electronic engineering. We had a lot of information about how long it took to do things, and how much items cost. In theory, estimating the cost of projects should have been straightforward. And then you add 15% for wiggle room. And still it's hard to keep things going out on time and on budget.