Category Archives: Productivity

Making Sausage and Delivering Sausage

There’s an article about DevEx, a new developer productivity methodology, in ACM Queue. If you subscribe to the Pragmatic Engineer newsletter, there was an interview with the article’s authors last week. This is the latest methodology from the people behind DORA and SPACE.

DORA’s measurements were grounded in externally visible outcomes.

Deployment Frequency
Mean Time to Recovery
Change Failure Rate
Lead Time

The idea was to pick things that engineers could actually control.. Even though the elements of DORA are not directly translatable to business outcomes, they are still understandable to external stakeholders.

In SPACE, these metrics are still one kind that we collect, but SPACE also recognizes that there are other things besides Performance and Activity metrics (the P and A of SPACE). It also considers Satisfaction, Communication, and Efficiency, which are more internal to the team.

In DevEx, the emphasis is on internal metrics: Flow, Cognitive Load, and Feedback Loops.

I want to say upfront that I completely agree that these things do help engineers deliver software better and faster. But they are hard to share outside of the team. It’s how the sausage is made. The business ultimately needs to deliver sausage.

Aside from the rest of the business not understanding or caring about these metrics, I also worry that they will try to get too involved in them. Engineering leadership should care a great deal about the cognitive load of the members of their teams, and should work to lower it, but they need to find a better way to express that outside of engineering if they do.

I know the DevEx authors know this, and emphasis on these “making sausage” metrics doesn’t mean that they don’t also think externally visible performance isn’t important (they did after all design DORA and SPACE). But if you deliver on, for example, long flow states, but there isn’t more useful software on servers, you have failed in the business objective. This is the same thing I said about Story Points—they are too far removed from things people outside of engineering care about:

[…] regular people just translate [story points] 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.

To the extent that you report directly on DevEx, try to emphasize the parts outsiders can help with. Frequency of meetings and speed of external feedback loops (especially from product management) are good examples of that.

Co-working First Impressions

I started working remotely in 2013 and haven’t spent significant time in an office since then. When I went to Trello’s NYC office, it was mostly for offsites or to onboard a new team member, so I wasn’t planning on getting a lot of programming done. Even so, the Trello founders were highly influenced by Peopleware, and knew that company offices needed to provide a quiet working environment.

But, now that I’m working alone, I do miss having some interactivity with people during the day, so I am trying out a co-working space once a week. Today is my 2nd day.

Some random thoughts.

I am really glad I brought noise cancelling headphones. It’s just enough (along with listening to ocean sounds) to drown out the one-sided zoom meetings when I am trying to code or write (luckily, it seems to be somewhat rare).

Sitting by a window is nice. It’s on the third floor across the street from a residential neighborhood. All I see are shade trees, rooftops, and the big blue sky. At home, my window is on my left, slightly behind me. This gives me a place to stare to rest my eyes.

A view outside of a co-working office showing tree tops, rooftops, and the sky

The weather is hot enough for shorts and a t-shirt, but like everywhere else in Florida, when you get inside, they have the AC cranked up. I get to wear jeans, which I miss.

I thought I would miss my monitor more. They have a place to store one, and I was already planning to do that, but I’m getting a lot done right now without it. If that keeps up, I probably won’t bother.

Doing this on Mondays sets up the week well. I guarantee that I won’t have a meeting (because I am blocking the whole day). I would not have done that if I was working from home. Since I end each week with a plan for the next week, I can just get going when I get here.

They have regular and counter-height desks. You can stand at the latter.

Initial Thoughts on AI Assisted Programming

I’m fairly active on StackOverflow, so when people started answering questions by copy-pasting from ChatGPT, I noticed. Unlike the AI generated code shared on social media (which appears to be cherry-picked), in actual use, the ChatGPT answers were nonsense. And so, StackOverflow banned its use.

The problem was not that ChatGPT was generating nonsense — the problem was that people were posting the nonsense without vetting it. That’s partly because the answerers were not even trying (they thought it was fun), but also, I would guess that many of them didn’t know if the answer was good or not. The answers were obvious nonsense to experts, but less so to beginners or laypeople.

Right now, AI generated code can’t be used without an expert. But is it useful if you are an expert?

Two years ago, I said that I wanted a Robotic Pair Programmer. In that post, I made some suggestions for what I’d want:

One way that seems fruitful to me is rare API calls. There will be times when I am using an API that appears very infrequently in the corpus or my own repositories. In that case, it should infer that I probably need more help than usual and offer up a tutorial or the top Stack Overflow questions.

And …

Another trigger might be my new comments. If I comment before I code, then it should be interpreted as a search query:
// Parse the JSON I get back from the data task
That should bring up links to likely API classes in the help pane (just like it would if I already knew the class). Maybe offer up imports to auto-add. Maybe offer a snippet.

One important thing is that this needs to be just in the IDE, not a chat interface. And last March, GitHub Copilot was released as a VSCode plugin. I ignored it back then, but seeing how far ChatGPT had come made me think that Copilot had a chance of being good.

The best thing about Copilot is its UI. It feels like autocomplete, but offers up more than usual autocomplete would. Sometimes it can complete a line — sometimes it can give you a few lines. In either case, since IDE users are already used to this interaction, it doesn’t get in the way. It’s also fast, which is vital.

It also does the comment trigger I wanted — meaning, I can comment my intention it will offer up snippets. Many of these are useful.

One worry I had in 2021 was that a system like this would offer bad suggestions often. And, that’s the main drawback to Copilot. Much of what it suggests is wrong. Some of it is scarily accurate, and the rest is in-between — not right, but still helpful. After a few weeks with it, I can’t decide if this is the right balance. I haven’t felt the need to turn it off, but also, I’m not sure I’d miss it once it was gone.

My main reason for trying it out was that it feels obvious to me that this is the future of programming. I program mostly for myself, so I really want the productivity gain. It costs $100/year, and I think that’s a no-brainer, because it pays for itself pretty quickly in productivity gains. If you use VSCode and one of the languages it supports, I’d recommend trying it out.

In Praise of Pamphlets

One of the influential books in my life is A Technique for Producing Ideas by James Webb Young. I spoke about it at length in episode 13 of my podcast, where I called it a pamphlet.

I meant this in the sense of it being short and focussed. He doesn’t waste any of his 48 pages on background or fluff. It’s almost entirely about the technique.

I read a lot of (much longer) books in the same basic genre of this one — “A wise, old knowledge worker gives you their secret to doing knowledge work.” But probably because of the tyranny of the publishing industry, they have to be fleshed out to 300 pages, and so I have to read the same old Steve Jobs anecdotes again. Because pretty much any good idea about creativity, business, or productivity has a Steve Jobs anecdote.

We’re just lucky that Webb’s book predates Steve Jobs, but I don’t really remember him telling any anecdotes. There are no lessons from pseudo-science (or worse, non-reproducible, but compelling, real science). He is 100% betting that you don’t need to be convinced, or that the technique itself is convincing, and he rewards you by keeping it short.

Being American, I learned about the great patriotic pamphlets of the revolutionary era, like Common Sense, and so maybe I have a soft spot for this kind of work. In a way, maybe all pamphlets are common sense.

Introducing Page-o-Mat

As I mentioned in my post about recurring journals, I decided to write a python program to create a PDF that implemented my riff on the Da Capo journal. I finished it enough to share, and put it on GitHub. It’s called Page-o-Mat.

To make it more generally useful, instead of hard-coding this particular journal, I made it read a configuration file that can be used to describe lots of journaling styles.

Right now, the paper and page types are what I needed for my 2023 journal. I am about to do a test-run with getting it printed on LuLu. After that, I might make some more page templates.

The config file is in YAML. You could just list each page you want one-by-one, but to make things easier, there are a few ways to create enumerated pages.

Any page could have a count, which just repeats that page
Any page can have a variant list, which repeats the page, setting a variable that can be used in titles
Pages can have lists of sub-pages, and so on.
Pages can have sections

In the code, it’s implemented with nested loops and recursion. The indices of those loops are exposed to the config to use in date math, so that any section of any page can have a date calculated for it. Most journals would probably have sequential dates, but a recurring journal wants you to keep cycling back to the beginning of the book, so the date math is fairly complicated.

There are documented examples in the repo that (hopefully) explain this better. Start with daily.yaml, which is just a 365 page daily journal. 2023-recurring-journal.yaml shows the more complex example.

Recurring Journals

A few weeks ago, I backed a Kickstarter for a ”Day-based Journal”. The idea is that each spread of two pages represents a day of the month. For example, when you open it up, the left page has boxes for Jan 1, Feb 1, March 1, April 1, May 1, and June 1. The right-hand-side has July 1 … December 1. So, to journal in January, you turn pages for 31 days and then go back to page 1 to start February. You go back to page 1 to start March, and you can see each day in January and February as you progress.

This has two effects:

You see your notes over and over (this reminds me of spaced repetition)
You can see monthly progress and eventually a years worth of progress

I love the idea and hope it gets funded, but in the meantime, I’ve started designing a riff on this idea that I will probably print out for 2023 on LuLu.

As a prototype, I drew something similar to the Kickstarter for 62 pages of my current blank journal to cover the rest of the year (Sep-Dec).

Prototype of a recurring journal showing Sep 1, Oct 1 on left hand page and Nov 1 and Dec 1 on right hand page — Prototype of a recurring journal

Since that’s just four months, each box is much bigger — half a page each month to make up the two-page spread. For me, I think that’s the minimum size. I don’t think I could use the orignal Day-based journal as a primary way to journal, since I need space to do a time block for the day.

The next thing I noticed was that each day was a different day of the week. That is mentioned as a plus in the Kickstarter, but I think in weeks. So, for me, it would be much more useful if each day shown on the spread were the same day of the week. My Mondays are very different from my Fridays, and the weekend is nothing like a weekday.

So I started to sketch out what a 2023 Week-based ”Recurring” Journal might look like.

My solution so far is to run 2023 as 4 sets of 13 weeks. That’s 364 days, and since Jan 2 is a Monday (and I start my week on Mondays), I’ll treat Jan 1 as a special day and then make 2-page spreads for the rest of the year where each box is 13 weeks apart.

One downside is that they are not aligned to months or quarters, but that’s just the nature of weeks, and I want to embrace weeks. I decided to further sub-group the 13 weeks as 4, 4, and 5 week blocks. That’s almost a month, and while it’s not ideal that they are uneven, I am also embracing the 13, so I have to accept its primeness.

Also, you are only revisiting your notes every 13 weeks instead of every month. To address this there will be 28 summary pages with 13 boxes where you try to get the essence of the day. To get 13 equal sized boxes, I’ll borrow from Betsy Ross and just use horizontal stripes. I think this would be the best way to use the original Kickstarter journal.

I’m currently building a spreadsheet where I can plan out what each page of the journal will be. In addition to daily pages, there will be pages for planning and retros. I also want enough blank pages for random note taking. So far it’s over 300 pages.

When that’s done, I’m going to build a python script to generate the PDF for the interior pages. I will open-source it, so if you are interested, then watch this space.

Banking Blog Posts

Today is January 28th at 6:45pm. This blog post will be posted on February 10th at 10am.

This morning, I wrote a review of The Practice which published on February 9th. In that post, I mentioned that I published 30 posts in the last 30 days, but, I wrote those 30 posts in 19 days, and set them up to publish over 30 days.

Since I’ve been actively reading and writing notes, I have a big backlog of ideas and nascent writing. Blogging has been mostly about assembling these notes into posts, and banking them has taken all of the pressure off in trying to blog every day. With the pressure off, I sometimes write a couple of posts a day.

I have a few other tactics I use to make sure I publish every day, which I’ll post in the next few days (but I’ll write them right now).

Robotic Pair Programmers

If search engines ever get eclipsed, I think it will be by something in the environment that just brings things to your attention when you need them. I want this most when I code, like a pair programmer that just tells me stuff I need to know at exactly the right time.

When I’m in Xcode, there are so many times when I need information I don’t have. To get that information, I need to initiate a search. It breaks my flow to do this.

What I want is that information to just be in the environment.

One way this already happens with with code comments. In my source, I trust all of the editors, so I would like to see all of their comments and commit messages. This is actually possible if I turn on the Authors sidebar in Xcode.

But, what more could I get? Let’s say I index every Xcode project in GitHub, every iOS tutorial, every iOS question in Stack Overflow. Could that be distilled somehow and then shown to me at the right time?

One way that seems fruitful to me is rare API calls. There will be times when I am using an API that appears very infrequently in the corpus or my own repositories. In that case, it should infer that I probably need more help than usual and offer up a tutorial or the top Stack Overflow questions.

Another trigger might be my new comments. If I comment before I code, then it should be interpreted as a search query:

// Parse the JSON I get back from the data task

That should bring up links to likely API classes in the help pane (just like it would if I already knew the class). Maybe offer up imports to auto-add. Maybe offer a snippet. In Xcode it would be similar to the auto-suggested fixes for compiler errors.

This is just the beginning, and we can do a lot more. Whatever we do, we need to make sure that nearly every suggestion is useful, because we risk knocking the developer out of flow. Conserving flow should be the driver for how this works.

My Habit Totem for Daily Routines

In Environment Hacking, I wrote:

In [the Fogg Behavior Model], we add prompts to our environment for things we want to do more […] changing our environment to influence our own behavior. I have been thinking of “habit totems” I can put into the environment to prompt me.

So, in the past, when I’ve tried to institute daily startup and shutdown routines, it would fall apart eventually because I didn’t remember to do it. It was a partial habit at best.

So, this time, I designed a custom bookmark. I use them in my journal, my sketchbook, and any book I’m reading. Here it is (I got them made on VistaPrint):

The words under each routine are a short-hand. “Breathe” means meditate, which could be with the Breathe app on my watch, or any other way. “Practice” means to do my daily practice of coding, writing, and sketching. Hone is my yearly theme.

In practice, the biggest help is to remember to plan the next day. It only takes a few minutes, but makes all the difference.

I tried to think of something clever to put on the back of the bookmark, but I was so indecisive about it that I finally just stuck a photo I took of a Florida beach sunset and called it a day.

End Your Week with a Plan for Next Week

This is a follow up to my end-of-day tomorrow planning.

I run my weekly plan Monday-Sunday, so sometime on Sunday I’ll start to make my plan for the upcoming week.

The first thing I do is collect my WINS from my daily plans. At the end of each day, I tried to pick out something from the day that would bring me joy to reflect on later. Now (at the end of the week) is later.

Under that I put a BIG 3 checklist for the week. These are tasks I commit to do the following week. Each might take several days, so I need to break them down.

So, under that, I write the date of the next seven days on separate lines. I try to break down my Big 3 into tasks that need to be done each day that will eventually accomplish them. These will feed into my daily plans that week.

I’m not going to write a separate post for it, but I also have a monthly plan with a monthly Big 3 and biggest WINS. The entire thing rolls up to my yearly plan, which is a one-word theme and some high-level ideas of the kind of things I want to do that year. Months and years are not planned out as thoroughly as weeks and days—they are mostly a guideline to provide some direction.