1. 3

    Finally got around to opening this book and I’m digging it so far, so I’ll probably spend the weekend reading it and thinking about it – maybe I’ll even code up a few example visualizations to help me understand the concepts. My dad does a ton of data visualization for his work and this is one of his favorite books, and I’m looking forward to spending some quality time with it and then chatting with him about the concepts therein.

    1. 4

      Starting my first newsletter! I started blogging and link curation/commentary as one of my pandemic hobbies, and now I’m obsessed. I tend to send to various different subgroups of my social circle, but I figured now was as good a time as any to consolidate all of that stuff to my “greatest hits” and start sending them out on a weekly basis. Plus, it’ll hold me accountable to continue to blog and learn in public :)

      1. 4

        Plus, it’ll hold me accountable to continue to blog and learn in public :)

        Wow. Great article. I hadn’t framed/considered blogging with this perspective in mind.

        Many times, in fact, I have come across comments that deride many of the beginner-tutorials that are repeatedly created and shared, such as on Medium. That led me to believe that I should only create blog posts when I feel that I have sufficient knowledge on the topic.

        Reading this, though, I guess it makes sense that it’s okay to share what you learned because the content may be new to others who read it.

        Thanks for posting this! This gives me confidence in publicizing my writing :) and now I know at least one project that I’ll want to work on this weekend…

        1. 1

          I’m glad you liked it! I’ve been noodling around with the concept of growth in the public eye as a good tool for accountability, and when I read that article it definitely made things click for me :)

          Yeah, I’m not really a fan of dunking on people for posting beginner topics/tutorials – I understand that folks don’t want a quagmire of introductory information that can occlude search engine results and potentially offer conflicting best practices (hell, even the whole concept of “best practice” implies some sort of solved state for teaching and learning, which is a concept I don’t particularly agree with), but I’ve never been a fan of the gatekeeping that tends to accompany that desire. Of course, there’s a relevant xkcd about that sentiment, too.

          I’m happy to hear that you found enjoyed this and that it helped you feel more confident about publicizing your writing! That confidence is something I work on for myself every day, and I’m happy to inspire it in others. Hopefully your project goes well!

        2. 2

          What a great read about learning in public! This is something I have am now learning to do as well, started off with the little step of making my instagram profile non-private so I can share more photos of my journey.

          I see you have a ton of great content about learning in public, which is awesome. My question to you is at what point do you package up what you have learnt to share with others? I’m a software dev and forming a habit of writing what I have done seems like it might distract me out of flow if i’m to take notes to share later when i’m working, consequently, I think i’m a little exhausted after coding to write something decent. That’s the little quagmire I find myself in at the moment, I wish to share, just don’t have the method. Any tips?

          1. 2

            I’m glad you liked it the article! As I mentioned in another comment, I’ve been trying to wrap my head around the value of sharing “rough clay” and that article definitely helped solidify some of the ideas I’d been chewing on.

            My question to you is at what point do you package up what you have learnt to share with others? That’s a great question. To be honest, it’s a question I’ve been iterating on for a while and I’m still trying to find out what works best for me. I’m happy to share what my current practice is, though!

            TL;DR: I take rough notes on my approach before coding it, then I take a break when I’m done coding to clear my head and note force myself to write when I’m exhausted. Later (either before bed or earlier in the following day), I use those notes as a way to re-contextualize myself with my solution and flesh them out if I feel inclined to write more about it.

            Longer answer: Like you, I’m a software developer and I resonate with the sentiment of feeling too cooked to write anything else after coding for a while. While I occasionally find success in taking notes on what I’m doing as I’m working, I (again, like you) find that it interrupts my flow and it’s only something I do when I’m noodling on a problem, rather than actually working through the implementation.

            The most successful approach for me, however, has been to write my ideas down before I start coding them (kinda like a scientific notebook; I’ll write a rough hypothesis of what I’m about to attempt to implement, and then my implementation almost serves as my experiment), and then when I’m done with my implementation, I come back and fill in the details later if I feel like what I just did is worth fleshing out in more detail. These initial ideas are intentionally pretty sparse; they’re more like a memory hook that I can come back to as I’m working through my implementation, but they’re helpful as a guide when re-reading my notes later.

            Here’s some notes from my work journal about a task I did yesterday as an example:

            Okay, it looks like all of this logic is in ParseProto.scala; 
            since ParseProto is what inherits the definitions of the 
            protobuf descriptors and actually composes 
            all of our algebras together.  
            
            The problem is that right now I’m not sure how to 
            visualize what a protobuf file representation looks like; 
            I think once I can do that I’ll have a better idea 
            of where I’m going wrong currently
            
            Hell yeah I cracked it.  The tricky part was having to rely 
            on Google’s `file.getTypeName` call to the protobuf descriptor 
            but once I figured that out the implementation wasn’t hard
            

            Yeah, super rough clay, but the key is that when I read these notes later, it’s much easier to re-contextualize where my head was when I was working through this problem, and so now that I’ve taken a break from coding and don’t feel so exhausted, I’m more inclined to be able to write these ideas into a more detailed explanation of what I just did.

            Anyway, sorry for the long response, but I hope it’s helpful! Even if my approach doesn’t work for you, hopefully having more data on the process is generally useful.

            1. 2

              Thanks so much for such a detailed reply. That approach of writing the approach before makes quite some sense, at the very least it offers a basis for comparison even after one ends up using a different approach. (You can easily pit the two against each other and write up the rationale for changing). That’s super helpful and I think i’m going to give that a shot!

              Happy writing and i will check your blog often to see how this is going.

        1. 2

          Monad tutorials have been all the rage on twitter lately (with many people complaining that each one is subtly wrong) but I like this one; I think it does a good job of getting the heart of the power of monads in that they enable sequential (i.e. imperative) programming in a functional programming context. When doing reasoning about doing real-life operations in the context of programming, the ability to think sequentially about your problem space is a big win. Thanks for the share!