Coding skill vs. employee skill(mikecr.it)
mikecr.it
Coding skill vs. employee skill
http://mikecr.it/ramblings/coding-skill-vs-employee-skill
43 comments
> 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....
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....
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.
I've seen a few Rodrigos (from distance mostly) in my life and it turned out later that they are all happily employed at tech companies.
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.
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.
Upvote just for "Most of management's problems are management's creation.'
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. :)
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. :)
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.
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.
> 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.
If you take 20 programming novices, maybe one will be as good as Rodrigo at coding after 5 years of intensive practice.
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.
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.
To be honest, I went back and forth several times on which one I thought would be easier. It's extremely dependent on the skills and personality of the person in question.
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.
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.
I feel like I've met a similar number of good communicators and good programmers--despite an enormous bias toward meeting good programmers. Besides, good communication is a core human competency; so I suspect that the number of great communicators vastly outnumber the number of great programmers.
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.
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.
I think the problem may actually socializing and not really communication. I noticed that people often confuse/combine the two. I haven't met any programmer that can't communicate, but I have met many that aren't very social.
It's very easy to give someone a list of concrete things they need to do about communication: 1) respond to emails within one business day, 2) update your manager and coworker 4 days before a deadline if it looks like you'll miss it, etc.
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.
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.
Yes, it's easy to give someone a list to do, but if you want him to do exactly what you want him to do, there's one certain condition: the man must be good at communication.
I got some colleagues who are like the guy in this post, it's very hard to let them see the importance of communication, they are very stubborn. Mostly, they see what they are doing matters.
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'm not saying teaching someone coding is easy, but at least you can see some progress on this, which make both side much easier.
Plus, from the description I read, Gabriella shows an interest in becoming a better programmer: she is constantly looking for feedback to improve her work. We get no such indications about Rodrigo.
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.
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.
Rodrigo just needs a $15hr personal assistant / secretary to handle to the interpersonal items. Now you have the best of both worlds.
I think you're grossly underestimating the skill required to "handle the interpersonal items" if you think you can get it done for $15 per hour.
I think this a more insightful comment than the author might think.
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.
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.
IT support is quite a bit different than software development.
IT support doesn't require any programming skills.
Having done it, it's easier to train Rodrigo to communicate well and to function within the context of a team, with the proviso that this doesn't mean training Rodrigo to become a team-monkey, it means finding an acceptable balance between the needs of the team and Rodrigo acknowledging that he works with others who have their own needs.
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.
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.
I wonder which is easier: training Rodrigo to communicate well, or training Gabriella to program?
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.
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 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?
>> 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 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.
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.
I think what actually happens is that her understanding of the technical issues is simple minded in the first place, and she explains it at a level that a layman can understand. Where as Rodrigo has a deep understanding of the issue, and he can't find a way to explain it without involving the listener in some technical details that they don't understand and don't care about.
I’d posit: the amount of time you spend teaching and advising your coprogrammers increases with experience and competence so that you spend less and less time actually typing and more and more time talking.
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.
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.
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.
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.
Thank you for your comment and your effort. I get a little chuckle everytime I see job ads for ROCKSTAR DEVS, thinking, "Really? Can you actually handle a rockstar dev?"
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.
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.
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...
And you're right about the ego. So much ego...
I believe the barriers and waste are deliberate or at least subconscious. If you view dev management as the middle man trying to cause a paycheck by interposing themselves between developer and user, it makes sense that they would try to disrupt and inhibit the dev process and cause cost on both sides. The benefit is that they are needed to 'manage' all the delay and disruption they are causing.
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.
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.
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.
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.
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?
*The most important task is the current one; no allowance for business priorities?
'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.
Judging by the 90/9/1 rule, you've already alienated 20 people other than xsmasher and myself.
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.
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.
> 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?
Why, then, does virtually every programming job advert list screes of acronyms?
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.
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.
Yes. In the real world finding the right question is much harder than finding the right answer.
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.
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.
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.
1. I've mentioned in another reply, but Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial. So, when the manager listens to her explanation, he understands what she says.
Rodrigo, on the other hand, has a deep understanding of the technical issues. When he tries to explain them, he involves the listener with some details that are necessary to understand before understanding what the issues are. Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager".
2. When you work on an open source projects, you can always push the deadline to next week. I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines.
I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs.
Alright, interesting, but I want to counter your points.
Either I didn't communicate my points correctly or you're not really countering my points.
Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager".
The point is not about Rodrigo's (in)ability to explain technical issues to less technical people. The point is that Gabriella is supposed to be able to do so well, yet unable to grasp the concept of performance. To quote the author, Gabriella's attitude is that "if it works, it works!" I was pointing out that this is rather inconsistent with the ability to understand complex technical issues well enough to be able to explain them to non-technical people.
Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial.
Unless I'm totally misinterpreting you, you're saying that Gabriella isn't actually explaining complex technical issues well, but instead misrepresenting them as simple issues.
While that might counter one part of my second point, it really does underline my final conclusion about the message the author tries to convey.
I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines.
Again, you seem to be countering a point I wasn't making. My point wasn't about deadlines, but about communication and collaboration. The phrase "you can't get a clear thought out of him without rambling incoherence surrounding it" describes a kind of person that can't communicate well enough even with their peers. Maybe my understanding of open source is naive, but I somehow find it difficult to believe that they can thrive when their "core contributors" (as the author claims Rodrigo to be) have such a low signal-to-noise ratio.
I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs.
Yes, I've seen quite a few of those, too. What invariably happens is that the "client" (i.e. whoever the software is for) either ends up "paying" extra for those bugs to be fixed or living with crappy product if they can't "pay". And when I say "pay", it's not necessarily in money -- it could be in time before they can use the software or reap expected benefits from it.
Like I stated, wherever this is acceptable behavior, it's because the concept of successful project is redefined to accept this. The reality is that you didn't really hit the deadline, you just strongarmed everyone into accepting the fact that you cheated by redefining rules.
Either I didn't communicate my points correctly or you're not really countering my points.
Manager doesn't care about details, so Rodrigo comes across as "unable to explain technical issues to manager".
The point is not about Rodrigo's (in)ability to explain technical issues to less technical people. The point is that Gabriella is supposed to be able to do so well, yet unable to grasp the concept of performance. To quote the author, Gabriella's attitude is that "if it works, it works!" I was pointing out that this is rather inconsistent with the ability to understand complex technical issues well enough to be able to explain them to non-technical people.
Gabriella often comes across as if she explains complex technical issues well -- but perhaps this is because her understanding of it is somewhat superficial.
Unless I'm totally misinterpreting you, you're saying that Gabriella isn't actually explaining complex technical issues well, but instead misrepresenting them as simple issues.
While that might counter one part of my second point, it really does underline my final conclusion about the message the author tries to convey.
I don't think the OP implied that Rodrigo can't get stuff done, but rather, because Rodrigo cares about the quality of his work, it comes across as if he's deliberately ignoring the deadlines.
Again, you seem to be countering a point I wasn't making. My point wasn't about deadlines, but about communication and collaboration. The phrase "you can't get a clear thought out of him without rambling incoherence surrounding it" describes a kind of person that can't communicate well enough even with their peers. Maybe my understanding of open source is naive, but I somehow find it difficult to believe that they can thrive when their "core contributors" (as the author claims Rodrigo to be) have such a low signal-to-noise ratio.
I've seen managers that prefer a Gabriella who hits the deadline even if the thing is full of bugs.
Yes, I've seen quite a few of those, too. What invariably happens is that the "client" (i.e. whoever the software is for) either ends up "paying" extra for those bugs to be fixed or living with crappy product if they can't "pay". And when I say "pay", it's not necessarily in money -- it could be in time before they can use the software or reap expected benefits from it.
Like I stated, wherever this is acceptable behavior, it's because the concept of successful project is redefined to accept this. The reality is that you didn't really hit the deadline, you just strongarmed everyone into accepting the fact that you cheated by redefining rules.
There's what the OP wanted to describe, and what he actually described. While your criticisms are valid (Rodriguo and Gabriella as described by the OP are indeed inconsistent exaggerations), this post does strike a chord.
For instance, I do see at work some people who care more about short term "done" than the quality of their code. Such code can often be shorten by 30 to 50% merely by applying local correctness-preserving transformations (my guess is, such code is written by shotgun debugging, then is left as-is when it "works", instead of being reviewed one last time for clarity).
I don't like this. But maybe that's because I don't understand that in this case, short term "done" really is more important: like we have to show "something" soon, or else there won't be any long term to speak of.
We can understand what makes good code. We can understand what people want to hear. We may even be good at both. Caring about both is harder. So when they're at odds, I think most people will bend one to meet the demands of the other. That's probably the essence of the Rodriguo & Gabriella trade off.
Hmm, I think we could go even more meta: hard facts vs politics. The best decision to make is often not the best decision to call for.
For instance, I do see at work some people who care more about short term "done" than the quality of their code. Such code can often be shorten by 30 to 50% merely by applying local correctness-preserving transformations (my guess is, such code is written by shotgun debugging, then is left as-is when it "works", instead of being reviewed one last time for clarity).
I don't like this. But maybe that's because I don't understand that in this case, short term "done" really is more important: like we have to show "something" soon, or else there won't be any long term to speak of.
We can understand what makes good code. We can understand what people want to hear. We may even be good at both. Caring about both is harder. So when they're at odds, I think most people will bend one to meet the demands of the other. That's probably the essence of the Rodriguo & Gabriella trade off.
Hmm, I think we could go even more meta: hard facts vs politics. The best decision to make is often not the best decision to call for.
Like I stated, wherever this is acceptable behavior, it's because the concept of successful project is redefined to accept this. The reality is that you didn't really hit the deadline, you just strongarmed everyone into accepting the fact that you cheated by redefining rules.
Sadly, this can be a very important component to your success as a developer (or anything else) in corporate America.
Sadly, this can be a very important component to your success as a developer (or anything else) in corporate America.
Rodrigo is a caricature, an exaggeration. Real Rodrigos only exhibit one or two of the mentioned employee defects.
Gabriella, however, is an understatement. Not only does her work require QA to fix up, etc, but her backstabbing tongue causes the productivity of the whole team to suffer, and s/he's quick to blame the Rodrigos.
Gabriella, however, is an understatement. Not only does her work require QA to fix up, etc, but her backstabbing tongue causes the productivity of the whole team to suffer, and s/he's quick to blame the Rodrigos.
Not only that but her fuck ups give management the leverage necessary to put the process in place to prevent Gabriella fucking up the whole codebase which stifles just about anyone from getting anything done.
Suddenly you're not allowed to use the ternary operator because Gabriella can't tell the fucking difference between a statement and an expression. Suddenly you have to use a massive DI framework and fucking checked exceptions because she can't understand what a lambda does, or that a closure doesn't change the value of variables outside the closure.
Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.
I really wish the OP reversed the genders of the examples because by sheer gender imbalance in the tech industry there are a lot more male Gabriellas.
Suddenly you're not allowed to use the ternary operator because Gabriella can't tell the fucking difference between a statement and an expression. Suddenly you have to use a massive DI framework and fucking checked exceptions because she can't understand what a lambda does, or that a closure doesn't change the value of variables outside the closure.
Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.
I really wish the OP reversed the genders of the examples because by sheer gender imbalance in the tech industry there are a lot more male Gabriellas.
Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.
This is a little over-simplistic, IMO. There's more to correctness and good code than "it didn't break the build." I've been there and got the T-shirt from an organization with that mindset and their code, five or more years after it's written, was terrifying in a lot of ways, because hey--none of it broke the build. I get that you probably have had run-ins with bad process, but that doesn't make all process bad.
I'm a big fan of Gerrit, personally; it encourages multiple sets of eyes on the code and I really like the "gatekeeper" approach to master. If I can't use Gerrit (and there are good reasons for not using it, often related just to development team size--Gerrit doesn't seem worthwhile for under, say, 20 devs), my personal preference is a riff off of git-flow; developers only push to develop-staging and CI constantly pulls changes from develop, builds, runs tests, and pushes to develop. Nobody other than the CI user (which anyone can log in as, but unless something's broken, you never would) can push to develop. This process (scary word!) allows us to say with authority "the build will never be broken when you pull from develop," and to me that has a lot of value--more and more as you add developers.
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.
Thanks for posting this.
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
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 don't think that in a few decades we'll see a "world filled with Gabriellas". Luckily (for the time being), our universities are really good at pumping out Rodrigos rather than Gabriellas. It's later when you enter the working world when the occasional Gabriella moves up through the company. So the real issue revolves around manager competence, or manager-team member relationships and how this social selection dynamic affects all of us.
I hate to refute everything you've just said, but sadly what you've described has not been the case my (tiny) 7 years working in IT..
I really hope you're right about the future though.
I really hope you're right about the future though.
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.
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!
I probably should have swapped the order or gone with two males or something, sorry!
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Seeing any correlation of ability, skill level, or talent with some shared physical feature is more often than not confirmation bias.
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.
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.
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
"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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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):
passActually 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."
"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.
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.
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.
Well in all likelihood, Rodrigo will probably leave/get fired and then go do his own startup! This is clearly not working for him!
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.
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.
Humm... I was talking about "true" good coders (kidding).
Good baseballers play 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 :-)
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.
[deleted]
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.
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.