Hacker News Reader

Comment by ajdecon | Hacker News Reader

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

View on HN

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.

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

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.

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.

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.

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

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.

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.

Rodrigo just needs a $15hr personal assistant / secretary to handle to the interpersonal items. Now you have the best of both worlds.

How would the secretary know what to say in response to these emails?

S/he could ask him at 10:15 each morning while he eats a snack, like any executive assistant does.

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.

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.

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.

Reply on news.ycombinator.com