Author Archives: Lou Franco

Review: Writing Down the Bones

My memories of reading Writing Down the Bones [amazon affiliate link] will always be tied to the beach. I read the book over several mornings on the Gulf Coast of Sarasota. It was early enough in the morning to beat the Florida-in-August heat, but late enough to let the truck rake the sand at the shoreline. I walked to the edge of the water, put my chair in the sand with my back to the sunrise, and settled in to read the wisdom of Natalie Goldberg. When I had about 50 pages left and didn’t have enough time to go out, I put my AirPods in and played some ocean sounds while I finished it.

Writing Down the Bones is a book about writing. It’s also a book about meditation. And, like many writing books, it’s a memoir. The three themes are intertwined in short, practical chapters that will get you writing.

It was written around the same time as Julia Cameron’s The Artist’s Way, more than 30 years ago. Like Cameron, Goldberg recommends that you “practice” writing. Her timed writing exercise is a lot like Cameron’s morning pages, and since Cameron wrote a foreword for this book, I’ve imagined them as lifelong friends and cross-influencers.

The main difference in their daily practice is that Goldberg recommends that the writing be directed. Like Goldberg, I have come to the conclusion that I should try to guide my pages a little more. She has a chapter with some suggested prompts. My favorite is to start with “I remember” and then just write what comes to mind. Whenever you get stuck, just repeat “I remember” and start again. I have used this idea often since I read it.

Goldberg uses the name “writing practice” for her timed writing exercise to evoke the “practice” of meditation. She draws comparisons between writing and meditation throughout the book. A through line of work is her accepting her guru’s attempts to convince her that writing was meditation. She is a much more serious practitioner than I am, but I have meditated regularly for more than five years, so these comparisons made sense to me. I consider my morning pages a kind-of meditation.

Another chapter, “The Action of a Sentence,” is a practical way to find good verbs. First she lists 10 random nouns. Then, she picks a vocation (in this case a Chef) and lists all the verb associated with it (chop, mince, slice, cut, taste, etc). Then she matches a noun, a verb and completes the thought. As a poet, these serendipitous combinations might go right into her work. For me, just expanding the list of verbs in my mind makes it possible to avoid adverbs and make verbs exert themselves to describe the scene.

I reread books like this every so often, so I am sure I’ll read it again in a few years. But, right now, I’m going through the book again and trying to figure out how I will keep it fresh in my mind as I continue to write. I was too enthralled to take good notes the first time.

Perhaps it’s a book I just need to consult more often. Pulling it off the shelf when I need a boost. Or maybe it will be my perennial beach read—with me when the waves remind me to flip through it again.

The James Bond Opening

I am building software to help onboard sales team new hires by helping them get to demo proficiency fast (if you are interested, here’s a 3 minute video of the DemoWizard).

One of the things we help our clients with is writing a compelling opening. My partner, Brian, calls this a “James Bond” opening. I’m not a salesperson, but I gave a ton of demos at Droplets and Atalasoft (both made developer tools)—I wish Brian had told me this back then, because I love this kind of opening.

Here’s how I try to explain it:

The beginning of a James Bond movie is actually the end of the previous (unmade) movie. We don’t know anything about the back-story of that movie, but now we get to watch the most exciting 10 minutes of it until it ends. Then, we start the next movie—the one we came to see. We know that at some point we’ll see an ending that topped the one we just saw, so we lean forward in anticipation.

For you, the opening is your best customer success story, but just the end. That customer already have a completely set up system, and they are already getting value from it. Start your demo by showing the part of the software that delivers that value and share their results (with permission of course).

Now that you have their attention, you can start your prospect’s story and help them understand how they will get from where they are now to an ending like the one they just saw.

Typing Out Art

I already wrote about how my typing teacher, Mrs. Cohen, was a genius for telling us (in 1983) that we needed to learn how to type to work with computers. Another thing she did was have us make pictures by typing. She’d read out of a book with instructions: “10 spaces”, “2 semi colons”, “30 periods”, “4 dollar signs”, etc, etc. It would take the whole class and then we’d get a picture of JFK.

This came to mind yesterday after I started a new meetup group for Sarasota Software Developers, and I had to come up with a banner image for the page. I was just going to use a photo of a sunrise with some palm trees, which definitely reads as “Sarasota”, but I also wanted it have some element of “Software Developer” in it. I was going to composite something together, but then I thought that someone must have made some kind of ASCII art generator. I was right.

I tried a bunch, and this one is the best: https://www.ascii-art-generator.org

Here’s what I made with it:

Green on black ASCII Art of palm trees at Benderson in Sarasota

It would have taken forever to type it out.

Don’t do Nothing and Be the Change You Seek

When I worked at Atlassian, we had five company values. The one that is most applicable to me outside of Atlassian is “Be the change you seek”. Even at Atlassian, in our slack, I probably reacted with our custom “Be the change” emoji annoyingly often. But, it wasn’t ironically—I loved that we (as a company and team) embraced the changes that people went out of their way to try to make. Co-CEO Scott Farquhar often started company Town Halls by telling new hires that they were hired to change Atlassian.

Before we were acquired, at Trello, we had a similar value we called “Don’t do Nothing”. It’s not exactly the same. “Be the change you seek” says that you should work hard to fix broken things you care about. “Don’t Do Nothing” was asking you to take a proportionate action to the problem, but not “nothing”—this could just be reporting it.

They both functioned in the same way with regards to who was responsible for improving the company—you were.

Write While True Episode 29: Loose Sentences

Last week, I spoke about something very fundamental—how to write complex sentences, and I’m going to continue along in that theme for what I’m now calling season three, drawing lessons from some of what I consider the greatest books about writing, and picking out ideas related to using words, sentences, and paragraphs. These are things that I’ve found that I need to work on, and I hope that that can help you too.

Transcript

Congratulations Rich Hickey

Rich Hickey, creator of Clojure, has announced his retirement from commercial software development. It looks like he’ll be still active in clojure development, but as an independent developer.

I met Rich in the 90’s when I took his Advanced C++ continuing education course at NYU. I was running a C development team, and we were adopting C++, so a few of us took the class. The most memorable part was the last few sessions where he described a GUI object-oriented design built around a dynamic object system (ala Self or Javascript) using his functor library.

The next 15 years of my career were dominated by C++ where my code was heavily influenced by what I learned in this class.

In 2007, when I saw his presentation at the NYC Lisp group, I reached out to see if he wanted to present to the Western MA Developer Group. Since Clojure was still relatively new, he was willing to come to present to us.

We had about 30-40 people there. One of our members, Chas Emerick, hosted the event. He went on to be a prolific contributor to the clojure ecosystem and co-author of O’Reilly’s Clojure Programming [amazon affiliate link] book.

I helped promote the event by writing my 20 Days of Clojure series. For the time, that was a lot of clojure content.

He came in March 2008 and blew the doors off with an elegant, concurrency-safe ant simulation:

Here is my original write-up of the meeting.

I still keep in touch with many of the developers that were there that day and we still talk about it. I can see the influence in their work.

The most important clojure code I wrote was the code I used to apply to FogCreek/Trello. They gated their application with a programming question, and I answered it in clojure because it looked like I would need something like a BigInteger in my answer, and clojure makes that easy. I also knew that the FogCreek/Trello team liked functional programming.

We might not all have adopted clojure (we opted for F# at Atalasoft and one of our engineers went on to become a Microsoft F# MVP), but our career trajectories were changed by that day when Rich opened our minds to what was possible with modern functional programming.

Thank you Rich and congratulations.

It’s Not the Ratio, It’s the Delta

I sometimes see a misconception regarding living in a high-cost vs. low-cost of living (HCOL v. LCOL) area. It goes something like this: “I make 2x more, but my expenses are 2x more, so it’s a wash.”

This is not true. If you make 50k and spend 30k, you save 20k. If you make 100k and spend 60k, you save 40k. Since increasing savings is the easiest way to change your future net worth, this is big deal. I started my career in NYC, so I know what this did to my savings account in my 20’s.

Just because you live in an HCOL area, doesn’t mean you have to have a high cost of living. I paired my NYC salary with a low rent (the 2023 equivalent of $900-$1,400) and no car, which are the easiest ways to save money in an HCOL.

Not all expenses are higher in an HCOL—mostly it’s housing and dining. Commuting (for me) was a lot cheaper. Other expenses, like travel, clothes, and “stuff” are pretty much the same where ever you live, so living in an HCOL means that you have more money to spend on those things. HCOL areas themselves are usually desirable travel destinations, and you can do that for free.

So, when planning where you live, if you are deciding between HCOL and LCOL, use the delta, not the ratio. Of course, if you can, working remotely and pairing an LCOL home with an HCOL job can give you the best delta.

30 Plants for Dinner

I saw this post about eating more plants from Mike Crittenden today. One suggestion is trying to hit 30 plants per week. As a vegan, I can get near 30 plants per day, but tonight I made a 3 course dinner for my wife and a neighbor.

  1. Vietnamese style raw spring rolls in rice paper with 2 dipping sauces (peanut and sweet & sour)
  2. Sesame Tofu and Brocolli over cold sesame noodles
  3. Mango Pudding with Coconut Cream Panna Cotta Style

Here is the list of plants we ate:

  1. Mint
  2. Cilantro
  3. Basil
  4. Spinach
  5. Soybeans (Tempeh and Tofu)
  6. Carrot
  7. Rice (in the rice paper and noodles)
  8. Peanut
  9. Garlic
  10. Ginger
  11. Wheat (flour)
  12. Shallot
  13. Black Pepper
  14. Sesame Seed
  15. Scallion
  16. Celery
  17. Lime
  18. Maple Syrup
  19. Serrano Pepper
  20. Brocolli
  21. Sugar
  22. Mango
  23. Coconut
  24. Vanilla

There was also vinegar, soy sauce, hoisin sauce, and sriracha used in the dips and glazes. I use very little oil (tofu was made in an air fryer), but there was a little bit of olive and grapeseed oil. I’m sure I got to 30 plants.

If I was going for 30 plant ingredients, I’d have just added some blueberries and allspice to the dessert, dredged the tofu in corn starch, and added a few more plants/spices to the main dish (peas, turmeric, cayenne pepper, grape tomatoes).

If you’re looking for plant variety, look for vegan recipes, but even if you eat meat, I agree with Mike that you should add more plants and varieties of plants, which is easy to do if you are going for it.

Be Happy When It’s Hard. Be Worried When It’s Easy.

When I was running product development for Atalasoft, I used to love it when a developer was having a hard time with a project. We sold image codecs, and our main competitor was open-source. Our secret sauce was that we could do things they wouldn’t. It was supposed to be hard.

If it were easy, everyone would do it, and it would be free. We wouldn’t have a business.

I think about this a lot when I see what people are doing with Large Language Models. Making an LLM isn’t easy, but Google thinks there’s no moat here for anyone. Still, it’s hard enough because it costs a lot of money, even if you know exactly how to do it.

The part that’s more concerning is what people who use LLM’s are saying. Everyone is so surprised how well it does with basically no work or skill on the part of the user. That’s fine, but then anyone could do it, and the thing they are doing with LLMs isn’t going to accrue value to them.

I think every knowledge worker should be using LLMs in some way, if only to learn about it. It offers enough benefits right now that it can’t be ignored. But, the easier it seems to be that you are getting good results, the more I would be concerned that you won’t be necessary to get those results in the future.

What Hardware Inspires Programming Language Design?

In early computing history, the government, academia, and industry collaborated to create languages for mainframes. The enduring ones were COBOL and Fortran.

You’d think that the PC era, when computing was delivering doublings in power every couple of years that it would also have been a time of programming language innovation. Aside from Microsoft, in the 70’s-2000’s, most of the PC companies didn’t do much here. IBM, Intel, AMD, Apple, Dell, HP, Sony, and Compaq made all the hardware, but contributed nothing to programming languages. Sun is the only hardware company that bucked this trend.

The photocopier, with Smalltalk, did more than the PC to drive programming language design than the PC. Fifty years of OO dominance followed.

But, for driving programming language development, nothing beats phones.

Telephone profits powered Bell Labs, which invented a lot of important tech, but some of the most enduring are the programming languages they developed. To limit it to just the ones I have used professionally, there are C, C++, Awk, KSH and the document processing languages troff, pic, and eqn. I’m probably leaving out about a dozen more.

AT&T was the most prolific converter of phone calls to programming languages, but Ericsson created Erlang, and Apple’s iPhone profits drove them to create Swift. You can give most of the credit for Kotlin to Android.

In the end, it’s probably money that does most of the work, and the real driver seems to be when it coalesces to a single winner.