Maybe it’s my age, but the Rocky Theme pumps me up. I always run harder when it comes up in my playlist. The music from Rocky makes me think of the training montage, and then I want to exercise.
When I read (especially on an airplane), I listen to ocean waves. Music would be a distraction, but hearing waves won’t make me think about them.
I do sometimes listen to music when I program. I once read a study that it can help when doing mundane, rote tasks. Uptempo music helps me—I like to use dance music. Sometimes I’ll just put a single song on repeat.
Right now, I am writing this blog post while listening to “Going the Distance” from Rocky and Rocky II. It’s what plays right after Adrian tells Rocky to win. It’s a little more low-key than the main fanfare and for me, it means that it’s time to get down to business. I think it’s fine when I am trying to get out the words for the first draft, but I’ll probably have to shut it off when I edit.
In all of these cases, I am trying to use sound in the way that movie soundtracks work—to enhance the foreground activity. It’s working in tandem, manipulating my emotions while I am engaged in something else.
I just finished a break where I traveled for four weeks to see family and friends in places I used to live (in NYC and New England). My intention was not to completely stop working, but that all of my projects would become much lower priority.
Here are some things that worked for me.
Banking content: I didn’t want to have to write every day and podcast every week, but I did want to keep the publishing schedule going. To do that, I pre-recorded five podcasts before I left and wrote many blog posts. I still wrote quite a bit during the break and did have to edit and post the podcasts, but it was much less work than normal.
Having a generation strategy: To make it a lot easier to make five podcasts in a couple of days, I did a four part series about lessons I learned from Art & Fear.
Lowering the bar: My goal in each podcast is to share something that is helping me in my writing with a clear takeaway. If I had that, I didn’t worry about the length.
Shutting off sometimes: Part of my trip was meant to be a real vacation, and during that time, I completely shut off.
Prioritizing relationships: I never turned down a chance to see my family or friends and made sure that my wife and I had plenty of time together as well. Everything else had to fit in between that.
Having fewer obligations: I do more projects alone or in partnerships that are trying to build modest businesses that can withstand me being away from it. My client work is more advisory and easy to schedule.
As I spoke about in my podcast, I did this exact same trip in 2021 and it completely derailed me. I did not set expectations correctly with a client and had to do a lot more work than I wanted to. I had to pare back everything to just work I was obligated to do and then kept that pattern for more than a year until I could get control again.
This time, using the strategies above, I was able to have the break I wanted and also keep projects going enough so that I could easily pick them back up when I returned.
I started using JIRA for issue tracking when I worked at Trello (at Atlassian), and I still use it now. JIRA does everything I need in managing software projects, but I never send people outside of my team to JIRA because it’s not easy for casual users. For that I use Trello.
I have a Trello board for each project I am managing that is meant to be a high-level summary of that project. It is useful for onboarding and getting its current status easily. It has links to JIRA, Confluence (for specifications), Atlas (for status) and Figma.
This Trello board is the first place I send a new team member to help with onboarding. If someone has a question in Slack about the project, I make sure that it was something you could find out on the board and then link them to it there. The board is a kind of dashboard and central hub of the project.
These hub boards are curated, so I don’t try to use any automations to bring things over. If I think you need more information, I send you directly to the source.
JIRA is useful to the people that work on the project every day. I use Trello for those that just check in weekly or monthly.
I just read Ben Thompson’s take on the Vision Pro, which is admittedly a gushing, glowing, overly optimistic take. But …. he’s actually tried one, so I am taking it seriously. One worry I had was whether the displays actually matched the demo, and it does seem that they do.
His conclusion is that the Vision Pro might be in the same product category as a Mac and if that’s true, the $3499 price isn’t that bad. I absolutely could see a world where you use this instead of a laptop, but probably not on day one because it won’t have the apps I need as a developer.
Even so, compared to a laptop, the biggest downside is travel—I value how thin and light my MacBook Air is, and this is certainly not thin. I can’t easily stick it in a backpack. I also can’t see using this in a café or shared work space.
But, that had me thinking that maybe it’s not a laptop replacement, but an external monitor replacement. I have been eyeing the Studio Display at $1599 and also the new Dell 6K displays at $3200. If a Vision Pro is a better display than those, I don’t need it do much more.
It does make me think I should definitely not just upgrade my monitor yet.
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.
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.
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.
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.
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.
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.
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
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.
