4 ms·

Companies who are in constant chaotic crunch time build tech debt partly because the people who would mentor do not have time or energy to help others. I know

Companies who are in constant chaotic crunch time build tech debt partly because the people who would mentor do not have time or energy to help others. I know that several times in my career, I've had a good mentor and I've grown hugely during those times. I've found that you can mentor in different ways, some more effective than others: Writing good, clear documentation depends on people reading it, which depends on them knowing it's there! Showing them during a group meeting rather than just mentioning the docs has a much better result. Simply saying "my door is always open" doesn't get much in the way of engagement. You, as a mentor, have to put in some footwork attracting people and maintaining the contact. It's all too easy for a junior person to feel overwhelmed by sprints and deadlines, for them to push the mentor session out a week over and over. Or even remember to schedule a session. It's also easy for the juniors to depend on the mentor-level folks taking care of the more complex things. It's faster, and during the everlasting crunch time, less burden on the junior. So to get the team benefit you have to spend the time going through the "pain" of having someone slower and less knowledgeable do The Thing. (Maybe more as I wake up, I hope this is useful to someone and not complete bullshit!)

ChrisMarshallNY 5y ago
> which depends on them knowing it's there! This. Indexing is So. Damn. Important. Documentation and knowledge discovery is crucial, and still very much a WIP. I don't claim to have the answer. I write a lot of really relevant, heavy-duty documentation, with my projects. That no one reads. I know this, because they keep asking me questions that are in the docs. I am their index.
- math-dev 5y ago
  I was thinking about this. I think its okay to be the index if it means you only need to spend a couple of minutes digging out the link and sending to them vs recreating the full explanation each time
  - ChrisMarshallNY 5y ago
    So far, that is how I do it. My stuff isn't particularly popular, so it doesn't take much of my bandwidth (well, actually, one project is very popular, but that has been taken over by a fairly energetic and talented team).
    - math-dev 5y ago
      Makes sense
- Decabytes 5y ago
  I run into this exact problem at work. I focus a lot on writing good documentation, and then no one can find it, or they ask me where it is. One solution I employ is just linking all documentation to a single document (like a table of contents) so people only have to remember 1 place to go. Only if it’s unclear on that table do they ask me, so it happens less often
- gregkerzhner 5y ago
  The problem with docs is that unlike code, documentation has no mechanism to keep it updated as things change. Even something really close to the code like code comments tend to get stale. Separate docs are hopeless - unless you are the owner of the code and the doc, and have great discipline, docs are almost guaranteed to diverge from the code. When this happens, it’s tough to say what’s worse - a stale, and sometimes wrong document, or no document at all. So, in my career I’ve come to rely less and less on docs, and more and more on just reading the code. Docs can lie - code rarely does.
  - ChrisMarshallNY 5y ago
    I've found that headerdoc-style documentation works very well. It does require a teensy bit of extra discipline and vigilance, on my part, but it is usually supported by many tools. If I do it that way, it's automatically displayed in mouseovers in Xcode, and can be compiled into organized sites, by Jazzy. I write about my methodology, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
BlargMcLarg 5y ago
>It's also easy for the juniors to depend on the mentor-level folks taking care of the more complex things. From my experience, this isn't just the juniors. It feels "easier" (read: efficient short term, problematic long term) for the party doing the "teaching" and management wanting things to be done quick. This also makes it harder to raise mentors, since would-be mentors aren't acquiring the experience to become mentors. This becomes even worse in places where bad practices and inefficient long term solutions reign. Best case, it keeps people from learning proper practices on their own thanks to all the friction. Worst case, it creates a cargo cult where bad practices are continuously hammered down and any attempt at breaking the cycle is met with even worse friction.
nomel 5y ago
> Simply saying "my door is always open" doesn't get much in the way of engagement. You, as a mentor, have to put in some footwork attracting people and maintaining the contact. The pandemic has made me realize I have so much to learn here. "My door is open" somewhat worked when we were all on site, and I sat in a place that everyone passed. But, people will not reach out to seek help, they don't really want to understand, and they're comfortable with confusion, and will just carry on with their work. That sounds negative, but I think it's the reality for many, and I need to learn to work with that reality. More importantly, I need to make sure that reality doesn't make me bitter. I've found that just reaching out and asking if they have any questions isn't enough. They'll say no, because they don't know what they don't know, and are comfortable with the confusion that they're aware of. So, what's a good way to maintain contact? Reviews? How do you get people to want to review code, without policy?

ChrisMarshallNY 5y ago

> which depends on them knowing it's there! This. Indexing is So. Damn. Important. Documentation and knowledge discovery is crucial, and still very much a WIP. I don't claim to have the answer. I write a lot of really relevant, heavy-duty documentation, with my projects. That no one reads. I know this, because they keep asking me questions that are in the docs. I am their index.

math-dev 5y ago
I was thinking about this. I think its okay to be the index if it means you only need to spend a couple of minutes digging out the link and sending to them vs recreating the full explanation each time
- ChrisMarshallNY 5y ago
  So far, that is how I do it. My stuff isn't particularly popular, so it doesn't take much of my bandwidth (well, actually, one project is very popular, but that has been taken over by a fairly energetic and talented team).
  - math-dev 5y ago
    Makes sense
Decabytes 5y ago
I run into this exact problem at work. I focus a lot on writing good documentation, and then no one can find it, or they ask me where it is. One solution I employ is just linking all documentation to a single document (like a table of contents) so people only have to remember 1 place to go. Only if it’s unclear on that table do they ask me, so it happens less often
gregkerzhner 5y ago
The problem with docs is that unlike code, documentation has no mechanism to keep it updated as things change. Even something really close to the code like code comments tend to get stale. Separate docs are hopeless - unless you are the owner of the code and the doc, and have great discipline, docs are almost guaranteed to diverge from the code. When this happens, it’s tough to say what’s worse - a stale, and sometimes wrong document, or no document at all. So, in my career I’ve come to rely less and less on docs, and more and more on just reading the code. Docs can lie - code rarely does.
- ChrisMarshallNY 5y ago
  I've found that headerdoc-style documentation works very well. It does require a teensy bit of extra discipline and vigilance, on my part, but it is usually supported by many tools. If I do it that way, it's automatically displayed in mouseovers in Xcode, and can be compiled into organized sites, by Jazzy. I write about my methodology, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/

BlargMcLarg 5y ago

>It's also easy for the juniors to depend on the mentor-level folks taking care of the more complex things. From my experience, this isn't just the juniors. It feels "easier" (read: efficient short term, problematic long term) for the party doing the "teaching" and management wanting things to be done quick. This also makes it harder to raise mentors, since would-be mentors aren't acquiring the experience to become mentors. This becomes even worse in places where bad practices and inefficient long term solutions reign. Best case, it keeps people from learning proper practices on their own thanks to all the friction. Worst case, it creates a cargo cult where bad practices are continuously hammered down and any attempt at breaking the cycle is met with even worse friction.

nomel 5y ago

> Simply saying "my door is always open" doesn't get much in the way of engagement. You, as a mentor, have to put in some footwork attracting people and maintaining the contact. The pandemic has made me realize I have so much to learn here. "My door is open" somewhat worked when we were all on site, and I sat in a place that everyone passed. But, people will not reach out to seek help, they don't really want to understand, and they're comfortable with confusion, and will just carry on with their work. That sounds negative, but I think it's the reality for many, and I need to learn to work with that reality. More importantly, I need to make sure that reality doesn't make me bitter. I've found that just reaching out and asking if they have any questions isn't enough. They'll say no, because they don't know what they don't know, and are comfortable with the confusion that they're aware of. So, what's a good way to maintain contact? Reviews? How do you get people to want to review code, without policy?