Hacker News Reader

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.

Thank you for sharing your experience. I found this comment very insightful.

bookmarked.

i don’t suppose you could publicly share the module? this is a stellar interview question.

or maybe there’s a library of such code? (yes yes, jquery/openssl or your favorite true but not useful reference comes to mind)

I don't think I can, sorry. Though I imagine that if you have a code base of any size that more than a couple dozen people have touched, you'll be able to find something similar if you ask around.

What was involved in their mentorship plan?

This was years ago, so my recollection is a bit fuzzy on the details. But pair programming was mentioned, and they also thought about what kinds of tasks to assign and how to provide scaffolding.

So for instance, instead of giving a really broad assignment and then going through six rounds of code review because everything is wrong, sit down with them in the beginning and make an outline (while explaining the rationale) of classes, methods, and responsibilities. Then have them fill in the implementations. That way you can use code reviews to focus on a lot of the smaller issues that are more concrete and less hand-wavy, while giving them practice working within sane high level designs. As time goes on, move on to more abstract concepts and give them more design latitude until they're capable of making a module like that by themselves.

There was a bit about walking the fine line in how much direction to give -- too little and they're lost at sea and spending forever to merge changes, too much and you stunt their growth.

I think there was also a book recommendation, but I have completely forgotten what it was.

Anyhow, they said it all a lot better than this, and I really wish they had accepted our offer. :-P

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

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.

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

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

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.

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

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.

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.

Interesting that a one letter typo changes the meaning so much!

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.

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