Welcome to the 503 Podcast with your hosts, Nicole and Sime. Deliver your monthly dose of everything related to software reliability and performance testing presented by k6. Hi everyone, this is our second episode. And in this episode we wanted to talk about something that maybe might not even seem technically related to testing or reliability, but I do think it's something that's really important. And that's knowledge management and not taking.
Okay, so I know that not taking is really important to both of us and that we spend quite a lot of time taking notes and making them searchable and organized in a way that they actually provide value for us. Why do you think Nicole, that not taking is so important?
I think it's actually one of the very practical bits of advice that I would give just because a lot about if you work in tech, I think that a lot of our work is about keeping up with current technologies and we know that it always changes and it's really difficult to do that. And so I think basically there's an infinite amount of things to learn in tech, but there's a finite amount of things that we can actually put in our brain storage and RAM.
Right, because I don't know about you, but I forget things that I worked on really intensely, like even last year. And I think that the more technologies you try and the more tools you use or programming languages you learn, the less you remember about the ones that you've learned before. I think whether you're a tester or a developer or some sort of engineer, I think what we do is knowledge work.
It's very much based on what we know, but if what we know is limited, we need to find a way to all float it into some sort of trusted system. And I really wish, like if I could talk to 20 year old Nicole just starting out, I would say take notes because at the very least having a cheat sheet of everything that I'm working on is going to be, is going to come in handy.
Like recently I came across some some notes of mine from when I was learning J meter and one of my first J meter projects apparently was testing LDAP. And I said, what's LDAP? This is me like two months ago. I had absolutely no idea what LDAP was or what what that looks like or how to test that in J meter because I'd already forgotten.
That was so many years ago. And yet in my notes, it was so well defined. Like what is LDAP? When is it used? What's the format? What's the thread unbind and what are actions you take and why do you have to do a thread bind after it? And it was just I was just so happy and it was one instance where I was like, yeah, thank you, past Nicole, having done that. So now I know where to go. And it was in my own brain at some point.
And I at the time that I wrote it, I thought I'll always remember this, but I didn't. Yeah, it doesn't even have to be good notes. At least if you write some notes, you can salvage something from it in the future or structure them as you learn more about note taking. At the start of my career, I thought, well, I'm a tester. So if I learn a programming language, I don't need to take notes on it because that's not relevant to what I'm doing.
That's what my mind frame was many years ago. But now I'm thinking, why didn't I take those notes on Python because now I have to use it or whatever it is. I think it's very difficult to tell which ones are going to be useful and which ones aren't. So I wish that I had just taken notes on everything.
Maybe not super detailed notes on everything, but like a cheat sheet. This is how to do string manipulation in JavaScript. And this is how to do it in C. Just those things would be useful to just be able to compare across different languages. Do you think there is any any limit to what you should actually document or put into notes? Do you limit yourself in any sense?
I think that there will be a practical limit. So you will have to make some decisions. I think if I sometimes I think this won't be useful at all ever, so I don't do it. But then I have to I come across the same problem again and I have to figure out and Google it all over again. The second time I will definitely write it down then because it's like a repetitive thing. I think it's not realistic to think you can actually document everything, but you can try.
Do you have any any similar requirement for what you want to actually remember in your primary storage or in your brain? Yeah, I try to keep that for things that are personal to me because I think I'm really lucky that a lot of what we know about tech and our work. That can actually be offloaded at least a significant amount of it can be offloaded to to some sort of knowledge management system.
But it's things like relationships with people. I do take some notes on that. Like if I bring up the notes on on you, Simmy, I know the name of your of your partner and things that you like and your birthday. That's because those are things that are important. Personally, I try to remember a lot of stuff about tech as well. But I sort of drawn a line for myself. I try to remember things that have to do with methodology or with big picture concepts or ideas.
I've kind of come to the conclusion that implementation details or language specific details, for instance, I'm programming a lot. Those I don't want to remember because they will fill up valuable brain space with things that I can easily Google or look up whenever I need them. I think that's a really good answer. I also try to do that. I think from what I'm doing, I think that the equivalent would be that I don't care too much about remembering exactly how to do something in a particular tool.
For instance, I might not know the exact syntax for importing a CSV file as test data in any tool or language. But I know the concept of test data and why it's useful and the reasons why it should be dynamically generated rather than just using something hard coded. So I definitely agree with you that it makes sense to keep concepts in your head and implementation in your notes.
And I also want to say that another reason why I think taking notes is so essential is that later on you'll find that you've amassed enough knowledge that you might want to share it with other people. I love seeing people who are learning in public because it's an easy way to document progress and they run across the same, they run into the same problems that I do.
And that kind of makes me feel good as a viewer when I'm like, oh, okay, so I also thought about that and was also not sure how to do that. How did he solve it? Okay, next time, even if I have a different problem, maybe I can do what he did. So that the thinking process is so much more important than the end result. So I think it's really helpful to look at my notes from when I was a new below tester and answer those questions now so that I can help other people.
Do you version control your notes? Yes, I do. Because that's something that I definitely did not consider when I was starting to take notes. I've always been an avid note taker, but I always kind of just threw away the wrong cards and I just kept the end result. But I actually think it's interesting now because there's so many different technologies we can use.
Like I know you and I both use, we both use Git for our notes, but you could also just put it in something like Dropbox, which already tracks history. Yeah, I remember when I first started taking digital notes. My first iteration was in a community at the time, which I don't even remember the name of, and that had some kind of note block feature, which I used for all my notes. So I just put it there and then I revised that note as I went along.
And it wasn't really very shun because I couldn't go back in the notes, but it was at least centrally stored. So I wouldn't have to be afraid of my computer crashing or whatever, and losing the notes because they were stored at least off premise. But then after that, when I started to work in tech, my first note-taking system was just daily notes named TXT files, basically, named with today's date.
And then I just poured all my thoughts into that file, and I had some kind of rule for myself that I was not allowed to go back and refactor notes. So they always had to build upon each other in a forward sense rather than going back and editing things. So I would have a trail of thought following the calendar or following the working days so that I could backtrack whatever I was thinking about. But that was really cumbersome, so I didn't stick with that for more than maybe two years.
Yeah, I think one mistake that I made early on is I always loved the physical act of writing. I love fountain pens, I love nice paper, I love fountain pen ink, and so I have a lot of notes that I still have not digitized. And I really think if, unfortunately, if I were doing it all over again, I would just start with digital notes, at least for the tech related stuff, because it's so much easier to copy and paste when it's already digital.
Then when it's handwriting, I don't know, I actually have like code snippets that I hand wrote. Can you imagine? Wow, that's actually how I learned the program. Really? Yeah, we didn't have a computer at home, so I borrowed programming books from the library, and then I wrote code on paper with a typewriter at home and carried the code to the library and put it in on the shared computer just to see how it executed.
So in a sense, it was kind of like, you know, back in the mainframe days when you would go with your punch hold cards and have that executed. Yeah, but I do, but would you say, if you were starting again now, would you have a digital? Yeah, at least if I grew up now in this day and age, I mean, back then, I wouldn't have digitized it, because it was so impractical to have it digitized.
Then you would have to carry around a floppy and maybe you put the floppy next to your cell phone and all the magnetic, you know, is the magnetic interference would just completely destroy the disk and then your notes would be gone. So given how sensitive the media was and how impractical computers in general were, at least when I grow up, I would probably still have opt-in for. I would have opt-in for analog at the time, but with today's tools definitely digital.
So, Sethel Kasten, the Sethel Kasten methodology was created by a German writer, philosopher, called Nicholas Lumen. And I think that his life is so interesting because he was an incredibly prolific man. He wrote about many different topics. He was a true polymath, and he managed to link them in very interesting ways. And the methodology that he credits with giving him the ability to do that is this concept of just a box of notes. It's very close to, I guess, modern library.
How would you call it? Like the Dewey Decimal System and things that real modern librarians use, but he used it for very separate atomic notes. He would create a note for each concept or idea that came to him and he would actually physically have it, and I imagine like these index cards. He would sequence them according to the topic and arrange them in some order, link from one to the other.
And what's interesting is his methodology is very, very analog. He didn't have a computer at the time, but I think that there's a lot that you can still take from that analog system, and at least personally I've brought it into a digital one.
I think that the thing that I don't follow the Zedalkasten methodology super religiously, what I do like is that it has separate phases for how to process information. So at the start you read something, so now it could be a tweet, it could be a video or an article.
And first you take notes on it that are just on a very basic level, like taking down ideas of something someone said, and then after you go through it, you do like a second pass of it, and this time you try to think about it more critically and try to refute some points or try to see where it fits in with the notes that you already have. It's kind of a more iterative approach to processing and taking notes. It's not like you take notes once and that's it, and you never look at it again.
You take notes and you think about it and you keep revising it, and then you start to think, well, what's like an abstract idea that I can take from this very specific topic that might apply to other things. And I really like that approach because it means that what do you process or what do you, the content that you consume becomes relevant not just to that context.
So if I read something about how to set up GitHub actions to work with K6, that's a very, very specific thing. But there are concepts that are related to CI-CD pipelines in general, or how you incorporate load tests into continuous pipelines, and they don't have anything necessarily to do with either K6 or GitHub actions.
That's the concept that you take from it, that you can put within your knowledge system, that you could apply to, you know, circle CI and J-meter, or whatever it is that you would want. So it's more transferable. I really love the GTD methodology that's getting things done by David Allen. It's a great book. And one of the things that sold me on that take of just productivity and just general knowledge management is the idea of having a mind-like water.
So his whole philosophy is built on the premise that the idea, your goal should be to have a mind-like water that does not get bogged down in going down different avenues. It's just a constant flow of ideas. It's a very meditative state. It's a state that does not have anxiety because you've forgotten things, or you have things in your mind that you haven't yet gotten it down on paper.
I think a lot of what he tries to do is to encourage people to just offload into a system. And that's what I took from it. I still follow his idea of having like a next actions list because having things, maybe something like do taxes as something on your to-do list is very amorphous. So for me, it's way better to have something that's like, you know, call this bank for statements or whatever it is. That's something that you can physically do.
And this is even doubly true, I think, for tech projects because you could have something that you could have as a task, for instance, learn Kubernetes. Well, what exactly does that entail? That task item would probably just sit in my list and be like something I procrastinate on because there's no concrete action. An example of a concrete action for that would be for me, talk to Sima and ask him for recommendations on things that I should look at, maybe sites or tutorials or whatever it is.
Or watch this video on Kubernetes or go through this tutorial to actually deploy something using Kubernetes. Like those are way more actionable things. And those are the ones that will get done. And now that we've talked about basics or rather, our thoughts on note taking and how that would be useful and why we actually do it. Do you have any thoughts on how note taking could be useful at work or in your professional role?
Yeah, I have been a load testing consultant before and as a consultant, there is not a lot of continuity except for the fact that things are always changing because you're not using the same tools. You're not using the same languages. They're different people, they're different architectures.
And you sort of have to learn very quickly on the go. And this is, I imagine, very similar for you as well. But I found it really useful to write, to take notes on the different tools and frameworks and programming languages that I had used. Just to quickly get it down during and after an engagement, just so if somebody says, oh, can you, do you know how to test this particular thing? Do you know how to test SharePoint? I can look back.
Okay, I did a search on my knowledge management system. I have tested SharePoint before. It was a different tool, but here are the issues that I ran into and here's how we can solve it with this new tool. So I just, I think you need to keep some sort of record. Otherwise, you just are trying to remember everything. I mean, unless you have a way better memory than I do, which, okay, it could be possible. I think it's way more practical to just have it written down.
What tech-related things do you have in your, in your Zettelcaston? If you were to browse it, you would probably find things like the memory map of a Commodore 64 and what memory locations would affect what thing on the actual computer when you manipulated it as well as the instructions that are available.
Because those resources are actually quite scarce on the internet. So if you come across something that's good and digestible, then you need one to immediately turn that into something that you can reference at a later point. But also a lot of literature notes. For instance, I used to read a lot about programming and about architecture. I still do, to some extent, but how to build solid architecture or how to write code that someone else can maintain over time.
And then I kind of tried to take notes on the key concepts of that book and what I liked about it as well as, you know, any quotes that I like to remember that makes sense to me. On the tech side, I like to separate things according to a rough sort of area. So I separate software testing from software development, for instance.
But I'm also finding that because I've worked in smaller companies that are not necessarily startups anymore, but they're more mature startups, that there are also things that have come up like things in product design. That I have sort of worked on or helped other people work on and their concepts that start to emerge. So I try to do it bottom up. Like I look at the notes that I have, and then I try to organize it.
And sometimes like for software testing or load testing in particular, even just collating things that I've written kind of makes me see like some sort of structure. Like, oh, I've written a lot about workload modeling. That's already an article. I just have to kind of rearrange it and make it flow a bit better. And I can publish that. And that's helpful. I think I think that it also helps me when I'm learning like, you know, right now I'm learning a lot on the upside of things.
And I've heard a lot about many different tools. So it was helpful for me to kind of categorize that and see like, okay, which part of this, which are the tools that are for monitoring? And monitoring now is splitting up, is being split up into three different things, just like metrics and then logs and then traces. It's just a way of placing things in your own kind of mental map.
I also want to say that I think that one thing that taking notes has let me do is that I'm more content now with starting a lot of things that never are quite finished. Because if you don't have some some way to track all of these things, I don't know, at least I felt like I had to start a project and do it, do all of it and finish it. Because otherwise, I'm going to forget, you know, so there was like this pressure to get it done now or not at all.
But now with Obsidian, it's this garden idea that it's always there, it's always improving, it's always growing. And you can at any point, if you've been keeping up with it and like doing the daily work, the daily duties of tending to it, then you can stop and harvest at any point. Yeah, I actually tried that not long ago. I was supposed to go on a podcast talking about the book, the Phoenix Project. And I've read that book like seven or eight times by now.
And yet it's really hard to pull specific things up from memory when you're going to discuss it in detail. So what I did this time was that I actually listened to the audiobook version of the book and I took notes in Obsidian and I tried to research the key ideas that I found within the book and you know, try to to bottom them. And once I started to research those topics and try to branch out from the main book, I ended up with a really good set of knowledge around the book.
What that book is about and what is describing and related concepts and what I personally think about those concepts and things like that. So when I did the actual podcast then that I had like 12 or 13 pages of content that I could just pick from as talking points. And I knew that I would have something of interest or at least of interest to me to say about all of these topics as well.
So it really lets you passively create content in a way that just regular research or just passively consuming content won't let you do. I think it goes even beyond that because you had those notes in Obsidian and you shared it with me. And so now it wasn't just you that got the benefits out of that because instead of having to read some review that's like filled with marketing, marketing keywords or whatever on Amazon.
I read the concepts that you took from that and that sold me on the idea of the book way more than something on Amazon would. Recently like we've been talking about changing our methodology at K6 to be a little bit more like base camp shape, not an exact copy. But we've kind of been talking about the principles and that's something that I've done in my previous job. But I'd already forgotten what you know how different it was.
But when I first learned it I went through the book, I processed it, I identified like weaknesses, I updated them after a year of that having been implemented. So when it came up again, I was like, oh, let me bring it up. Oh yeah, this is the problem with it. And that's just something that I wouldn't have been able to do if I were just relying on my memory.
The conclusion we were arriving at, it sounds like is that we definitely think that everyone should at least give it a try and see whether they like your journaling or note taking and whether that will be useful for them in their current situation. And if you do try this out, feel free to ping us on Twitter where I'm 0x12b and you are in underscore V-A-N-D-E-R-H-O-E-V-E-N. And underscore Vanderhoove and that is. Yes. Or using the hashtag 503 podcast. We have a hashtag. As of right now we do.
Okay. Until next time. Thank you for listening to the 503 podcast. Brought to you by K6, a modern load testing tool built for developer happiness.