8 ms·

The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true. In the middle of last year

The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true. In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates are working on applications which have 2-4 years of catching up to reach the same level of maturity as my existing work. It's taken me the better part of a year to communicate the whys, whats, and hows of the systems we've built. I've given multiple talks, explained in 1:1s, written docs, and it's just taken a really long time to get across these ideas. All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.

inadequatespace 6y ago
> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so. Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).
rorykoehler 6y ago
Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.
- cloogshicer 6y ago
  I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale. That is my experience at least (even in very well documented projects).
- chubot 6y ago
  It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful. Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
  - rorykoehler 6y ago
    I’ve never been unhappy when provided with thorough documentation.
    - majormajor 6y ago
      Do you have any examples of sufficiently thorough documentation? I've basically never been happy with the documentation I've been provided with, whether for internal company code or 3rd party OSS stuff or 3rd party paid stuff...
      - rorykoehler 6y ago
        Just do audits. There are ISO standards for practically everything and you should run internal audits (and external ones if you can afford it for important stuff).
- QuercusMax 6y ago
  Unfortunately for me, I started developing really bad RSI around January of last year, and typing has been incredibly painful. In the past I would have discussed things using whiteboards, sitting down side-by-side with code, etc.; these are all very hard to do if typing causes pain. Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a long time to unwind. Being able to gauge on-the-fly if the audience understands can save tons of time and confusion. I've got 17 years of domain experience across 3 companies in the industry; there's no way I'm going to write all that down in my docs.
  - learc83 6y ago
    Dragon works very well for dictation, and a Wacom style tablet works great as a remote substitute for whiteboarding. There are also voice coding solutions like Talon voice that work well (I use it regularly).
  - hydroxonium 6y ago
    Might be worth trying Dvorak keyboard layout. Has worked for many, me included.
  - hathawsh 6y ago
    It sounds like you need a secretary--someone who can type fast and dress up your words for wider distribution in the company.
    - QuercusMax 6y ago
      You're not wrong; I've actually thought about that. Fortunately my RSI is starting to get better. Therapeutic massage and shoulder rehab exercises have made a big difference (I had a bike accident a few years back, and my shoulders were in pretty bad shape). I stopped typing on my 2018 MacBook Pro's keyboard (which I think contributed to my problems), and exclusively use an ErgoDox. I've also been taking Magnesium as well as NSAIDs to reduce inflammation. Still a daily struggle, but I can type posts like this one without too much pain.
- solatic 6y ago
  Reading and writing scale in theory. They require an organization staffed with people who are strong readers and writers. Unfortunately, many people, especially those forced into remote work during the pandemic, are not. They will not read through explicit, clear, but long documentation; they will not respond by writing questions of their own, and will often fail at writing explicit and clear documentation of their own. You are who you hire.
  - rorykoehler 6y ago
    ....They won't do their job.
    - simiones 6y ago
      Their job is not to write docs, it's to produce a product. The docs are a possible tool towards that goal, but there are others, with different trade-offs - such as in-person trainings. It is fairly obvious that most of the industry believes the opposite from you here - thorough docs are an extremely expensive way of achieving good context, and as such are usually replaced with training sessions, which seem to fit most people better up to some point.
      - rorykoehler 6y ago
        You can’t do in-person training properly without docs. It’s not an either or choice.
- closeparen 6y ago
  It's not a one-way transfer of information. - The student has questions that it wouldn't have occurred to the teacher to answer. - The student gets confused and asks for things to be rephrased or reframed. - The student has questions that don't currently have static answers, but get computed by the teacher in real time, according to an intuition and assimilation of the facts that the student is only beginning to develop. - The teacher's answers are up to date, whether or not he has actually exercised the diligence to maintain the textbook. - The teacher fields the questions that the specific students ramping on the project actually have, rather than trying to anticipate all possible questions of all hypothetical students (and still failing). There is a reason we have college and not just reading lists. And those are subjects where the economics support massive investments in discovering the best / most broadly useful ways to present the ideas. The average software project isn't that. The commoditized software factory is an MBA fantasy. The expertise held by "key persons" is a software team's greatest asset.
  - rorykoehler 6y ago
    I learned f all in college and everything through reading and watching back video tutorials/lectures. YMMV.
    - z3ncyberpunk 6y ago
      cool anecdotal sample of n=1
    - simiones 6y ago
      Then you had poor teachers or a poor structure that didn't give you access to teachers in the right way. While documentation has both advantages and disadvantages compared to in-person training, video tutorials are strictly worse than an interactive lecture.
      - rorykoehler 6y ago
        I’m an autodidact. No teacher can provide the density and velocity of information and knowledge the Internet, science papers and books can provide. I can’t watch a lecture at 2x speed if its live. I can’t cherry pick. I have to be at a certain place at a certain time when I might not be in the right headspace. Then add on top that’s it’s basically a crapshoot whether or not you get along with your teacher or not. I don’t regret going to college but I didn’t gain much academic knowledge there either.
- ilaksh 6y ago
  I think it should help in a way. But I also believe that people overestimate how well one can learn in depth about a complex problem from reading or any mainly passive activity alone. I know there is this theory about learning styles but it's largely debunked. To get a really solid understanding of a topic such as a business domain and it's interaction with a complex process and application, it takes a certain amount of time and contact with real problems. The only time that people can quickly pick up new ideas from reading is when they have mastered all of the underlying concepts of that knowledge. But applications generally have layers of very specific knowledge required to understand the problem and existing solution. The point of the article I think is that it's usually going to take a significant amount of time for new developers to become familiar, regardless of how good the source or documentation is.
mssundaram 6y ago
> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. It doesn't have to be that way, but if that's new to you and your team, I can understand that happening
- dasyatidprime 6y ago
  I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)
- sriku 6y ago
  One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "random" manner rather easily in person.
  - striking 6y ago
    At my workplace, we have a few blocks of time scattered around the schedule for teammates to just jump in and code with other people. No agenda, no one is required to join. But a few always do, because it's so pleasant.
johbjo 6y ago
It sounds like the new teammates are too comfortable if their current learning rate is 2-4 years. That number could also be an overestimation, which reinforces the relative rank in the team. This points to another "field of tension": when the value of the company is in the minds of the programmers (not in the code), how should an organization handle rank such that all team members become stakeholders in the most effective progress? I suspect more like academic rank rather than "team lead" or "lead dev".
- QuercusMax 6y ago
  My field, medical device software, has very long product cycles. It's not that my teammates are taking a long time to learn, it just takes time for a project to reach maturity. Additionally, we've all been learning to collaborate in a new mode, with immense distractions. Prior to our reorg, we'd never actually worked together before. And we all had our own deadlines we were trying to meet. The last 11 months have been pretty awful, ya know?

inadequatespace 6y ago

> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so. Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).

rorykoehler 6y ago

Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.

cloogshicer 6y ago
I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale. That is my experience at least (even in very well documented projects).
chubot 6y ago
It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful. Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
- rorykoehler 6y ago
  I’ve never been unhappy when provided with thorough documentation.
  - majormajor 6y ago
    Do you have any examples of sufficiently thorough documentation? I've basically never been happy with the documentation I've been provided with, whether for internal company code or 3rd party OSS stuff or 3rd party paid stuff...
    - rorykoehler 6y ago
      Just do audits. There are ISO standards for practically everything and you should run internal audits (and external ones if you can afford it for important stuff).
QuercusMax 6y ago
Unfortunately for me, I started developing really bad RSI around January of last year, and typing has been incredibly painful. In the past I would have discussed things using whiteboards, sitting down side-by-side with code, etc.; these are all very hard to do if typing causes pain. Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a long time to unwind. Being able to gauge on-the-fly if the audience understands can save tons of time and confusion. I've got 17 years of domain experience across 3 companies in the industry; there's no way I'm going to write all that down in my docs.
- learc83 6y ago
  Dragon works very well for dictation, and a Wacom style tablet works great as a remote substitute for whiteboarding. There are also voice coding solutions like Talon voice that work well (I use it regularly).
- hydroxonium 6y ago
  Might be worth trying Dvorak keyboard layout. Has worked for many, me included.
- hathawsh 6y ago
  It sounds like you need a secretary--someone who can type fast and dress up your words for wider distribution in the company.
  - QuercusMax 6y ago
    You're not wrong; I've actually thought about that. Fortunately my RSI is starting to get better. Therapeutic massage and shoulder rehab exercises have made a big difference (I had a bike accident a few years back, and my shoulders were in pretty bad shape). I stopped typing on my 2018 MacBook Pro's keyboard (which I think contributed to my problems), and exclusively use an ErgoDox. I've also been taking Magnesium as well as NSAIDs to reduce inflammation. Still a daily struggle, but I can type posts like this one without too much pain.
solatic 6y ago
Reading and writing scale in theory. They require an organization staffed with people who are strong readers and writers. Unfortunately, many people, especially those forced into remote work during the pandemic, are not. They will not read through explicit, clear, but long documentation; they will not respond by writing questions of their own, and will often fail at writing explicit and clear documentation of their own. You are who you hire.
- rorykoehler 6y ago
  ....They won't do their job.
  - simiones 6y ago
    Their job is not to write docs, it's to produce a product. The docs are a possible tool towards that goal, but there are others, with different trade-offs - such as in-person trainings. It is fairly obvious that most of the industry believes the opposite from you here - thorough docs are an extremely expensive way of achieving good context, and as such are usually replaced with training sessions, which seem to fit most people better up to some point.
    - rorykoehler 6y ago
      You can’t do in-person training properly without docs. It’s not an either or choice.
closeparen 6y ago
It's not a one-way transfer of information. - The student has questions that it wouldn't have occurred to the teacher to answer. - The student gets confused and asks for things to be rephrased or reframed. - The student has questions that don't currently have static answers, but get computed by the teacher in real time, according to an intuition and assimilation of the facts that the student is only beginning to develop. - The teacher's answers are up to date, whether or not he has actually exercised the diligence to maintain the textbook. - The teacher fields the questions that the specific students ramping on the project actually have, rather than trying to anticipate all possible questions of all hypothetical students (and still failing). There is a reason we have college and not just reading lists. And those are subjects where the economics support massive investments in discovering the best / most broadly useful ways to present the ideas. The average software project isn't that. The commoditized software factory is an MBA fantasy. The expertise held by "key persons" is a software team's greatest asset.
- rorykoehler 6y ago
  I learned f all in college and everything through reading and watching back video tutorials/lectures. YMMV.
  - z3ncyberpunk 6y ago
    cool anecdotal sample of n=1
  - simiones 6y ago
    Then you had poor teachers or a poor structure that didn't give you access to teachers in the right way. While documentation has both advantages and disadvantages compared to in-person training, video tutorials are strictly worse than an interactive lecture.
    - rorykoehler 6y ago
      I’m an autodidact. No teacher can provide the density and velocity of information and knowledge the Internet, science papers and books can provide. I can’t watch a lecture at 2x speed if its live. I can’t cherry pick. I have to be at a certain place at a certain time when I might not be in the right headspace. Then add on top that’s it’s basically a crapshoot whether or not you get along with your teacher or not. I don’t regret going to college but I didn’t gain much academic knowledge there either.
ilaksh 6y ago
I think it should help in a way. But I also believe that people overestimate how well one can learn in depth about a complex problem from reading or any mainly passive activity alone. I know there is this theory about learning styles but it's largely debunked. To get a really solid understanding of a topic such as a business domain and it's interaction with a complex process and application, it takes a certain amount of time and contact with real problems. The only time that people can quickly pick up new ideas from reading is when they have mastered all of the underlying concepts of that knowledge. But applications generally have layers of very specific knowledge required to understand the problem and existing solution. The point of the article I think is that it's usually going to take a significant amount of time for new developers to become familiar, regardless of how good the source or documentation is.

mssundaram 6y ago

> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. It doesn't have to be that way, but if that's new to you and your team, I can understand that happening

dasyatidprime 6y ago
I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)
sriku 6y ago
One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "random" manner rather easily in person.
- striking 6y ago
  At my workplace, we have a few blocks of time scattered around the schedule for teammates to just jump in and code with other people. No agenda, no one is required to join. But a few always do, because it's so pleasant.

johbjo 6y ago

It sounds like the new teammates are too comfortable if their current learning rate is 2-4 years. That number could also be an overestimation, which reinforces the relative rank in the team. This points to another "field of tension": when the value of the company is in the minds of the programmers (not in the code), how should an organization handle rank such that all team members become stakeholders in the most effective progress? I suspect more like academic rank rather than "team lead" or "lead dev".

QuercusMax 6y ago
My field, medical device software, has very long product cycles. It's not that my teammates are taking a long time to learn, it just takes time for a project to reach maturity. Additionally, we've all been learning to collaborate in a new mode, with immense distractions. Prior to our reorg, we'd never actually worked together before. And we all had our own deadlines we were trying to meet. The last 11 months have been pretty awful, ya know?