3 ms·
(Full disclosure: I definitely fall under the real programmer category) I agree with about 90% of what the author said. However, I don't know that I agree th
by j_baker 17y ago
(Full disclosure: I definitely fall under the real programmer category)
I agree with about 90% of what the author said. However, I don't know that I agree that the "dudes" and "real programmers" shouldn't work on a project together. In fact, I think it's good for them to be in a state of healthy conflict.
I also would dispute that the "real programmer" would be more productive than the "dude". The real programmer would probably outperform the dude in terms of sheer amount of code written, but the dude is likely to get more done.
I think that the ultimate product would be that the dude would actually get the product done and the programmer would make a higher-quality product that won't fall apart at the slightest change.
- snitko 17y agoSince you're not the first to say this in the comments to the post, I simply must surrender and at least review the point - indeed it might be good for the project to have both people on the team. But I suppose only when both have certain qualities. What do you think those qualities are? And when does the team of 2 different types outperform the team of equal types?
- j_baker 17y agoI think that both groups always outperform each other and are always behind each other at the same time. It's that the two groups are really working towards different goals. The dude will likely want to get a product out as quickly as possible. The real programmer will want to make something that will be maintainable and good to work on in the long-term. I think this is why you will see conflict often between the two groups if you're not careful. Personally, I think that the key is understanding. Both types need to recognize that the other is working towards a valid goal and that sometimes the other's goal is more important. Otherwise, you end up with two people who wonder why they never agree on anything.