Hacker News Reader

Comment by latch | Hacker News Reader

My experience is that what you're saying is true if it's being done dogmatically. I've been a subject (victim?) of this before.

But strategically applied? I think it's a pretty big win. Specifically, I'm talking about onboarding people (onto the company or a project) and working with interns and juniors. Doesn't even have to be a senior and a junior, two juniors working together is significant. And it isn't just about information flowing from SR -> JR, the benefits are tangible the other way.

I'd say at a minimum, having everyone spend 4 hours a week pair programming should be a goal to try.

View on HN

I've paired a lot and see a lot of value in it but I disagree with most of this, honestly. Agreed on onboarding, but only if that's what works best for the incoming engineer. Two junior engineers pairing rarely increases productivity in my experience and putting some arbitrary number on it like "4 hrs/week" seems dogmatic.

Horses for courses - pairing works really well for some teams and is painful for others. The presence (or lack) of pairing in a company wouldn't be a signal to me, rather I'd take it as a good sign if the team is fine with pairing whenever it makes sense but doesn't have any specific rules about it.

> I'd say at a minimum, having everyone spend 4 hours a week pair programming should be a goal to try.

Pair programming is like nails on a chalkboard to me and at least a plurality of developers generally, based on what I’ve experienced personally and read online. An expectation that I’d do 4 hours a week of it would have me hunting for a new job immediately.

It’s different in kind to other practices like mandatory code reviews or minimum test coverage. Organizations are free to select for compatible employees, of course, but it’s totally unrelated to the health of the engineering org in any dimension.

Ok, so that assertion was pretty controversial, but, honest question, what mechanism do you use for mentoring/learning/growth? Code review is the only other activity that I've seen that can have the same type of impact, but I see them as complementary.

I'm old, I learned about sql injection and hash salts and coupling and testing by being awful at it for decades. How do I transfer that knowledge so that a 26 year old can be where I was at 32 if not working closely with them, using their code as the foundation for that knowledge transfer?

I like embedding, joint design sessions, and thorough code review. For explicit junior dev mentor relationships, I like frequent one-on-ones (I’ve even done 2x per week) and quite detailed, joint ticket/work planning. I’m also happy to do pair code analysis/review for areas that I’m familiar with and the junior isn’t.

What I’m not happy to do, and what pair programming is, as far as I have seen, is to sit down with another engineer and figure out a problem together. In addition to being simply incompatible with my mind’s problem-solving faculties, it in my experience produces lowest-common-denominator software that strips any sense of self-satisfaction or -actualization from my work. No thank you.

Thanks, I appreciate the perspective.

> I'm old, I learned about sql injection and hash salts and coupling and testing by being awful at it for decades.

You pick up a goddamn book, man!

> How do I transfer that knowledge so that a 26 year old can be where I was at 32

You tell them to pick up a goddamn book, man!

Sorry for being curt. But it's the professional responsibility of developers to educate themselves. Some people think they can cram on binary trees in CS, use that limited knowledge to BS the interview, and then coast into working on the transaction system at a bank or whatever.

If a company wants to pay you to mentor a junior, that's one thing. And should be explicitly stated as such. I'm willing to help just about anyone that asks. But if I find myself showing a developer how the compiler works (or a compiler works), or the syntax of our programming language, or basic things that Google knows, I'm going to walk away from that flaming wreck of a company. I've worked with developers that hunt-and-peck typed before. You ever have to explain syntax to a guy that can barely work a keyboard? Let's just say, my threshold for putting up with BS is dramatically lower now.

My belief is that the mentorship comes from the code[1]. Juniors (+ new hires) copy the existing code.

They don't avoid sql injection because they think it's bad, they avoid it because they're adapting your code. When they're asked to make a page that does X, they just copy a page that almost does X somewhere else in the system. Maybe one day they read a list of the top 10 vulnerabilities and realize why you did it that way.

It's why loads of developers can add new functionality just fine, but ask them to build a whole new app from scratch and you will get an incomprehensible mess.

Of course, this doesn't work too well when your code base is a mess of competing styles, etc.

[1] Not that I'm saying some additional help wouldn't be good, but that the significant amount can be learnt alone, with no guidance, from the code base.

Strategic Pair Programming is the perfect way to describe the right answer here.

Essential for onboarding and cross skilling. But mandatory for everything ? Awful idea.

Not everyone learns or benefits by watching someone else type.

Reply on news.ycombinator.com