3 ms·

In grappling (Brazilian jiu-jitsu), it is very apparent from one sparring round with a person to get a sense for what they know and get a general idea for their

by mlady 7y ago

In grappling (Brazilian jiu-jitsu), it is very apparent from one sparring round with a person to get a sense for what they know and get a general idea for their skill/belt level. The exact belt is determined by that person's coach by measuring their skill against their personal potential. An analogy to software would be to pair program with a person. You both get a feel for each other's strengths and weaknesses while working on a particular problem. I feel that coding interviews try to replicate this, but fall short given time constraints.

bryanrasmussen 7y ago
yeah in programming you get a feeling of if someone is really uncomfortable pair programming.
sillysaurusx 7y ago
Has anyone in the world actually delivered effective, large scale software that was primarily pair programmed? Genuine question. It would be fascinating if there were documented examples. Note that this is distinct from having a company culture where pair programming is common. I am skeptical that just because you occasionally look over each other’s shoulder and exchange ideas, that the software ends up being fundamentally different from the ground up. It seems unlikely that two people would both decide to rewrite an entire subcomponent of the project from scratch, whereas individuals do that often. And the results turn out better (but only when the person is an effective programmer, otherwise it’s just a mess). I don’t think you’d learn much from pairing with me. You’d see me sitting, staring at the screen for long periods of time, saying nothing. Or experimenting with pasting various code tweaks into a repl. The final result that makes it into a text editor is the outcome of both processes, and these have long time horizons. Sometimes far longer than someone else could reasonably tolerate.
- kick 7y ago
  Guy Steele expresses similar admiration. Currently a research scientist for Sun Microsystems, he remembers Stallman primarily as a "brilliant programmer with the ability to generate large quantities of relatively bug-free code." Although their personalities didn't exactly mesh, Steele and Stallman collaborated long enough for Steele to get a glimpse of Stallman's intense coding style. He recalls a notable episode in the late 1970s when the two programmers banded together to write the editor's "pretty print" feature. Originally conceived by Steele, pretty print was another keystroke-triggerd feature that reformatted Emacs' source code so that it was both more readable and took up less space, further bolstering the program's WYSIWIG qualities. The feature was strategic enough to attract Stallman's active interest, and it wasn't long before Steele wrote that he and Stallman were planning an improved version. "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type. The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it." The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."
- otras 7y ago
  Jeff Dean and Sanjay Ghemawat are one such example. They’ve been pair programming since before Google. https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
- aprdm 7y ago
  I interviewed at pivotal in UK and they seemed to be all about pair programming.
ben509 7y ago
The point about feedback is the root of my problem with DK as an idea. In most professions, you have a ton of feedback indicating where you are, often formalized. In martial arts, you wear a belt showing roughly what level you're at, which you earned through tests done by people far senior to you. In the military, you wear your rank, maybe skill badges, and do constant training. In most other jobs, you have a title and get feedback from supervisors and such. The hypothesis of DK seems to require that the person is evaluating their performance entirely on their own, possibly because the authors were evaluating comedic skill, which is a very subjective task and something everyone knows at least a little about. Moreover, it's one where you get bad feedback: good comedy among friends is not the same as comedy that pleases a crowd. But in the professional world, you practice a craft towards a result and are exposed to your peers, the information on how you stack up is pretty objective and coming to you fairly consistently. And I think the cases people attribute to DK are better explained by other mechanisms. In particular, there's a lot of confusion between self-knowledge and knowledge of the complexity of a task. I have done phone screens and asked people stuff like, "how many numbers can be represented with 8 bits." But that's to screen out people who were applying to a job without having a clue what the job entailed. Not understanding a job description is different from not understanding your level of skill. And I see plenty of self knowledge in interviews; if I ask about algorithms and data structures, a common answer is "I haven't looked at that since school." You learn: 1. the person doesn't think that skill is relevant to the job and 2. the person is willing to admit they aren't good at it. I may disagree with the person that the skill is relevant, after all, I asked the question for a reason, but it's not a lack of self-knowledge on the part of the candidate.
EnderMB 7y ago
While I largely agree, one similarity I see to software engineering is that a beginner (i.e. a day one white belt vs a fresh grad) can work with a purple belt or a senior-level developer and be amazed at the gap of knowledge, when in reality that person might look at their superior and be wondering the same thing. There are levels to the game, and ultimately you don't know what you don't know. One of the reasons I like BJJ is because it's hard. There is no substitute for time on the mats, in the same way that you cannot become a good software engineer by simply graduating from a top-tier university or by reading every book on the subject. I don't want to take anything away from your comment, because it's absolutely right. It's just a nice lesson to consider that you can perceive something, and it not being the case.

by mlady 7y ago

bryanrasmussen 7y ago

yeah in programming you get a feeling of if someone is really uncomfortable pair programming.

sillysaurusx 7y ago

Has anyone in the world actually delivered effective, large scale software that was primarily pair programmed? Genuine question. It would be fascinating if there were documented examples. Note that this is distinct from having a company culture where pair programming is common. I am skeptical that just because you occasionally look over each other’s shoulder and exchange ideas, that the software ends up being fundamentally different from the ground up. It seems unlikely that two people would both decide to rewrite an entire subcomponent of the project from scratch, whereas individuals do that often. And the results turn out better (but only when the person is an effective programmer, otherwise it’s just a mess). I don’t think you’d learn much from pairing with me. You’d see me sitting, staring at the screen for long periods of time, saying nothing. Or experimenting with pasting various code tweaks into a repl. The final result that makes it into a text editor is the outcome of both processes, and these have long time horizons. Sometimes far longer than someone else could reasonably tolerate.

kick 7y ago
Guy Steele expresses similar admiration. Currently a research scientist for Sun Microsystems, he remembers Stallman primarily as a "brilliant programmer with the ability to generate large quantities of relatively bug-free code." Although their personalities didn't exactly mesh, Steele and Stallman collaborated long enough for Steele to get a glimpse of Stallman's intense coding style. He recalls a notable episode in the late 1970s when the two programmers banded together to write the editor's "pretty print" feature. Originally conceived by Steele, pretty print was another keystroke-triggerd feature that reformatted Emacs' source code so that it was both more readable and took up less space, further bolstering the program's WYSIWIG qualities. The feature was strategic enough to attract Stallman's active interest, and it wasn't long before Steele wrote that he and Stallman were planning an improved version. "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type. The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it." The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."
otras 7y ago
Jeff Dean and Sanjay Ghemawat are one such example. They’ve been pair programming since before Google. https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
aprdm 7y ago
I interviewed at pivotal in UK and they seemed to be all about pair programming.

ben509 7y ago

The point about feedback is the root of my problem with DK as an idea. In most professions, you have a ton of feedback indicating where you are, often formalized. In martial arts, you wear a belt showing roughly what level you're at, which you earned through tests done by people far senior to you. In the military, you wear your rank, maybe skill badges, and do constant training. In most other jobs, you have a title and get feedback from supervisors and such. The hypothesis of DK seems to require that the person is evaluating their performance entirely on their own, possibly because the authors were evaluating comedic skill, which is a very subjective task and something everyone knows at least a little about. Moreover, it's one where you get bad feedback: good comedy among friends is not the same as comedy that pleases a crowd. But in the professional world, you practice a craft towards a result and are exposed to your peers, the information on how you stack up is pretty objective and coming to you fairly consistently. And I think the cases people attribute to DK are better explained by other mechanisms. In particular, there's a lot of confusion between self-knowledge and knowledge of the complexity of a task. I have done phone screens and asked people stuff like, "how many numbers can be represented with 8 bits." But that's to screen out people who were applying to a job without having a clue what the job entailed. Not understanding a job description is different from not understanding your level of skill. And I see plenty of self knowledge in interviews; if I ask about algorithms and data structures, a common answer is "I haven't looked at that since school." You learn: 1. the person doesn't think that skill is relevant to the job and 2. the person is willing to admit they aren't good at it. I may disagree with the person that the skill is relevant, after all, I asked the question for a reason, but it's not a lack of self-knowledge on the part of the candidate.

EnderMB 7y ago

While I largely agree, one similarity I see to software engineering is that a beginner (i.e. a day one white belt vs a fresh grad) can work with a purple belt or a senior-level developer and be amazed at the gap of knowledge, when in reality that person might look at their superior and be wondering the same thing. There are levels to the game, and ultimately you don't know what you don't know. One of the reasons I like BJJ is because it's hard. There is no substitute for time on the mats, in the same way that you cannot become a good software engineer by simply graduating from a top-tier university or by reading every book on the subject. I don't want to take anything away from your comment, because it's absolutely right. It's just a nice lesson to consider that you can perceive something, and it not being the case.