Like David, I think of note-taking as primarily about writing and is the starting point of my original writing. His book covers his workflow, which is a lot like mine. I got a few new tips, but it was mostly a reinforcement of how I think of note-taking.
As I covered in my podcast, I “read” by writing. At the end of reading a book, I have generated bits of writing in Obsidian and flash cards for Anki (covered in Write While True Episode 14: Spaced Repetition). This has helped me retain the information I have read, have new ideas, and develop them into new writing.
If you write, but don’t currently have a note-taking practice and would like to see how one writer does it (in detail), this book is worth your time.
When I am trying to figure out if something is worth the cost or how to charge for something, I might build a little model in a spreadsheet. All the things that can be expressed as a number probably end up in it. What usually makes the difference though, is when I force myself to express my mental costs and benefits as a number too.
For example, I like my apartment, but sometimes I think of moving. Maybe get a condo instead of renting. But, when I put the numbers together, if I make line items about my “feelings”, I see that I can’t justify the cost difference. I just don’t value what I’d get and I personally find some parts of home-ownership very aggravating.
The same kind of line items also show up when I am trying to price my consulting services. I price in my feelings. I want to be neutral to the customer’s choice. It’s the standard “say no with a number” advice, but this is how I get to that number.
I made this podcast, but I wanted to self-host, so I learned how to do that with s3 and wrote my own way to get analytics. So, Podcasting leads to programming. And then I wrote up a blog about that program (so it led back to writing) and now I am telling you about it on this podcast. Round and round it goes.
The more times I go around the circle, the easier it becomes to write or podcast or program about one of the other things I’m doing. The content for this podcast is mostly taken from a blog post I made in February. Back then I just said that I should come up with some way to combine programming and writing more. This podcast was the result of that thinking.
I think everyone who programs has heard the story of the failure of the waterfall process.
Back in the olden days, to build software someone would first write up a document with all of the requirements. Then, the software architects would design a system and produce a document with that. And, then, I guess there would be some kind of implementation plan and that would be completed. Then, the programmers would code it up. And finally, the testers would test it. Then, you ship it.
It looked like this:
I’m going to say that I think this never happened in real life. I doubt anyone seriously tried it for anything big. Or, if they did, I hope they failed super-fast and started over.
I’ve been doing more TDD lately (which is why I’ve been watching TDDdebates), and one thing that’s been good is to not do Red, Green, Refactor, but instead do Green, Refactor, Red and end the day on Red.
That way, when I start the day, I can warm up quickly by fixing that test and before I know it, I’m done.
I know, I know. I’m supposed to be estimating using Fibonacci story points, and like Whose Line, the points don’t mean anything, but I have tried it, and I don’t get it.
For one, regular people just translate that to some notion of time anyway, and in that regard, I am very regular. If you are going to take some random number I provide and assign a date to it, I’d much rather I do the translation for you.
Also, I feel like a wrong point estimate is never acknowledged as wrong. It’s just that we didn’t do as many points this sprint as we thought we would. A time estimate is more checkable and less subjective. You can track it using normal means. When I work for two hours on something, that’s two hours. How many points did I just work?
If I say it takes 8 hours and after 4 hours, I say that there’s 6 hours left, I have good feedback on my estimate. If I say something takes 8 points and a the end of the day, I think I’m halfway done, was I right? I don’t think you can make any inferences about the correctness of point estimates without some kind of translation to time, and if you do that, then just use time.
If you love and use story points, that’s great. My only strongly held belief is that people should do what works for them. But, it’s not how I think of how long things take.
This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.
At the time I was thinking about a programming podcast, and that somehow you listened while you were doing tasks it described.
But this ultimately turned into Write While True, which is a podcast that ends with a writing-related exercise that you do right after it’s over. So, not exactly what I thought it would be, but more of a prompt. I do believe in hacking your behavior via prompts, so this is good with me.
In this TDD video I linked to, Ian Cooper mentioned that there were a series of videos where Kent Beck, DHH, and Martin Fowler debated TDD and related practices. The first one is here, and there are several more that you can see linked from that one. There are six in total—each about 30 minutes long. The debates were sparked by DHH’s blog that TDD was dead.
One interesting thread throughout is the idea of tradeoffs, and that nothing is necessarily always good or always bad. I had written this before in the context of technical debt and personal savings rate.
In these debates, they discussed whether more testing was always better and whether faster tests were always better. And of course, the answer is: it depends.
With no (or low) tradeoff cost, then yes, more and faster tests are better. If I can make tests faster with just hardware upgrades, then that’s great. Also, when benefits are very high, then even higher costs may seem low. For example, if tests take an hour, then we are willing to bear high costs to make it a few minutes. We would bear some lesser cost to make it a few seconds. But, should we keep going?
I think this all fairly obvious, but in the heat of discussion, it’s often glossed over.
(I should say that I believe for lots of kinds of problems, testing and coding together, whether it’s TDD or or not, makes you go faster and more correctly. I also mostly don’t care about unit isolation if it gets in the way—if you aren’t going faster and more correctly with tests, then I’d start wondering why and whether they might be getting in the way).
In yesterday’s podcast, I talked about spaced-repetition and how I use Anki to help with my memory. Anki is a flash card system that uses algorithms to show you cards just as you might be forgetting them.
If you are just using this casually, like I am, you only need to “study” for a few minutes a day (and skipping days or even weeks will be fine—Anki will catch you up). If you are a student who is using Anki to cram for exams, you would probably do it differently.
I built up my deck over time. I make new cards while reading or watching videos. I made a bunch last week while watching WWDC.
In the podcast, I said to use a single deck with all of your cards mixed together. So, if in a few months, you read books in different subjects, you wouldn’t make separate decks for each book or subject. This makes it a lot easier to just make cards whenever you want without thinking about it too much. It also makes studying a kind of serendipity machine.
A couple of episodes ago, I had spoken about how to generate ideas by combining disparate knowledge. Going through an Anki session of uncategorized cards helps me do that regularly.
So, in my deck today, I was asked about:
The kinds of gates you find in QUIL quantum computing (I read Quantum Country this year which is a book with embedded spaced-repetition)
As I think it over, there is perhaps something interesting about the communication principles in C4, the communication goals of visual design generally, and Covey’s 7 Habits—specifically “Seek First to Understand”, which is the core communication habit.