Author Archives: loufranco

Recommendation: Digital Zettelkasten by David Kadavy

I just bought and finished reading Digital Zettelkasten by David Kadavy. It’s a quick read and a good companion to How to Take Smart Notes, which I talked about in Write While True Episode 2: Small Bits of Writing and Write While True Episode 3: First Drafts.

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.

June 2021 Blog Roundup

I took a few weeks off to travel, see friends and family, and get some rest.

WWDC was in the beginning of June, so I wrote about that:

I also wrote about software process and testing

I also took a break from podcasting, but made these in June:

I expect to have an episode Monday on taking breaks.

Put Aggravation (and Joy!) in the Spreadsheet

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.

Write While True Episode 15: Combine Identities

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.

Transcript

Waterfall is a Myth

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.

This diagram comes from a 1970 paper called Managing the Development of Large Software Systems by Dr. Winston Royce. Right after this figure, he says: “I believe in this concept, but the implementation described above is risky and invites failure.”

Then he goes through a bunch of fixes to the process and ends up with:

The process as described seems completely reasonable to me (see the original paper) . It features

  • Code review
  • Automated tests
  • DevOps manuals
  • The idea of a spike implementation to learn and de-risk the real one
  • Including Customers in the process (every circle icon in the figure)

So, even in 1970, it was known that waterfall could never work, and the term was only coined later to describe Royce’s first diagram, which he had immediately rejected.

I think waterfall only really existed as a concept to immediately reject and fix, not a serious suggestion for what to do for a large software project.

Green, Refactor, Red

I’ve been doing more TDD lately (which is why I’ve been watching TDD debates), 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 do end the PR on the Green though.

Confession: I Estimate Using Time

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.

Write While True is a Prompt not a Companion

In March, I wrote this about the idea of a “companion” podcast that could be listened to while doing something (or learning something) related to what you were listening to:

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.

Tradeoffs in Unit Testing

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).

Building a Serendipity Machine

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)
  • The goals of visual design
  • A specific Typescript operator
  • Covey’s 7 Habits
  • The parts of C4

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.

I should write a note about that.