
Coding skill vs. employee skill - mcrittenden
http://mikecr.it/ramblings/coding-skill-vs-employee-skill
======
fleitz
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.

~~~
rickmb
> 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 what so many developers don't seem to understand. This isn't "gaming
the system". This is just giving better estimates which leads to better (or at
least less annoying) management because they won't be breathing down your neck
when you're far from done.

If you don't do this, you're not a cool hacker who doesn't care about
management stuff and politics, you're just an idiot. Unless you are a
masochists, in that case, enjoy your self-imposed agony....

~~~
benmmurphy
if you are always meeting your estimates then surely your estimates are
incorrect. unless an estimate is given as x% of the time you will complete the
work faster than the estimate then I would assume an estimate is 50% of the
time you will fall under 50% of the time your will fall over.

------
ajdecon
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. :)

~~~
tarice
Actually, I would expect the latter to be easier.

Teaching someone who is bad at coding means fixing 2-5 years of mistakes.
Teaching someone who is poor at communication means fixing 20+ years of
mistakes.

Plus, it's easier to convey coding mistakes than social mistakes since it's
more difficult to communicate the large amounts of unwritten social rules.

~~~
robrenaud
> Rodrigo is an MIT graduate who writes compilers in his spare time. He is a
> core contributor to Haskell and wrote a few very well known Python packages.
> He can generally write very solid code that's readable and handles edge
> cases beautifully. However, he takes days to answer emails, he rarely picks
> up his phone, he doesn't seem to have much of an understanding of the
> importance of deadlines, he does things his own way, and you can't get a
> clear thought out of him without rambling incoherence surrounding it.

If you take 20 programming novices, maybe one will be as good as Rodrigo at
coding after 5 years of intensive practice.

~~~
mikescar
Maybe, but there's a difference between the real Rodrigos, and the programmers
that just think they are in that class, but only match up on the negatives
(unresponsive, don't show up to work, think they are above the rest of the
group).

I'll take a team player who has room for improvement almost every time over
some rockstar who can't take constructive criticism.

Not that we only have these two choices, but the truly great AND nice are kind
of rare compared to the wanna-bes who think being an amateur professor at work
translates into business value.

------
gummadi
>> 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?

~~~
duopixel
I agree with you, but most of the time it's not the ability to explain
technical issues what pulls these people ahead, it's the social skills that
ease friction among coworkers and clients.

I used to work with someone who had this gift. If an unimportant feature was
difficult to implement, instead explaining technical details and ROI, he'd
somehow make the client talk himself into removing the feature.

Psychologists do something similar, they guide you into a train of thought
hoping that you will arrive to some conclusion on your own. It completely
undermines whatever defensive stance you had and all you need is some
reassurance that it's the right decision.

------
malvosenior
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.

~~~
wizzard
This is music to my ears. While I wouldn't necessarily go so far as to say
that all management is useless, they certainly seem to go out of their way to
create barriers and waste time. They tend not to understand the observer
effect: Making programmers spend more than five minutes a day reporting their
progress adversely affects their progress.

And you're right about the ego. So much ego...

~~~
malvosenior
I've been spending a lot of time thinking about where this is going and how we
can accelerate the outcome (again speaking as a high level manager). The
problem seems to come from access to capital. I've never seen an executive who
adds "10x" value in terms of what they actually can produce through "work",
instead what you find are 10x executives who create value through their
ability to literally increase company valuation 10 times via their connections
and network. Their network unfortunately will be founded on structural
advantages they've gained from society (rich parents mostly). The right rich
guy will get your company sold for millions of dollars more than an engineer
can because his friends will be doing the acquisition. It has NOTHING to do
with the actual value being created by the company.

As for middle management, they are a resource that should be subordinated to
the engineers and other high value producing individual contributors. Non-
creative work needs to suit the needs of the creatives not vice versa.

So, how to get around executive domination? Lowered costs to deploy technology
is a great first step. When you can launch your product on ec2 and get going
for an order of magnitude less money than was possibly 10 years ago, then you
don't really need to raise millions of dollars (which by the way would be
spent by the MBA types trying to attract top talent anyway). If you are top
talent, run with it. Avoid ANYONE who isn't going to be producing value for
you and your vision. Avoid the cult of VCs. Tech talent needs to take
ownership of the success narrative and not give in to temptation to bring
execs and vcs on board regardless of the capital boost they may provide. In
the end they will make your product worse 100% of the time.

------
fotoblur
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.

~~~
xsmasher
Why is your example more "real" than the original? You've made Gabriella a
worse programmer, Rodrigo into a worse employee.*

*The most important task is the current one; no allowance for business priorities?

~~~
fotoblur
'Extreme example' vs 'real example' ...hmmm, did I interpret the article
incorrectly in that it was a hypothetical where mine was my own experience.
Thanks for calling me a 'worse employee' too. Guess I won't be getting a job
at tinyco anytime soon.

~~~
ianstormtaylor
Judging by the 90/9/1 rule, you've already alienated 20 people other than
xsmasher and myself.

------
bdunn
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.

~~~
vorg
> 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

Why, then, does virtually every programming job advert list screes of
acronyms?

~~~
tomjen3
Because approximately all managers are retarded. Consider how many programmers
can't program, despite daily feedback from their compilers and a pretty
objective definition of success.

Now consider that managers don't get errors when their teams don't perform
well, actions are not going to have a direct outcome on the user, etc and it
should be clear why there are so many bad managers.

------
CodeMage
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
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
_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.

~~~
loup-vaillant
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_.

------
MBlume
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.

~~~
mcrittenden
Author here, I can promise that genders weren't chosen on purpose. I was
thinking of names and the guitarist duo Rodrigo y Gabriella came to mind so I
went with it.

I probably should have swapped the order or gone with two males or something,
sorry!

------
sunkencity
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.

~~~
mcrittenden
> the gender aspects of it, a woman who cannot code but is a great coworker,
> talk about stereotypes

See <http://news.ycombinator.com/item?id=4503317>

As for the rest of your post, try not to get lost in the details. Questions
like "What kind of code is it? Who can design/build the better UI? Can't good
developers introduce bugs too?" are valid in general but sort of miss the
point of the post, which is that _in general_ , people who are "bad" at
programming but "good" at communicating and staying organized tend to be
favored by management instead of the good programmers/bad communicators.

Of course there are exceptions (based on the specific skills each job requires
and what different companies value in employees), but that's true of all
writing that speaks in general terms.

~~~
sunkencity
I see what you mean. I just don't think great programming skills are needed to
do most of what accounts for programming work these days. Load a couple of
objects from the database, change something, put it back and display some
HTML, as long as you don't totally mess it up it's OK. The lesser skilled in
programming often have some other thing they are great at to validate their
place on the team, like understanding what the business side wants, styling,
UI or organizing the team.

I think the best solution for working with less skilled programmers is to have
a framework in place that lets them be productive without having the chance to
mess up too hard, lots of enterprise java frameworks are built on this premise
"Write your code >>here<< \- and you may only call on >>these<< apis" -
enforced in strict rules. Truly skilled programmers are a limited resource,
especially when you need a couple of hundred ones for a boring project.

So what if their code is a little bit longer and buggier as long as it works,
as a lead developer once told me "if their code breaks, they'll just have to
stay a little bit longer that day and fix it".

I'd rather have a medium skilled programmer which is a team player than a
really skilled programmer who is a loner. OTOH I have fired bad programmers,
like one guy I had to explain what a for loop is to and who delivered
something completely unusable.

Off on a tangent:

I'm just generally bored with the Software Craftsmanship pipe dream. It too
easily becomes an ivory tower - creating software for it's own sake. Real
requirements are messy and real programs run in a messy environment, and I'm
not sure that "Doing things properly the first time" is the right approach. I
think it's more important to iterate and be prepared to throw stuff away,
instead of being more rigorous and shooting up design patterns. I do
understand the need for pride especially if there's pointy haired bosses
around, but I think that some of the reactions to that kind of environment are
too extreme. It's about shipping software that works, and if it does work in
90% of the cases to 30% of the cost of having a 100% solution, then maybe
that's a good business decision, especially if it fails gracefully with a good
error message "I'm sorry can't do that Dave". It just might be that a couple
of months later business has changed so things needs to be scrapped and
rewritten anyway. Of course it depends on who is funding the bill, but I
rarely see people willing to pay for military-grade software consultancy.

------
SatvikBeri
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.

------
vorg
> 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.

------
gxs
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.

------
jamesmcn
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.

~~~
OmIsMyShield
In my experience, people come with various talents and skill levels.

Seeing any correlation of ability, skill level, or talent with some shared
physical feature is more often than not confirmation bias.

~~~
jamesmcn
The bias you are looking for here is survivorship bias. Minorities have to
outperform their majority-peers or they don't get hired or promoted. So those
that remain are disproportionately skilled.

But my concern is the narrative fallacy - we ascribe far more importance to
narratives than they deserve. The way to defeat that is to fill our narratives
with the future that we want rather than the future that we don't want.

------
aangjie
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.

------
actsasbuffoon
> ... 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

------
adrianhoward
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.

------
diego_moita
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.

------
codeonfire
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.

------
guard-of-terra
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.

------
tonecluster
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.

------
gruseom
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.

------
hasenj
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

------
anujkk
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.

------
gbin
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.

------
lhnz
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.

------
rlod
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.

------
stevenelliottjr
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

------
ChuckMcM
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.

------
zwieback
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?

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

"You espouse a false dichotomy."

------
fiziklgrfiti
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.

------
infinii
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.

~~~
nodemaker
Well in all likelihood, Rodrigo will probably leave/get fired and then go do
his own startup! This is clearly not working for him!

------
dukecylk
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?

------
jhrobert
Good coders work for glory, not money nor power.

~~~
EliRivers
This is incorrect. Coders are as diverse as people. Some work for the money,
some like coding, some hope to move up to management, some are marking time
until they find something better, some are this, some are that; they cross the
whole spectrum of humanity just like everyone else.

~~~
jhrobert
Humm... I was talking about "true" good coders (kidding).

------
carterschonwald
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 :-)

------
realrocker
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.

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

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

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

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

------
lhnz
Does anybody know what blog software is being used here?

~~~
nwilloughby
Drupal

