5 ms·

The skills cited in the article are: 1. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the co

by apo 7y ago

The skills cited in the article are: 1. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the computer. 2. Anticipating problems. Prefer solid foundations over veneers that appear to get the job done. 3. Organizing and designing systems. Essentially, SOLID. Two things on this: First, bad code often results from conflicting goals. Moving goalposts and on time shipping, for example. The result appears to have been written by a poor programmer, when this may not be the case. Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. The best programmers I've seen have it and the worst completely lack it. Lack of empathy leads to poor communication. If programmer can't anticipate or read his/her audience's perspective, there's no way s/he can communicate a complex concept to them. The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing. Lack of empathy also leads to disregard for the needs of users and future maintainers. Systems get built that don't need building, and systems that should be built aren't. Should the two happen to coincide, the system is a nightmare to maintain because the programmer simply didn't care about the people who would need to maintain the contraption. A lot of the 10x programmer discussion focussed on people who lack empathy. For some reason, it's easy to conflate lack of empathy with technical skill.

subjectsigma 7y ago
>The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing. This is a popular claim on HN that I don't think is true. Where does the boundary end? Is it my fault they can't understand my program if they don't know any code at all? What about if they're a Python programmer hired onto a Java project? The point is you should make a good faith effort to write readable code, especially for your team members, but you're a programmer, not a teacher. >Lack of empathy also leads to disregard for the needs of users and future maintainers. This I agree with. Its a very underappreciated reason to build empathy as a programmer.
- kareemm 7y ago
  You’re assuming that the only way developers communicate is through code. But it’s not. If you want your message to be understood, and the listener is making a good-faith effort but doesn’t get what you’re saying, the onus is on you to communicate in a way the listener understands.
Jugurtha 7y ago
I'd say that point 1 is more De Morgan and Karnaugh than code.
rjpc 7y ago
Yeah, context and empathy are two things that I'm only appreciating more and more as my career goes on. I once had this small but terribly written module written by an inexperienced developer who wasn't given the kind of feedback and code review that he should have been given. It was still running in production years after that person had left because it was in a corner of the code base that was basically never touched. What made it interesting to me was that it was badly written at almost every level from the high level separation of concerns to low level coding practices, while still basically getting the job done. I started giving this module as an exercise during interviews for a certain position, with the framing of "This was written by an beginner developer on your team. What kind of feedback would you give them to help them improve?" This sort of thing was actually a major part of the job, as it was a position that would be a kind of consulting resource for other teams and would involve many code reviews and encouragement of best practices -- basically providing subject matter expertise to full stack, cross-functional teams. The results were fascinating to me because it acted like a Rorschach test of sorts and told me a lot more about the focus on the interviewee than the code they were criticizing. More junior candidates immediately jumped on the low level issues like the boolean assignment example, naming conventions, or small snippets of code duplication, and spent all their time there. More experienced folks often mentioned the low level issues but spent more time on the higher level problems -- the class should be broken out into two, extending in the most obvious way would be hard because XYZ, this etc. Some of the best candidates would ask for more context on the situation and overall codebase. It also helped weed out the jerks who, despite the prompt, decided that the exercise was an opportunity to show off and insult the original author (who was of course anonymous), venting about how stupid something or other was or using it as a springboard to attack their current co-workers. Everyone starts somewhere. It's fine to wince a little at something that's poorly written, but the point is to actually help them improve. The better candidates were there trying to understand what their gaps in understanding were that would cause them to make certain mistakes. The very best candidate was trying to map out a staged plan of more easily digestable things to work on so that they're not overwhelmed all at once -- extrapolating a whole technical mentorship model out of what they could glean from the code review.
- meken 7y ago
  Thank you for sharing your experience. I found this comment very insightful.
vorg 7y ago
> the most valuable skill a programmer can have isn't technical, but rather social: empathy You should say "a programmer needs social skill as well as technical skills to be valuable". If a programmer doesn't have a basic aptitude for programming-like tasks, they won't be able to understand how the language works, anticipate technical problems, or organize and design systems. Until you've worked in a group that's filled with "programmers" who don't have the aptitude for coding, you won't really understand this. The social skill must complement the technical aptitude and skills, but is not more important than them. In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves.
- ghostpepper 7y ago
  I think the difference is that empathy often correlates with teach-ability, and it's much easier to teach someone technical skills than it is to teach someone empathy.
- munchbunny 7y ago
  "Social skill" and "empathy" are very different things. An awkward person can be empathetic. A charming person can be callous. In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves. In my experience the programmers who are saying that are usually engineering leadership. If you believe the endgame is becoming engineering leadership, then it's absolutely true that soft skills become more important. While I don't agree that "social skills" are the most valuable skill for a programmer, I do sincerely think it is the most common reason why competent programmers hit an invisible ceiling in their careers. I've seen plenty of programmers who are technically talented and hardworking, but who get stuck in their careers at the junior end of "senior" because nobody wants to work with them no matter how right they are. If person A is right 90% of the time but nobody wants to deal with them, and person B is right 80% of the time and people are willing to listen, I would rather keep B over A because those junior developers who are running at 60% will turn into 80%-ers under B, but they'll stay 60% under A.
techslave 7y ago
> Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. couldn’t agree more! but the term you’re really looking for is perhaps a strongly developed theory of mind. whereas empathy really is referring to emotional awareness. the worst and also most annoying programmers i know, to a person, consistently fail to see other points of view. their way is the right way, period. they tend to actually be smart, and right about very many things in a small problem domain. i dare say their raw intelligence is a double edged sword.
- beernutz 7y ago
  Maybe empathy comes in when trying to frame criticism in a constructive way that the receiver will internalize and find helpful? In some cases, it might be better to ask them about reasoning around a particular bit of code than to offer alternatives right away. In others, a good idea or anecdote about something you found useful in that spot, might be better received. In my experience, there is a good amount of empathy (or emotional awareness) involved in offering advice that will be accepted in a constructive spirit, and not seen as an attack. After all, we ALL write bad code sometimes. A bit of code might seem like a good idea at the time, but could just be overly "clever" upon later inspection. A good review comment that does not point fingers seems like it would fall under the "empathy" umbrella.
bassman9000 7y ago
Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. The best programmers I've seen have it and the worst completely lack it. +10 This is missed by 99% of articles and lists. And most programmers never stop to step on someone else's shoes.
- stevens32 7y ago
  Interesting that a one letter typo changes the meaning so much!
mr_toad 7y ago
I don’t think that social skills and technical ability are at all related. I’ve seen people with great social skills produce great code, and others produce a tangled mess. And I’ve had to deal with people with terrible social skills who produce great code. One thing you don’t see often in the workplace are people who lack both social and technical skills.

by apo 7y ago

subjectsigma 7y ago

>The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing. This is a popular claim on HN that I don't think is true. Where does the boundary end? Is it my fault they can't understand my program if they don't know any code at all? What about if they're a Python programmer hired onto a Java project? The point is you should make a good faith effort to write readable code, especially for your team members, but you're a programmer, not a teacher. >Lack of empathy also leads to disregard for the needs of users and future maintainers. This I agree with. Its a very underappreciated reason to build empathy as a programmer.

kareemm 7y ago
You’re assuming that the only way developers communicate is through code. But it’s not. If you want your message to be understood, and the listener is making a good-faith effort but doesn’t get what you’re saying, the onus is on you to communicate in a way the listener understands.

Jugurtha 7y ago

I'd say that point 1 is more De Morgan and Karnaugh than code.

rjpc 7y ago

Yeah, context and empathy are two things that I'm only appreciating more and more as my career goes on. I once had this small but terribly written module written by an inexperienced developer who wasn't given the kind of feedback and code review that he should have been given. It was still running in production years after that person had left because it was in a corner of the code base that was basically never touched. What made it interesting to me was that it was badly written at almost every level from the high level separation of concerns to low level coding practices, while still basically getting the job done. I started giving this module as an exercise during interviews for a certain position, with the framing of "This was written by an beginner developer on your team. What kind of feedback would you give them to help them improve?" This sort of thing was actually a major part of the job, as it was a position that would be a kind of consulting resource for other teams and would involve many code reviews and encouragement of best practices -- basically providing subject matter expertise to full stack, cross-functional teams. The results were fascinating to me because it acted like a Rorschach test of sorts and told me a lot more about the focus on the interviewee than the code they were criticizing. More junior candidates immediately jumped on the low level issues like the boolean assignment example, naming conventions, or small snippets of code duplication, and spent all their time there. More experienced folks often mentioned the low level issues but spent more time on the higher level problems -- the class should be broken out into two, extending in the most obvious way would be hard because XYZ, this etc. Some of the best candidates would ask for more context on the situation and overall codebase. It also helped weed out the jerks who, despite the prompt, decided that the exercise was an opportunity to show off and insult the original author (who was of course anonymous), venting about how stupid something or other was or using it as a springboard to attack their current co-workers. Everyone starts somewhere. It's fine to wince a little at something that's poorly written, but the point is to actually help them improve. The better candidates were there trying to understand what their gaps in understanding were that would cause them to make certain mistakes. The very best candidate was trying to map out a staged plan of more easily digestable things to work on so that they're not overwhelmed all at once -- extrapolating a whole technical mentorship model out of what they could glean from the code review.

meken 7y ago
Thank you for sharing your experience. I found this comment very insightful.

vorg 7y ago

> the most valuable skill a programmer can have isn't technical, but rather social: empathy You should say "a programmer needs social skill as well as technical skills to be valuable". If a programmer doesn't have a basic aptitude for programming-like tasks, they won't be able to understand how the language works, anticipate technical problems, or organize and design systems. Until you've worked in a group that's filled with "programmers" who don't have the aptitude for coding, you won't really understand this. The social skill must complement the technical aptitude and skills, but is not more important than them. In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves.

ghostpepper 7y ago
I think the difference is that empathy often correlates with teach-ability, and it's much easier to teach someone technical skills than it is to teach someone empathy.
munchbunny 7y ago
"Social skill" and "empathy" are very different things. An awkward person can be empathetic. A charming person can be callous. In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves. In my experience the programmers who are saying that are usually engineering leadership. If you believe the endgame is becoming engineering leadership, then it's absolutely true that soft skills become more important. While I don't agree that "social skills" are the most valuable skill for a programmer, I do sincerely think it is the most common reason why competent programmers hit an invisible ceiling in their careers. I've seen plenty of programmers who are technically talented and hardworking, but who get stuck in their careers at the junior end of "senior" because nobody wants to work with them no matter how right they are. If person A is right 90% of the time but nobody wants to deal with them, and person B is right 80% of the time and people are willing to listen, I would rather keep B over A because those junior developers who are running at 60% will turn into 80%-ers under B, but they'll stay 60% under A.

techslave 7y ago

> Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. couldn’t agree more! but the term you’re really looking for is perhaps a strongly developed theory of mind. whereas empathy really is referring to emotional awareness. the worst and also most annoying programmers i know, to a person, consistently fail to see other points of view. their way is the right way, period. they tend to actually be smart, and right about very many things in a small problem domain. i dare say their raw intelligence is a double edged sword.

beernutz 7y ago
Maybe empathy comes in when trying to frame criticism in a constructive way that the receiver will internalize and find helpful? In some cases, it might be better to ask them about reasoning around a particular bit of code than to offer alternatives right away. In others, a good idea or anecdote about something you found useful in that spot, might be better received. In my experience, there is a good amount of empathy (or emotional awareness) involved in offering advice that will be accepted in a constructive spirit, and not seen as an attack. After all, we ALL write bad code sometimes. A bit of code might seem like a good idea at the time, but could just be overly "clever" upon later inspection. A good review comment that does not point fingers seems like it would fall under the "empathy" umbrella.

bassman9000 7y ago

Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. The best programmers I've seen have it and the worst completely lack it. +10 This is missed by 99% of articles and lists. And most programmers never stop to step on someone else's shoes.

stevens32 7y ago
Interesting that a one letter typo changes the meaning so much!

mr_toad 7y ago

I don’t think that social skills and technical ability are at all related. I’ve seen people with great social skills produce great code, and others produce a tangled mess. And I’ve had to deal with people with terrible social skills who produce great code. One thing you don’t see often in the workplace are people who lack both social and technical skills.