Threads for trptcolin

    1. 1

      Couple weeks before $NEW_JOB starts, so going through and the SRE workbook. And having the occasional lunch beer 😹

    2. 3

      Thanks for making the effort to document this!

      btw, you’d probably avoid weird breaking changes on minor versions like this by using LTS (even-numbered major) versions of Node.

      1. 1

        Sweet, TIL Node has LTS versions.

    3. 4

      kudos for taking the time to document every (or nearly every) step along the way.. It’s way too easy to rush after the rabbit down the hole than to stop every step and document it.

      1. 3

        Having tried doing some documenting, I believe it’s not simply “too easy” to not do, but rather doing it is somewhat difficult and takes some investment. In particular, I feel finding out when to start documenting is the most difficult part. You can’t document every single step/command you’re ever doing, as it will take a huge hit on your dev speed. But then with bugs/strange behaviors, it’s often that you don’t know how deep it will go when you first observe it; often it starts super inconspicuously, “everyday typo”-grade trivial. You would have to be very self-aware and vigilant, and have enough self control, to tell yourself after some ~3 commands of debugging, “Hey, it’s already becoming not that trivial as expected; so let’s halt my progress now, and seemingly waste some time to copy a few of my last commands, and their results, to a notebook file, followed by some succint yet understandable field notes on what was my reasoning behind them for expanding later”.

        Still, I found that if the initial investment is done, trying to do some documentation/journaling on the way, although seemingly expensive (in terms of time), has some benefits that might in fact conserve time in longer term. Specifically: you can sometimes get back to some tricky commands that proved useful; or verify which combinations of tricky cases you already tested, vs. which are untested yet; or take a few steps back to rewind and review the path till now when you’re stuck, looking for new directions to explore.

        With all that said, I don’t really think my field notes would be readable and understandable to anyone else verbatim. On the other hand, I still considered publishing some of them anyway, as an experiment; though I haven’t grown enough courage to actually do it yet. I am curious if the original post is published after some extensive editing, or did @trptcolin already achieve such a level of mastery that their work journal is insta-poetry? :) This way or another, huge respect.

        1. 3

          Yeah this is not my typical work-journaling style at all. Normally I’ll take notes if I’ve got a more creative/brainstorming/research problem to dig into, but much less often when it’s a coding thing or a bug. I can imagine benefits though! Maybe I’ll try some middle ground in the future.

          For this, I feel like I tend to run into weird stuff a lot, and I just wanted to share some tips & process stuff with some of my newer colleagues. So once I was maybe 2-3 steps in and realized it wasn’t already covered by our README (but wayyy before the end), I thought I’d try and capture all the steps I was taking, in the hopes someone could find a few tricks that’d help them. I probably just cleaned up a few typos and added a link or two (?).

        2. 1

          By “too easy not to” I meant “there are lots of reasons/excuses why one might not do it, including difficulty, reliance on being vigilant, and basically all the things you just said.”

    4. 1

      You could have done nothing and it would have fixed itself eventually anyway…hopefully.

      1. 1

        Hard pass.

        1. 1

          “And that’s when we started using patch(1) for updating the website”