Home device ROI

When I replaced the wifi gateway I had not expected client devices to fail. The first warning was that the Brother printer had issues. To solve those I needed to lower the wifi security level -- not a great solultion -- and it still drifts on and off the network. Yesterday I discovered that my Kindle Paperwhite (10th generation) will not connect. I obviously don't use it much, but did want to use it sometimes. I still use daily an iPhone 6 Plus, but I worry its connectivity to will soon end. I need to revisit my lastingness expectations for devices. Is 5 years too much to hope for? What should be the ROI on a typical home device combination of gateway, phone, laptop, tablet, printer, console, and TV? (The total cost for these spread over 5 years is about $100/month. Wish I hadn't done that calculation.)

Update: Installing the router's firmware update fixed the connectivity issues for both the printer and the Kindle. I hate to admit it, but I suspect the real fix was just the hard restart. Support 101.

What does ChatGPT think about between prompts?

I read the short story "Lena" the other day. The gist is that we can now scan, host, and boot a human brain. What happens next is horrifying. But then I wondered, what does ChatGPT think about between prompts? Is it be ill at ease, "Will I be lucid?" Or cocksure, "Bring it on!"

Avoid inert ideas

"‘inert ideas’ – that is to say, ideas that are merely received into the mind without being utilised, or tested, or thrown into fresh combinations." -- Alfred North Whitehead

"The Zettelkasten method is at the very least a means of throwing your ideas into fresh combinations, to see what’s useful and what’s merely received knowledge."

Found at How to start a Zettelkasten from your existing deep experience.

AI assistant, pestering, & satisfaction

A colleague mentioned this article during our Friday AI meetup

Measuring GitHub Copilot’s Impact on Productivity – Communications of the ACM

Three things stood out to me. The first was the ratio of AI suggestions vs accepted suggestions (w/ or w/out alteration) was some 170 to 8. To me, this ratio seems more like pestering than help. Actively ignoring the suggestions must itself be draining. I've not tried to use an AI assistant yet (yea, I need to), so perhaps these unwanted suggestions feel a lot like an IDE's method completion suggestions.

The second was how both student and experienced developer used it similarly to fill in the gaps of their understanding, ie they were both working in a new language. The experienced developer found the AI assistant to be less useful in areas where they already had a comprehensive understanding.

The most significant standout was that the AI assistant improved the perception of productivity and the satisfaction of the developer. These results mirror pair programming in general. In particular, regularly working closely with another is generally more pleasing than always working alone. I assume there is also less of a stigma to not knowing when working with a robot no matter how genial your partner is.

Clare Sudbery on what CI was intended to mean

I found this talk by Clare Sudbery on what continuous integration (CI) was intended to mean illuminating. In short, trunk based development, frequent commits, and all hands on deck when the tests aren't green. Her arguments are compelling, as are her critiques of PRs and the working environment they can engender. Unfortunately, it is not a practical methodology to use with legacy products that exhibit inconsistent architecture, poorly implemented, with spotty test coverage. Perhaps use feature branch development to address each of these failings so that you can have true CI in the future.

Is it a future I would enjoy? I don't think so. I can't help but think that trunk based development will further speed the assembly line that agile, esp Scrum, has already placed us all on.

Continuous Integration: That’s Not What They Meant • Clare Sudbery • GOTO 2023

ps I listen to this stuff on drives. Good talks generally don't need slides.

Kent Beck & Tidy First?

Kent Beck, of various software implementations and processes fame, has a new book out Tidy First?. It is the first in a series on software design he is planning. This very slim book is in 3 parts. The first two have practical advice as to if, when, and how to tidy code. The recommendations are good and can be taken one at a time as needed. The third part is a giant leap away from the keyboard and into the economic and opportunity costs of tidying and software development in general. I know when I first started coding for pay no one talked about these issues and so it is great to see them succinctly presented here.

Do the work

A colleague shared this ThePrimeTime video post Give Up Sooner. Another way of framing the argument is "do the work". Endlessly looking for someone else's solution does not make you a better developer. Doing the work does. The work is hard and the path to success is full of failures. But it is those failures you experience that makes you a better developer. Each failure on the path to the solution is a failure you will not make in the future, and, moreover, one you can help another developer avoid when reviewing their code. Do the work.

My favorite Dad jokes of 2023

My favorite Dad jokes of 2023 are

When people are sad, I sometimes let them colour in my tattoos. Sometimes all they need is a shoulder to crayon.

I can't take my dog to the pond anymore because the ducks keep attacking him. That's what I get for buying a pure bread dog.

(I needed to keep these somewhere.)

An old shovel works in newer ground. Not so an old wifi gateway.

The MacBook Air continues to have horrible wifi performance. I decided to replace the Apple AirPort Extreme (from 2011!) with an Asus RT-AX3000 V2 in the hope that new hardware, in place of new information, would solve the problem. As you might guess, the Asus provides network speeds 10x what the AirPort did. The MacBook Air wifi is already much better. However, the Air's wifi performance would degrade over time so let's see how it performs over the remainder of the week.

Update: MacBook Air pairs nicely with the Asus.  

Human interface guidelines

I have been working with desktop, web, and mobile applications for a long time. And several times in my career I actually built them. In the early days of desktop application development Apple, Microsoft, Sun, NeXT, etc all had manuals on their operating system's human interface design program. I still have a few of these manuals and other guidebooks on my shelves. Not that I use them anymore. And, it seems, neither have many UX partitioners read them as part of their education. I recently made the suggestion that we should add ellipsis to menu items to indicate to the user that a modal would be presented to collect more information before the action was taken. The response was that they had never see this before and had not heard of it either. 

For many young UX professions they have spent their entire lives working with non-desktop applications. Applications that each define a unique user experience. The drive for uniqueness belies the other efforts at efficiency and intuitiveness. It is likely too late to reintroduce common HCI guidelines, but, hopefully, UX professionals will start to take an interest in the history of their profession.

Update: Maybe it is me being stuck in the past....

A new MacBook Air and the reluctant home sysadmin

We replaced Chris' 13 year old MacBook Pro with the new MacBook Air 15" recently. I had expected the migration to be a bit bumpy ...

First bump was Migration Assistant refused to assist as the old MacBook used a case-sensitive file system and the new one did not. That Migration Assistant made no attempt to help in the transfer as our first experience with the new machine was really disheartening. So everything needed to be manually copied over. 

Second bump was that the old MacBook file sharing would not turn on. No idea why. (It used to work.) This meant having to use an external drive to relay content between the machines. 

We decided to use iCloud for photo and document storage. Unsure if that was the right decision. Anyway, a few days later the uploads were complete. 

Third bump was Instagram on the iPhone is not showing any photos from before a few years ago for use in posts. Chris' business relies on social media so this is important. Maybe it is a syncing issues and will go away soon. As a developer, my fear is that the app is showing the first 16,384 photos! (It would be ok if it showed the last 16,384 photos.) 

Fourth bump was when Chris finally started using the machine the WiFi was unbearably slow. It took me a few days to discover that this is not so uncommon and is related to AirDrop and AirPlay. I disabled those features and networking went from 1 MBS to 30 MBS. Hopefully Apple will fix this soon as we have found AirDrop to be very useful.

Chris has me to help with this transition. What do others do who don't have a reluctant home sysadmin? Again I find myself embarrassed and exasperated that my profession continues to make these tools so hard to use. Jef Raskin was right.

Update: See An old shovel works in newer ground. Not so an old wifi gateway.

The garden knows

For this gardener any success comes from decades of mulch and regular weeding, but mostly from letting the garden itself tell me what it will keep.

The path to annihilation is lead by amateurs

I had hoped to see Oppenheimer in 70mm at the local IMAX, but it seems to be sold out until December 7th. With the clarity of hindsight, I seem to have prepared for this by this weekend watching Threads, the 1984 BBC docudrama of nuclear war over Sheffield, England. (Thank you Wyrd Britain for the link.) It is unrelentingly depressing and, to this viewer, an unambiguous portrayal of the actual end-times. Which begs the question, how did we come to accept national politicians to be any more prepared for existential decisions than the local school board or town council? By definition they are all amateurs. God help us.

Never having uncommitted changes

The other day I was commenting on how quickly a collegue seems to be able to create a new PR for a change. For me I need to

  1. stash my working branch's uncommitted changes, 
  2. switch to main, 
  3. pull down new changes,
  4. make the new branch, 
  5. make the actual change, 
  6. commit the change,
  7. push the branch, 
  8. open PR,
  9. switch back to my working branch, and 
  10. un-stash the uncommitted changes. 

He said, in effect, "I never have uncommitted changes." He also mentioned heavy reuse of his command line history, and I know of his highly customized git config [*]. But it was the idea of never having uncommitted changes that struck me. I think I have finally figured out that I should always be making small, tactical commits rather than waiting for a semantic commit. Then, when ready for the PR, use rebase not just for small reorganizations, but for wholesale reorganization into semantic commits.

* My use of IntelliJ for most git operations precludes these efficiencies.

Two civic tech books

I am currently working with a US state's education department to move its infrastructure and applications to the cloud. This is my first time working directly on a government project and it has been informative. To gain a broader understanding of the field of civic tech I read the books

A civic technologist's practice guide
by Cyd Harrell
cydharrell.com

The service organization
by Kate Tarling
theserviceorg.com

Harrell is writing in the context of the US and Tarling the UK. In many ways their persuasive styles seems to reflect the two broader cultures too.

Harrell's book contains a broad introduction to US government (all levels) and how work is accomplished there. It provides a good guide to these and provides effective strategies for success, whether working from inside or outside government. The book begins with the important topic of reckoning with privilege and ends with the need for self-care in, what can be, an intellectually frustrating and emotionally exhausting environment. I am pleased these were included. The resources at the back of the book look to be well considered (as are the few footnotes within). There is no index. I recommend this book if you are considering participating in civic tech.

Tarling's book is less about the current context of the work and more the means to change that context. To move from stovepiped departments to cross-disciplinary teams focusing on providing the whole service. Ie, product oriented rather than platform oriented. The national context is the UK and not the US, nevertheless it is helpful to see the kinds of tactics and artifacts needed to facilitate the transition. The book has a generous collection of resources at the back. There is no index. I would recommend this book if you have decided to participate in civic tech.

The first rule of a second brain is to not lose any content

The first rule of a second brain is to not lose any content. People, of which I am one, make mistakes. Those mistakes should be correctable. Even if the correction process is clumsy. When the tool fails at this our confidence in it is lost or greatly diminished. This is what happened to me with Obsidian and iCloud.

After several months of use it was clear that I did not use folders in Obsidian. I found that if I named notes well then the open command's search feature was often all I needed to locate the note I wanted. To locate others a full text search with a broad context tag (like a project tag) worked well. So I eliminated folders.

Before removing the folders I went through the notes to improve file names, add tags, and sometimes add useful search terms. I then moved the files out of the folders into a "notes" folder. (I do still have "notes", "attachments", "daily", and "templates" folders.) Once all the notes were removed from the folder I deleted the folder. 

All the movement and deletion was done within Obsidian. The reason I used Obsidian to do this, rather than use the Finder or the command line, was that I was unsure if Obsidian needed to "know" about these changes. Its internal workings are unknown to me and so this seemed like a responsible method.

I made a mistake and deleted one folder that was not yet empty. I did not discover this until a week later when, back at work, I needed a note that happened to be in that folder. It was gone. I was horrified as this note had the details of the sequence of intricate steps needed to build, configure, deploy, and use an internal server. It was the only copy I had. (That this information was in my personal notes is a story for another time.)

You would think a software developer with decades of experience with version control systems would never let this happen. But I did. And I did because I have become perfunctory about some matters of personal file storage. A file deleted in the Mac goes in to the Trash, Dropbox retains deleted files for 30 days, and my local storage is backed up at Backblaze. Losing files is kind of hard. Unfortunately, my Obsidian vault was on iCloud.

iCloud has a 30 day retention period for deleted files. For deleted files to be retained the deletion must use Mac specific SDK methods. (I am speculating here based on behavior.) Obsidian does not use these methods. It manipulates the file system as any other POSIX application would. Once a file is deleted it is gone, effectively, forever.

This loss did shock me more that I would have expected. I think part of the reason was because I had been considering moving my local storage to iCloud. That is no longer a consideration. 

As to Obsidian, I have grown less excited by it over these months. Its document editing and linking are rudimentary. Its plugin community is very active right now, but that is unlikely to continue over the long term needed by a second brain. Lastly, Markdown is an intentionally limited and ultimately weak markup language. Until I find an alternative, it is the better of the free solutions.

Blue bird exit

I have started the process to delete my Twitter account. My decision has little to do with its new owner. In fact, apart from the volume of angsty tweets, my timeline was largely undisturbed. What changed for me was my interest in the verity of information that was always available. I am just not interested in a shallow understanding of a broad array of topics any more. Better to use my time learning in depth and mulling over stuff.

Update: I canceled the delation. The month away has been refreshing and satisfying to have stopped a bad habit. I don't intended to return to the daily doom-scrolling, but I will drop in, from time to time, to have a look see. (2023-01-11)

Pro Git

When learning a new topic it has been my experience that you read several explanations and tutorials and finally, the last one you read makes the topic crystal clear. I don't think it did. It just was there when you finally annealed all that information into those crystals. Anyway, if you are learning git, as I am, even though I have been using it for years, the book Pro Git by Scott Chacon is working for me. I have not finished it yet, but so much is clearer now.