Alternatively work at a company that prioritizes quality and clarity of thought over deadlines and interruptions. Most of management's problems are management's creation. If you want to create quality products don't embrace their philosophy. Hiring people like Gabriella is how the company goes out of business as faster and more nimble competitors roll out updates to customers while managerial companies pile hack on top of hack.

All the deadlines may have been hit but nothing of value was produced. It's the classic efficiency vs. effectiveness trade off.

If Rodrigo wants to hit deadlines all he needs to do is increase his estimates. It's usually easier to teach someone how to game the managerial system than it is to teach someone to code.

This is a classic case of the CSL dynamic as expressed in the Gervais principle, the issue is that Rodrigo is a loser, he know's he's not being fully compensated but his coding skill makes up for having to participate in the bureaucracy, hence he doesn't care because he isn't clueless and thus will never be promoted to middle management. He's making the best of a bad situation.

I wonder which is easier: training Rodrigo to communicate well, or training Gabriella to program? I suspect it's the former, though you might first have to convince him that communication is important at all. Being able to train in both directions is important when your company gets big enough.

I suspect that companies which are product-focused can probably get away with (a little) less concern for deadlines, as they can more easily push back a release if they want to focus on quality. I've often worked in service or client-oriented settings, and the temptation of hiring the Gabriella is real: she might not be the best programmer, but at least she actually answers your damn emails when the client is angry! It's not a recipe for long-term quality, but occasionally short-term is really damned important. :)

>> she takes 30 lines to write what should be written in 15 or 20, she introduces bugs that QA has to spend their time on, and she doesn't really grasp the concept of writing code that performs well

>> she is a great communicator and is able to explain complex technical issues quite clearly to clients

I haven't yet met a developer/programmer who writes a code like the one described in the first statement being a great communicator as described in the second statement. Most of them who could articulate complex technical issues seem to be great programmers too. Any counter examples?

I'm a manager who focuses on good communication. I strive to hire and retain Rodrigos. It's extremely difficult to attract talent of that caliber (writing compilers...). My experience has been that when I do build my pure-Rodrigo team that my boss (usually the CEO) just can't deal with employees of that caliber. I end up spending 90% of my time executive handholding because they continuously try to force the team around their (usually primitive) objectives instead of letting the geniuses drive progress forward.

Rodrigo will get his work done 10X faster than another dev, regardless of the artificial deadlines.

I shield my team as much as I can from the bullshit from above but in the end I usually walk because if you're unwilling to take advantage of the resources in your own company then there really is no hope. Executive/management ego is THE problem.

In the future there will be Rodrigos, scripts and the unemployed.

Okay, now a real example:

Gabriella is only able to explain the technical stuff because Rodrigo explained it to her first. Her summary is the watered down version, so more people understand her. She doesn't quite get the details anyway.

Mostly, Gabriella gets her job done because Rodrigo helps her at every turn. Without him, she'd be lost. He has to spoon feed the solution to her often. He leaves out the last step occasionally to see if she can figure it out on her own. He enjoys this game so both win. Gabriella feels like she's actually contributing something. All this happens while Rodrigo is getting his own job done. The team is happy.

Rodrigo gets more work done since he tries to avoid distractions. He understands that the most important 'thing' is actually what he's currently working on and not what project managers have coming down the line. Gabriella is focused on what is coming down the line so that she can identify and get assigned the easy work first. Rodrigo gets assigned the hard stuff.

Gabriella keeps her job by appearing busy through socializing while Rodrigo keeps his by keeping the ship afloat.

At standups Gabriella can talk half an hour about a single line code change while Rodrigue provides a single brief statement on an entire system he's currently working on.

Gabriella's checkins:

+5 -2

+1 -0

Rodrigo's checkins:

+78 -45

+22 -10

+55 -0

+85 -20

Rodrigo makes 1.6 times Gabriella. Gabriella leaves early, Rodrigo puts in a full day.

Becoming a skilled developer is hard, therefore many of us seem to think that when a business hires us to develop software they're hiring us for our hard-earned skills.

However, businesses really hire us because they want to achieve Objective X, which requires some software in order to get there. The overwhelming majority of of businesses frankly don't care about the code, and are concerned only about whether it gets them closer to Objective X.

Though Rodrigo is a better coder, if Gabriella is more capable of getting the business to Objective X because she's able to better distill business goals into actual solutions, she's exponentially more valuable than Rodrigo.

I've hired a lot of people - quite a few of them were incredibly talented developers. But at the end of the day, building the right software, even if not the best software, trumps the inverse. We often fail to quantify how destructive a poor communicator can be to the success of a business.

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.

I realize that choosing genders by coinflip would give 25% probability of this outcome, and if that's what the author did, I'll shut up, but if not, making the antisocial cerebral character male and the technically weak, pleasant communicator female seems like lazy writing to me.

Gaah this is such a strawman, and the gender aspects of it, a woman who cannot code but is a great coworker, talk about stereotypes. Obviously trolling but I cannot help but bite.

The first thing one has to ask is, what kind of programming is it? Modifying a company's Wordpress installation hardly requires a compiler specialist. Actually, it doesn't matter if somebody's code is 50% longer just as it does the job, and doesn't create a larger instability in the codebase or production environment.

I find that beginner programmers and refactoring aficionados have the same tendency to introduce weird little bugs. The article talks about introducing bugs like something bad. Every non-trivial code change in a large project has a good chance of introducing a bug, it's just how shit works.

This argument also totally bypasses the problem of good UI. Compiler guys might be very good at getting those loops tight, but are they really interested in good UI for business software? They may, but they may also not be able to execute on it. I think that for a good operation we need a diverse group of people who cover all areas of expertise needed to build a great experience. OTOH if we're talking about building a kernel extension instead of an iOS app then different needs apply.

Another major example is being able to identify which problems matter to the company. Rodrigo works on whatever his manager tells him to do and executes splendidly, while Gabriella identifies the big problems that most people don't even realize can be solved with code and fixes them. In this case, Gabriella can easily be massively more valuable. I've mentioned on HN before that I used these same problem-identifying skills, combined with very crappy, amateurish coding, to save a former employer $2MM in under a year. And I've continued to do this-e.g., by writing SQL Stored Procedures to solve problems that many people in a company run into, which has been a tremendous help for my career.

That's not to say communication skills aren't important, but identifying the projects/problems relevant to the business at large are even more so.

> a manager would rather work with Gabriella

Managers avoid Gabriellas because Gabriellas try to get out of their coding jobs as fast as they can, usually by going for the manager's job, usually with a few freshly sharpened knives in their holster.

> [Gabriella] takes 30 lines to write what should be written in 15 or 20

That's a typo. Should read "takes 30 hours to write what should be written in 15 or 20 minutes".

> Gabriella comes out way ahead. And I've seen it happen many times--programmers who are great employees but not great coders move to the top while the great coders but poor communicators stay on the bottom.

What is the top and what is the bottom? Is getting out of coding as quick as possible your definition of moving to the top? Gabriellas also get to "the top" by passing off Rodrigo's work as their own.

Interestingly, people usually complain about people who can't pull their weight technical skills wise, yet in my experience, I've found it way more frustrating picking up the slack for other people's lack of employee skills so I'm happy to see this on the front page.

I go to great lengths to be responsive and send very carefully crafted short, succinct emails. I've been working since I was 14 in IT in some capacity or another. This means over the years I've developed a savvy as far as maneuvering in a corporate/professional environment. Being paired with people who lack this has been somewhat frustrating.

Perhaps it is because I've spent the majority of my career as a developer that I when I put my manager hat on, I want a team full of Rodrigos. Quick standup meetings and dev-owned granular task breakdowns are easy ways to address Rodrigo's lack of proactive communication and disinterest in deadlines.

I haven't been in a situation where Gabriella is someone I'd want on the team. Devs are often more productive if they check their email a few times a day, rather than every minute. If there's an issue that needs urgent attention, I'm generally capable of stopping by their desk or calling them on the phone.

I'm also annoyed by the subtle sexism that underlies this article. In my experience, female developers are much more likely to be highly skilled than not.

Perhaps OT: but is it only me that sees Gabriella as a female name and thinks the article is a little implicitly sexist? If the author chose it and tries to point out that there's a sex difference then fine. But otherwise, implicitly inserting a sex difference suggestion is not good.

> ... programmers who are great employees but not great coders move to the top while the great coders but poor communicators stay on the bottom.

"Staying on the bottom" apparently means making a six figure salary while doing intellectually stimulating work. If you've got the portfolio to back you up, you don't even need a college degree.

I like it at the bottom. It's cozy down here.

#firstworldproblems

Of course - what you actually want is the best of both Gabriella and Rodrigo. And there are a bunch of those folk out there. If you're a Rodrigo go learn more from a Gabriella. If you're a Gabriella go learn more from a Rodrigo.

But - y'know - if I was forced to pick between a Gabriella and a Rodrigo I'd pick Gabriella every time.

Because she can "explain complex technical issues quite clearly to clients, she has never missed a deadline, she is constantly looking for feedback to improve her work".

I've worked and mentored people like that before. People who are actively looking for feedback are easy to coach into being better developers. A team lead can polish up Gabriella's coding skills. She's open to feedback. She'll get better fast.

Conversely I've found it really hard to coach Rodrigo types into being better team players. They think that the stuff Gabriella is good at is just about the "need to impress to get jobs and promotions and raises and pats on the back". They don't understand that the stuff Gabriella is good at is vital to building products with a team that meet the client's needs and make them and the end-users happy.

And these days - most of the time in most places - software development is a team sport. I've seen more teams of Rodrigo's kill projects through inattention to deadlines and client needs than I have seen Gabriella's kill projects through bad code.

Gabriella is the perfect employee for cost centers, places that consume rather than produce technology.

Rodrigo should go work in a technology company that makes the products Gabriella will use.

Managers are always claiming coders have bad "communication skills". That's fine because on the other side most programmers feel that managers are incredibly stupid and focused only on their careers and getting attention above all else.

For example, this article: Managers as lazy, stupid careerists?: Contestation and stereotypes among software engineers http://www.emeraldinsight.com/journals.htm?articleid=1615745

Software devs for the most part understand that many managers and analysts have no concept at all of what it means to develop software and be required to produce complex deliverables. Their only taste of what it might be like is to quibble about things like capitalization and punctuation in their powerpoints. Yes, if you spend all day going to meetings and aren't required to produce anything except opinions, then it would be very easy to see someone working a software component into existence for the entire day while ignoring all the super important, self-absorbed people as a 'bad communicator.'

As for what Rodrigo should do, its obvious he needs to move to a start-up as a founder as there's never going to be a satisfactory employee position for someone like him.

If you by some miracle has got a hold on Rodrigo, now you just need to weave a management framework around Rodrigo. One which will keep him fed, undistracted and with a nice queue of interesting tasks.

Think of all the plumbing and shields that make nuclear reactor use feasible, and then of massive amounts of power this configuration will produce.

That's like the Grim Reaper management in Dungeon Keeper if you understand the idea.

Hiring one or two engineers (per team) who are as technically capable as they are socially capable is ideal. The Rodrigos on the team will rely on this person to communicate what the hell is going on, and the Gabriellas will (must) raise their game -- although, I think that you can do without a Gabriella if you have one or two of these ideal engineers around.

The combination of coding and employee skills usually also means that this person is a good candidate for a team lead.

If you've never worked with someone who's an A+ engineer as well as a fantastic teammate/subordinate, you don't know what you're missing. The unsocializable uber-geeks can do what they do best, which is produce great code, and the managers are much more informed (and relaxed). And the teammates (like me) find working with them a pleasure.

In summary, coding skill vs. employee skill is a false dichotomy; the alternative is someone who has both skills and whose value to a team and to management acts as a team & production multiplier.

These two things are contradictory:

1. "He can generally write very solid code that's readable and handles edge cases beautifully."

2. "you can't get a clear thought out of him without rambling incoherence surrounding it"

It would be better to talk from actual experience than to invent things that don't exist, in support of a point that must necessarily therefore be bogus.

Very interesting. Can definitely relate ..

This part made me chuckle:

> [Rodrigo] does things his own way, and you can't get a clear thought out of him without rambling incoherence surrounding it.

However, I would argue (and I'm biased, of course) that if you're a technology company, it's the manager's responsibility to adapt to Rodrigo

I'm more like Rodrigo than Gabriella. I have all the soft skills that are needed but I'm not a great fan of following "deadlines". When I was working for a company I completed most of the tasks assigned to me before deadline but I wasn't happy doing that. I love to do the best possible work in least possible time humanly possible but as I have noticed most of the "deadlines" created by managers are unrealistic and stupid. Let me give you an example. Our project manager at that time(MBA from a top university) committed to client(electricity board) that the project we were working on will be completed in 3 days time and they can have a trial of it on 4th day. He didn't consult with programmers before making commitment. The reality was that it required another 20 days of work. Three of us had to work 56 hour continuously to complete it - an untested crappy code that just worked. I didn't liked it. Eventually after some months I left the job and never worked for anyone else again.

So this is how it works - Stupid clients will pressurize stupid managers for unrealistic deadlines and the stupid manager will accept it and will further pressurize programmers to do it. Good programmers will eventually leave the company/project and programmers like Gabriella will continue to meet the deadlines writing crappy code that just works and will eventually break down someday and it will be really hard for someone else to correct it because the code is a mess resulting in loss to client. It bites back.

This is a question of trade off. As a developer if you bug me and ring me every 5 minutes so I can extinguish fires to please the management, I tell you I won't hit any deadline and I gonna produce shitty code.

As a dev team manager I always try to create the correct environment so people are protected from management noise. They can be efficient at what they do and hit the deadlines. At the same time you need to tool your team to clearly separate what is urgent from what is not so you can disturb their work flow only if the emergency worth it.

This is a false dichotomy. While there are people that rely on one skill to support another weak skill (social skill to support lack of technical skill, or vice versa), not everybody is like this. The best people are not over-reliant on either skill, they have both.

You can understand your objective, explain to the business in a simple way what you will be doing, and then implement it in a high-quality way. You might be better at one thing, but there's no reason that you should become either of these dysfunctional types.

I personally, as a programmer and a person, would rather work with Gabriella than Rodrigo. While it is definitely true that Rodrigo is a much better person, if I can't depend on him to get me his good code by the deadline, I would rather have Gabriella's "working" code, because, hey, it WORKS, and it meets the deadline -- the biggie here. If I can't depend on him to communicate with me and who ever else we work with, it is another negative for him.

I don't know about other programmers, but for me, the better I understand my teammates and/or colleagues, and the better we perform as a whole, the better I perform individually.

I also would rather optimize Gabriella's code than have no code at all from Rodrigo. Although, after reading one of the comments below, if Rodrigo was missing deadlines by a small margin, let's say only by a few days, I would much rather get code from him. If I was his manager instead of his project teammate, I wouldn't mind his in-depth technical explanations as much, mostly because I do the same thing, and I value expanding my own knowledge well beyond its borders over just getting a brief overview without the how and why because without them, the what is almost worthless by itself if the manager has to turn around and provide instructions to the team based on the how and why that s/he was not given.

This is an interesting read for me. I am 33 years old and work as the CTO of a large fund in NYC. I started off as a coder and then got promoted all the way up to the glorious rank of CTO, which really means the guy with the most responsibility and doesn't get to code as much anymore :(

I agree with this article in many ways but I don't think you can separate out the two characters in such a black and white fashion. Where I work, there is no such thing as "bad coders" because the standard for hiring is so tight. Everyone here really knows their stuff (including me!) but I do agree what separates people apart is their communication skills. I was one of the few people that was not afraid to talk to management and express my opinion on certain things. Most of the other programmers just deferred to me and I was almost always the representative of the coders to management. I work with some really smart people, genius-level guys, but most of them are extremely introverted. The ONLY difference, from what I can see, is that I am almost exactly the opposite. I am an extrovert through-and-through but also love nerd-type things. Someone that can bridge the gap between the technical and non-technical worlds is a worth a lot to an organization.

    def toot_own_horn(self):
        pass

Actually the problem children are excellent coders who are toxic to the Gabreillas in the office. As a manager having a person who writes perfect code but pisses everyone else off, is less useful than one who writes moderate code but gets along, even if they are quiet and moody.

I think a good team will have some of each and a good manager is responsible for everyone getting along. The interesting question is what happens when Rodrigo reports to Gabriella a year down the road - will he realize that her people skill got her in that position?

I have a mantra that I repeat on a regular basis in a lot of contexts:

"You espouse a false dichotomy."

This article is pretty true to what I've encountered.

In a previous job I worked with hands down the most knowledgeable computer tech I've ever encountered. He got fired from his job as a computer tech.

The reason he got fired was because he didn't gel with the team (use deodorant, hygiene in general). His skills made him arrogant (elitism) and his communication to clients was woeful (he spoke tech talk to non tech people).

I think the simply way to communicate this idea of coding skill vs employee skill is Yin and Yang. Strong technical skills (Yin) are wasted, unless you have good employee skills (Yang).

A good employable programmer will have a balance of both.

I won't answer the question of who I'd rather work with on a daily basis as I can see both of their strengths and there's no reason they cannot both fit within a team.

If I were management, I'd groom Gabriella to be a Development Manager/Project Manager. She has the skills to speak to developers and actually understand their problems yet she also has the skills to face off with stakeholders.

Rodrigo will need to be babysat and is more suitable for less structured roles that offer more freedom from daily rigors of development work; such as an Architect or Technical Lead.

Oh puhlease...all the rambling incoherence...no wonder twitter is so successful...besides too many of you are reinventing the wheel...google the answer, tweak it and make it work - if that doesn't work contract one of you guys for 2 to 3 months for some outrageous fee and you go away in your hole and make it work...then we're happy...next subject?

Good coders work for glory, not money nor power.

My 2cents, I'd be recruiting Rodrigo hard and just pay him to hack on ghc full time, and that other one I'd at best refer to another company that might be a better fit.

Granted, what I'm up with Wellposed is pretty darn special, and I am planning on pulling baller solid computer scientist engineers in as fast as capital permits starting late fall :-)

Just imagine Linus Torvalds being nice and cuddly about a bad software and not telling(shouting)you to fix up your shit. Thank Universe for the Rodrigos of the world.

undefined

Yes, and that's why service companies look for employees who respect deadlines and product companies look for coders who get-sh*t-done.

I don't like the idea of trying to make code as small as possible. You might end up with perl one liners...

If you have such extreme people as your only choice, what you do is hire both, part time!

Yeah, "don't be a dick" is a good baseline for most things in life.

Does anybody know what blog software is being used here?

yawn

Nothing new here, nothing to see, really.

One possibly valuable angle to look at this from: people with better soft skills sometimes keep their jobs longer and/or get promoted faster/further than people with better tech skills. And this often seems unfair to the techies.

(Written as a techie, consultant and startup guy who has hired, fired, and promoted those from both camps.)