3 ms·

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 do

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.

Bamafan 14y ago
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. Sadly, this can be a very important component to your success as a developer (or anything else) in corporate America.
loup-vaillant 14y ago
There's what the OP wanted to describe, and what he actually described. While your criticisms are valid (Rodriguo and Gabriella as described by the OP are indeed inconsistent exaggerations), this post does strike a chord. For instance, I do see at work some people who care more about short term "done" than the quality of their code. Such code can often be shorten by 30 to 50% merely by applying local correctness-preserving transformations (my guess is, such code is written by shotgun debugging, then is left as-is when it "works", instead of being reviewed one last time for clarity). I don't like this. But maybe that's because I don't understand that in this case, short term "done" really is more important: like we have to show "something" soon, or else there won't be any long term to speak of. We can understand what makes good code. We can understand what people want to hear. We may even be good at both. Caring about both is harder. So when they're at odds, I think most people will bend one to meet the demands of the other. That's probably the essence of the Rodriguo & Gabriella trade off. Hmm, I think we could go even more meta: hard facts vs politics. The best decision to make is often not the best decision to call for.

Bamafan 14y ago

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. Sadly, this can be a very important component to your success as a developer (or anything else) in corporate America.

loup-vaillant 14y ago

There's what the OP wanted to describe, and what he actually described. While your criticisms are valid (Rodriguo and Gabriella as described by the OP are indeed inconsistent exaggerations), this post does strike a chord. For instance, I do see at work some people who care more about short term "done" than the quality of their code. Such code can often be shorten by 30 to 50% merely by applying local correctness-preserving transformations (my guess is, such code is written by shotgun debugging, then is left as-is when it "works", instead of being reviewed one last time for clarity). I don't like this. But maybe that's because I don't understand that in this case, short term "done" really is more important: like we have to show "something" soon, or else there won't be any long term to speak of. We can understand what makes good code. We can understand what people want to hear. We may even be good at both. Caring about both is harder. So when they're at odds, I think most people will bend one to meet the demands of the other. That's probably the essence of the Rodriguo & Gabriella trade off. Hmm, I think we could go even more meta: hard facts vs politics. The best decision to make is often not the best decision to call for.