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.
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....
And that's what makes a tech company a "tech" company. It can make Rodrigo come to work, produce code, be more-or-less happy.
I also guess they're compensated OKAY compared to developers in climb-the-ladder sweatshops, too.
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. :)
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.
If you take 20 programming novices, maybe one will be as good as Rodrigo at coding after 5 years of intensive practice.
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.
On the other hand, it's very hard to give someone a list of concrete things that will make them a better programmer. I suspect if you tried, you'd end up with very subjective things like 'strive for readable code' etc.
I'm not saying teaching someone coding is easy, but at least you can see some progress on this, which make both side much easier.
I ended up deciding the people skills would be easier to teach because, frankly, the culture of the field demands a lot more in terms of technical skills than it does in people skills. The bar is set a lot lower for people skills among developers than it is for programming skills, and in my opinion, pulling someone from "horrible" to "competent" communication is easier than pulling someone from "ok" to "awesome" as a developer. But the truly skilled, in either area, are hard to find and worth their weight in gold.
To me, this implies that programming is harder to teach and learn; though you could also take it to mean that Rodrigo is that much more obtuse regarding communication.
This, I think, puts Gabriella slightly over the bar -- she sees value in being more like Rodrigo, but it doesn't appear that Rodrigo sees value in Gabriella.
I once had a boss in an IT support organization that believed it was easier to teach technical skills (assuming a basic level of competence) than customer service skills. As such, he preferred to hire those with a strong customer-oriented background, and regularly passed over programmers, MCSEs, and others with IT certifications. He consistently showed high marks in satisfaction from his customers. After working with both "types" of hires in his org, I came to agree with his reasoning.
The issue isn't "Does Rodrigo reply within five minutes", it's "is it hard for others to work with Rodrigo when they need to? Is Rodrigo a barrier to others (or are others a barrier to Rodrigo)?" I've never seen a supposed workplace misanthrope who didn't understand that others had their own needs and priorities and assignments, and that a degree of co-operation was needed to avoid hurting everyone. It's just a matter of negotiating affordances that Rodrigo and his coworkers both understand and accept.
Don't tell Rodrigo to check his email constantly and reply quickly. Get him to schedule routine email checks that don't interrupt his flow and that are sufficiently frequent that others aren't unduly delayed; in return, make sure Rodrigo has the time and space he needs to work well and feel satisfied.
In my experience, on multiple occasions, it's the latter.
Possibly this just means I'm a superstar development coach, and a lousy team building coach, but I suspect not.
In my experience Gabriellas already value getting better at development. Rodrigos, on the other hand, often actively deprecate the "soft skills" that they need to improve.
With Gabriellas you just have to educate them. With Rodrigos you have to change their value system first.
>> 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 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.
This makes sense because you can amplify the benefit of a great programmers by having them influence the design decisions of lesser programmers who will also learn from the process.
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.
Having seen classical managers call a group of mild mannered programmers unmanageable before, i'm glad the some folks realize that you might get exactly what you asked for when you hired that rockstar dev: some behavior that might look prima-doma to C level execs (but is really just the devs saying, "please don't add tickets to the sprint mid sprint"). Or when some exec gets mad at people who clock in at 10 ("2 hours late!!") without realizing they fought some server or deadline until 3am.
And you're right about the ego. So much ego...
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.
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.
Rodrigo makes 1.6 times Gabriella. Gabriella leaves early, Rodrigo puts in a full day.
*The most important task is the current one; no allowance for business priorities?
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.
Why, then, does virtually every programming job advert list screes of acronyms?
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.
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.
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.
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.
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.
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.
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.
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.
Sadly, this can be a very important component to your success as a developer (or anything else) in corporate America.
It actually made my skin crawl reading the article and imagining the state of software a decade or two from now in a world filled with Gabriellas, because "that's what you've gotta do to get ahead".
Of course, with the rate at which technology is "taking over the world", I wouldn't be surprised to see the required technical understanding of even managers start to rise, with that of consumers. Hopefully we might see some relief if that happens, ha!
A question though.. what do you do if you're 80% coder, 20% communicator and your boss just doesn't seem to appreciate it? Keep job hopping until you find where you fit? Because that doesn't seem like such a good idea.. especially not where I live =S
I really hope you're right about the future though.
I probably should have swapped the order or gone with two males or something, sorry!
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.
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.
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.
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.
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.
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.
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.
Seeing any correlation of ability, skill level, or talent with some shared physical feature is more often than not confirmation bias.
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.
"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.
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.
Rodrigo should go work in a technology company that makes the products Gabriella will use.
For example, this article:
Managers as lazy, stupid careerists?: Contestation and stereotypes among software engineers
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.
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.
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.
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.
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
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.
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.
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 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.
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.
"You espouse a false dichotomy."
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.
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.
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 :-)