4 ms·

While I understand what the author was trying to say, the argument is flawed in several ways. First of all, as several people have already pointed out in their

While I understand what the author was trying to say, the argument is flawed in several ways. First of all, as several people have already pointed out in their comments, not all companies are the same. Some companies place higher value on hard skills, some on soft skills. Most programmers will find their place somewhere. "Rodrigos" will fit better into a software/tech company, while "Gabriellas" will fit better into a company where software is just a necessity (e.g. a credit bureau). Second, the whole "Rodrigo and Gabriella" example is not only contrived to support a flawed argument, it also features several inconsistencies that it conveniently sweeps under the carpet. For example, Gabriella is said to be "able to explain complex technical issues quite clearly to clients", yet "she doesn't really grasp the concept of writing code that performs well". The concept of writing code that performs well is a lot simple than "complex technical issues" you might need to explain to clients. Similarly, Rodrigo has risen to fame in open source community despite the fact that he is so inept at communication and teamwork that "you can't get a clear thought out of him without rambling incoherence surrounding it." Third, the author states that "a manager would rather work with Gabriella" because "managers are the ones who would have to deal with missed deadlines". There's an assumption here that the fact that Gabriella "introduces bugs that QA has to spend their time on" would not lead to missed deadlines. I can attest, based on lots of personal experience, that in the companies that prefer to hire mostly "Gabriellas" the whole concept of success has been redefined so that nobody will mind the fact that the projects consistently miss deadlines and exceed the budget. Fourth -- and I guess this is the one that hit my nerve -- the whole thing is presented as a matter of being able to impress managers "to get jobs and promotions and raises and pats on the back". Believe it or not, but some of us actually care more about producing software that does what the users/clients/customers need in the best possible way. Some of us are motivated by professional pride. We expect to get "promotions and raises and pats on the back" based on our merits, i.e. not because we're focused on impressing managers, but rather because we expect managers to be impressed by quality work. Look, if you're slightly bitter about seeing "programmers who are great employees but not great coders move to the top", I can understand that. If you feel the need to rationalize about it, I can understand that, too. The problem is that you are offering your rationalizations as advice, without any regard for the effect it might have on shaping new generations of coders, such as teaching them it's okay to be a mediocre suck-up.

hasenj 14y ago
Alright, interesting, but I want to counter your points. 1. I've mentioned in another reply, but Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial. So, when the manager listens to her explanation, he understands what she says. Rodrigo, on the other hand, has a deep understanding of the technical issues. When he tries to explain them, he involves the listener with some details that are necessary to understand before understanding what the issues are. Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager". 2. When you work on an open source projects, you can always push the deadline to next week. I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines. I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs.
- CodeMage 14y ago
  Alright, interesting, but I want to counter your points. Either I didn't communicate my points correctly or you're not really countering my points. Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager". The point is not about Rodrigo's (in)ability to explain technical issues to less technical people. The point is that Gabriella is supposed to be able to do so well, yet unable to grasp the concept of performance. To quote the author, Gabriella's attitude is that "if it works, it works!" I was pointing out that this is rather inconsistent with the ability to understand complex technical issues well enough to be able to explain them to non-technical people. Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial. Unless I'm totally misinterpreting you, you're saying that Gabriella isn't actually explaining complex technical issues well, but instead misrepresenting them as simple issues. While that might counter one part of my second point, it really does underline my final conclusion about the message the author tries to convey. I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines. Again, you seem to be countering a point I wasn't making. My point wasn't about deadlines, but about communication and collaboration. The phrase "you can't get a clear thought out of him without rambling incoherence surrounding it" describes a kind of person that can't communicate well enough even with their peers. Maybe my understanding of open source is naive, but I somehow find it difficult to believe that they can thrive when their "core contributors" (as the author claims Rodrigo to be) have such a low signal-to-noise ratio. I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs. Yes, I've seen quite a few of those, too. What invariably happens is that the "client" (i.e. whoever the software is for) either ends up "paying" extra for those bugs to be fixed or living with crappy product if they can't "pay". And when I say "pay", it's not necessarily in money -- it could be in time before they can use the software or reap expected benefits from it. Like I stated, wherever this is acceptable behavior, it's because the concept of successful project is redefined to accept this. The reality is that you didn't really hit the deadline, you just strongarmed everyone into accepting the fact that you cheated by redefining rules.

hasenj 14y ago

Alright, interesting, but I want to counter your points. 1. I've mentioned in another reply, but Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial. So, when the manager listens to her explanation, he understands what she says. Rodrigo, on the other hand, has a deep understanding of the technical issues. When he tries to explain them, he involves the listener with some details that are necessary to understand before understanding what the issues are. Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager". 2. When you work on an open source projects, you can always push the deadline to next week. I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines. I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs.

CodeMage 14y ago
Alright, interesting, but I want to counter your points. Either I didn't communicate my points correctly or you're not really countering my points. Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager". The point is not about Rodrigo's (in)ability to explain technical issues to less technical people. The point is that Gabriella is supposed to be able to do so well, yet unable to grasp the concept of performance. To quote the author, Gabriella's attitude is that "if it works, it works!" I was pointing out that this is rather inconsistent with the ability to understand complex technical issues well enough to be able to explain them to non-technical people. Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial. Unless I'm totally misinterpreting you, you're saying that Gabriella isn't actually explaining complex technical issues well, but instead misrepresenting them as simple issues. While that might counter one part of my second point, it really does underline my final conclusion about the message the author tries to convey. I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines. Again, you seem to be countering a point I wasn't making. My point wasn't about deadlines, but about communication and collaboration. The phrase "you can't get a clear thought out of him without rambling incoherence surrounding it" describes a kind of person that can't communicate well enough even with their peers. Maybe my understanding of open source is naive, but I somehow find it difficult to believe that they can thrive when their "core contributors" (as the author claims Rodrigo to be) have such a low signal-to-noise ratio. I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs. Yes, I've seen quite a few of those, too. What invariably happens is that the "client" (i.e. whoever the software is for) either ends up "paying" extra for those bugs to be fixed or living with crappy product if they can't "pay". And when I say "pay", it's not necessarily in money -- it could be in time before they can use the software or reap expected benefits from it. Like I stated, wherever this is acceptable behavior, it's because the concept of successful project is redefined to accept this. The reality is that you didn't really hit the deadline, you just strongarmed everyone into accepting the fact that you cheated by redefining rules.