Comment by hasenj | Hacker News Reader

Comment by hasenj | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

Rodrigo is a caricature, an exaggeration. Real Rodrigos only exhibit one or two of the mentioned employee defects.

Gabriella, however, is an understatement. Not only does her work require QA to fix up, etc, but her backstabbing tongue causes the productivity of the whole team to suffer, and s/he's quick to blame the Rodrigos.

Not only that but her fuck ups give management the leverage necessary to put the process in place to prevent Gabriella fucking up the whole codebase which stifles just about anyone from getting anything done.

Suddenly you're not allowed to use the ternary operator because Gabriella can't tell the fucking difference between a statement and an expression. Suddenly you have to use a massive DI framework and fucking checked exceptions because she can't understand what a lambda does, or that a closure doesn't change the value of variables outside the closure.

Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.

I really wish the OP reversed the genders of the examples because by sheer gender imbalance in the tech industry there are a lot more male Gabriellas.

Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.

This is a little over-simplistic, IMO. There's more to correctness and good code than "it didn't break the build." I've been there and got the T-shirt from an organization with that mindset and their code, five or more years after it's written, was terrifying in a lot of ways, because hey--none of it broke the build. I get that you probably have had run-ins with bad process, but that doesn't make all process bad.

I'm a big fan of Gerrit, personally; it encourages multiple sets of eyes on the code and I really like the "gatekeeper" approach to master. If I can't use Gerrit (and there are good reasons for not using it, often related just to development team size--Gerrit doesn't seem worthwhile for under, say, 20 devs), my personal preference is a riff off of git-flow; developers only push to develop-staging and CI constantly pulls changes from develop, builds, runs tests, and pushes to develop. Nobody other than the CI user (which anyone can log in as, but unless something's broken, you never would) can push to develop. This process (scary word!) allows us to say with authority "the build will never be broken when you pull from develop," and to me that has a lot of value--more and more as you add developers.

Reply on news.ycombinator.com