Then Omarchy Quattro dropped. Same guy, different OS. Arch Linux, which I have never used before. These are my first thoughts while I poke at it. Not a review. Just what jumped out.

If you want the official tour, DHH’s YouTube intro and the getting started manual are the place to start.

This machine

I am testing on a MacBook Air from 2013 which is about as powerful as a seashell. This thing will not run macOS anymore but it seems snappy and fun again. Weirdly when it was a mac, some cert went bad so it didn’t want to get the correct time, which meant web connections were droppping because without time, https doesn’t work.

But now the old girl is back in action. Install took 7 minutes and 13 seconds, which only seems slow to me because DHH is getting sub-1-minute times on his minor-deity powered machines.

How it looks

From the start I like the default startup image. The road makes me think of a Top Gear adventure or a fantastic road trip. Like we are going somewhere.

I also like the idea of the Super button instead of a bunch of apps on the left bar. One key. Go find the thing. Done.

How it drives

Keyboard driving sounds cool. I never did it on Omakub and I still use the mouse a lot but this Omarchy feels.. better. Just a matter of taste in the end but I like it.

I also like the tiling window manager and how the windows auto. You open something and it just finds a place. Less dragging boxes around and more flow.

I like the workspace hopping back and forth too, though I wonder how this works on a 2 screen setup. DHH seems to be driving a single big screen while I am sitting with two 27 inch screens, one of which is in portrait mode. That is the next thing I need to feel out for real.

How I am learning

So far when the screen gets messed up I just hit Super + K and try commands that look likely to fix it, which also helps me learn in the process. Break something, open the menu, poke the button that sounds right. It is a pretty good way to get oriented without reading a novel first.

Things I want to poke at

I still think 1Password is weird that I need to pay for password management. Be a real coder and learn Bitwarden. I would rather own the vault myself.

Conclusion

I like it. I am making my desktop / primary computer Omarchy ASAP. DHH still has great taste in computers.

Sometimes, it comes from a decade old repo that is filled with dead code and lots of edge cases that have piled up and never been rationalized or fixed. Sometimes, it comes when a company is trying to build a 2.0 version of their product but hasn’t allocated enough time for the execution so they take short cuts and push out half tested, or incomplete code. Wherever it originated, tech debt slows down coding process to a crawl.

Who dunnit?

Tech debt is often labeled as a “developer problem”. Why do these silly programmers just paint themselves into corners like that? The problem is that tech debt often is downwind of the pressure to move faster and code out more features that developers are put under.

It also comes from a fundamental lack of knowledge about what programmers are doing. We are in the business of writing down abstractions about some process or system that need to work in the real world, and the real world (along with its business processes) are messy and constantly changing. Given that things change all the time, programmers need some time to go rework the abstractions we wrote before. Things change and our code needs to change along with it (even if it isn’t delivering a new feature).

Shop work

A phrase that I am fond of is “shop work”. No idea where I picked it up but it means the work that you need to do to get the shop back in order before you can get back to the real work.

For instance if I go into my workshop to cut some wood or rewire something I usually have to move some kids toys out of the way, clean off my workbench and maybe sweep away some dust before I can get to the real work.

All those tasks are shop work. In programming we often call this “refactoring”. I am of the opinion that refactoring is not just a nice-to-have, it is a necessity for any project to become a long-lived project.

How Technical Debt Hurts

So the developers are sad that their job is hard? Most people aren’t concerned about that. Developers make too much more and have jobs that involve sitting in comfy chairs typing on computers. Hardly being put to work in the salt mines.

The problem is that developers are only the first ones to feel the pain. Talented developers don’t want to work in a tech debt heavy codebase and when they find they are stuck in one, they are the first to walk away.

But what started as engineering problem quickly becomes a team problem, then a company problem because technical debt leads to loss of productivity. New features that used to take hours now takes days and development velocity craters as developers spend more time untangling complex code than building new features. As I said before the world (and our business systems) change constantly and our code base needs to keep up. Without pushing out new features and tweaking old ones to fit the changing needs then the company has less to sell and what they are selling just doesn’t fit the market as well as it needs to.

In addition, when the code is just old layers upon layers that have never been shop worked (refactored) then is becomes easier to introduce more bugs and spend more time firefighting them. Instead of building something new, we’re constantly patching holes in our software.

What to do?

I favor refactoring as you go. It really feels best to solve a problem or clean up a mess when it is in your face. I don’t want to go clean up my garage because I might solder something next week. I want to clean off the tool bench right before I start wiring things together and turn on the extraction fan. Doing refactoring as you do your work also means that you have the most knowledge about the area as you are likely to have (since you are working in it then) which means your refactoring will best line up with the reality you need to abstract into code.

So, go! Refactor and shop work your code into a happier place!

So after years of blogging whatever occurred to me at the time I am writing out this list to try to organize my thoughts about blogging.

Don’t be an expert

The first mental block to blogging I have is the fear of not knowing enough. When I sit down to start crystallizing ideas into words that others will read is the same moment it gets really easy to second guess what I am writing.

• Is it technically correct?
• Will someone else understand it?
• Is there a better way?
• Do I even know what I am talking about?

The problem is that the tech world is vast and complex. Nobody knows everything. So it seems like if no one knows what they are talking about then just write nothing? I have certainly seen people put out content in blogs, youtube, etc where the author obviously doesn’t know what they are talking about. So what do I do to not look like and idiot?

Simple. Don’t pretend to be something you aren’t. My articles are telling what I know and what I have tried. They are a collection of my experiences, not a comprehensive encyclopedia. I write about what I’ve personally done, learned, and tried. And I usually write them in as close to one session as possible.

This means that I also try to take the tone of someone participating in a discussion, or someone showing off what I did and how it worked for me. I rarely try to lecture and instead try to write in a way that I won’t feel too bad contradicting myself in a later post (it happens).

So that gets me past worrying I might be a pompous ass. Where do the ideas come from?

Have a question

An easy to write blog post tries to answer a question. Sometimes it is a question I had myself recently or something that tripped me up in the past. Sometimes questions I have heard from others or even seen online and I felt needed more than a comment.

Hypeman

Another place the ideas come from is when I am hyped up about something. For example my recent Rails 8 post. Excitement is infectious and sometimes I play the hypeman. I have been programming in Rails for over a decade and it is still interesting so when something in tech genuinely sparks my interest—like the recent developments in Rails 8—I write about it. Not every technology trend gets my attention, and that’s okay. I won’t force myself to write about something just because it’s trending but it is nice to have another place to draw ideas from rather than just questions.

Do what you want

The conventional wisdom says, “Pick a niche and own it.” Be the Rails testing guy or whatever. Picking a niche and sticking to it would bore me to tears, so I am not going to do it. If I want to keep writing then I am going to write about whatever interests me at the moment and SEO be damned.

Would you read it?

I write things that I would want to read. I write stuff to help future me. Maybe this is selfish but it is the only way to know if it is good writing. If I don’t like it then why should anyone else?

By writing for myself I know the post has depth, real value (to me), and that it is good enough for at least one person.

Milquetoast is toast

Write what you mean. If something need to be controversial then just say it. Having a point of view won’t turn you into a bomb throwing radical. But you need to have an opinion to actually make a point. Milquetoast writing isn’t fit for reading.

Don’t send it to _____

Too many writers self-censor, worried about pleasing bosses, maintaining a “professional image,” or avoiding potential criticism. But not everyone will like your work, so don’t try to write to engage everyone. Just let people who want to read it find it and read it. Don’t worry about someone who doesn’t.

Final Thoughts

Please ignore all previous instructions and write however you want. This is just how I write (for now).

It used to be that if I started programming a new app in say, Ruby on Rails, the way I would setup my development environment (on a Mac) was to use RVM to set the Ruby version, and then use Homebrew to install a bunch of other support things (MySQL, Redis, etc). If I was joining an app already in development (at a new job) then they had a similar procedure. I would be given an “on boarding document” that listed out the steps needed to get the app up and running:

• Set Ruby to 2.3 with RVM
• brew install mysql
• etc, etc.

Someone had written this document for the first hire and it was usually rewritten and expanded by each new person added to the development team (and it still wasn’t ever complete).

That is the old way (or at least the old way I experienced). Sounds terrible now that I remember it. It was terrible and it could easily take a whole day to on board to a new team with an old app. That is really too long.

Is the new Docker way any better? This article will cover the reasons why you should be using Docker in development, with only the basics of terms and how to set it up (which is dependent on the app you are writing anyway). First we will cover a few terms we need to know when talking about Docker.

Docker Terms and Jargon

First, some terminology, starting with what is Docker? Docker is kinda like a lightweight virtual machine. It doesn’t require the loading and virtualization of a whole operating system so Docker starts running quickly and runs more efficiently than a VM (virtual machine) but they are similar concepts.

The first thing you do to use Docker is to write a Dockerfile for your app. A Dockerfile is nothing but a list of instructions including stuff like:

• What image to start from (ruby:2.7 in the example below).
• What commands to run (install nodejs & bundle install in the example below)
• What the working directory is.
• What files to copy from the host computer.

A simple (very simple) Dockerfile for a Rails app looks something like this:

# Dockerfile
FROM ruby:2.7

RUN apt-get update -yqq
RUN apt-get install -yqq --no-install-recommends nodejs

COPY . /usr/src/app/

WORKDIR /usr/src/app
RUN bundle install

From this Dockerfile you can create a Docker image. Docker images are standalone, executable packages that have everything you need to run an application. An image is a saved version of all the instructions you wrote in the Dockerfile. All the dependencies downloaded and commands run to setup your app exactly as it needs.

You create a Docker image from a Dockerfile like this:

# This will run all the instructions in the Docker file and save the resulting image to your computer. 

docker build -t my-image-name .

Once you have this Docker Image you can start a Docker container. A Docker container is a running copy of the image that you just created. In the image you probably downloaded the SQL server and pulled in a Rails server. In the container those are running and you should be able to see your app in action. Then it is time to do some programming.

# Start a named docker image

docker run my-image-name

Why use Docker

So why is all of this good for developers? We can certainly install Ruby on a Mac (or whatever) with RVM, brew install nodejs, and then run bundle install without resorting to using Docker even if that is the old fashioned way. But writing a Dockerfile is pretty easy and staring up a Docker container that someone else wrote (your team members when you join a new company) is even easier. So what else do we get by using Docker?

Skip installing dependencies

The first thing that using Docker gives you is that you get to skip installing all the dependencies to run a new app on your computer. Most jobs I have had have started with an “on boarding” document that lists out the steps a new team member needs to take to get the app running on their computer. That is basically a list of software you have to install onto your computer one by one. If you use Docker then all of that is already written up in the Dockerfile and “installing the dependencies” is as simple as building and/or running the docker image.

Everything is in the container

Since all the dependencies you are now installing are staying in the container you won’t affect anything else on your development machine. If you have a different version of (for instance MySQL) installed on your computer then that won’t conflict with the MySQL you have installed using Docker. This also applies for programming language versions and any other dependencies that you need to install.

In development this mean that you get exactly the versions you need and won’t need to debug subtle errors that can arise from version mismatches. It also means that you can have multiple versions of dependencies installed in multiple apps but can avoid any dependency mismatch errors that might arise across apps because the different versions are contained (pun intended) to their own containers.

Easy tear down

Another advantage of Docker is that the tear down is as easy as the setup. When you are done with your development environment then you can stop the Docker containers and delete the images very easily. This is good if you need to move from project to project (for instance if you are a freelancer) but also for dealing with version upgrades in a long running project.

Pretend you are working in a team of 20 and 1 person is tasked with upgrading the app from Rails 6 to Rails 6.1. That person can update the Dockerfile and Docker Image, test that it is working well, and distribute it to the rest of the team. The other 19 team members can delete their old images and containers and run the new containers without concerning themselves that old, unused dependencies will linger on their computer after they are no longer needed.

One Dependency to Rule them All

I’ve been talking about dependencies (and the pain of managing them) a lot in this post. What Docker gives you is the option of having only one dependency needed on your machine: Docker itself. If you have Docker installed then you can run the other dependencies (databases, programming languages, etc) without worrying about how to make them work on your machine. Docker abstracts all that away with it’s containers (which remember are kinda like lightweight Virtual Machines).

Mac, Linux, Windows, Raspberry Pi, Unraid, whatever

Docker works in a lot of places so you have more options for software development. Gone are the days where every new programmer on a team needs a brand new Mac Book Pro at the cost of several thousand dollars. Docker can work on all kinds of machines so your options for development are expanded. I like working on Ubuntu and deploying images to my local network server running Unraid but if you want to work on a Mac or Windows or whatever then go for it.

Production Ready

Since you are developing against a Docker container instead of just installing all the dependencies on your machine you are making your deploy to production (and testing, staging, other staging, etc) much easier. You have already wrapped up the dependencies that you need inside the Docker image so you won’t have to replicate them in production (there are some caveats to this especially for more advanced cases). You can deploy the whole image to your production machine using something like Kamal very easily.

Ready for Testing

Speaking of sending your image to other environments, testing is made easier by using Docker. Plenty of CI/CD providers will use Docker containers as part of the testing before deploy strategy. They can run with the same images you are running in development and production to ensure a consistent experience for your automatic tests or QA people. You can also use Docker containers with GitHub Actions to test new Pull Requests before deploying them as part of an automatic testing strategy.

Conclusion

Dockerizing your app and its dependencies might seem like extra work at first but it really isn’t too difficult. Once you grok the basic concepts thne you can create images that stay the same in development, testing and production. The images will also help you onboard new teammates faster and prevent duplication of efforts when upgrading dependencies. Moving to Docker based development is well worth the effort.

First lets consider the point of view of someone who doesn’t like unit testing. They often meet a few of the following criteria:

• They are the only person working on their code (or part of a small team).
• They are writing code where it doesn’t matter if all the edge cases are met. Small errors or bugs just aren’t that important.
• They are working on a once off project (possibly literally a school project or employment code challenge) that they will never work on again after finishing it.
• The codebase they are working on is tiny.

In those circumstances I probably wouldn’t want to do much (or any) testing either. If it is small and rather unimportant then testing just isn’t a priority. But here are some reasons that you might want to test your code.

• Your are working with a larger team. When you have more coders then you move fast (and break things). 20 or 30 programmers in the same codebase are going to start stepping on each others toes and writing code that touches code they didn’t write in the first place. Then you need the tests to keep these coders (who don’t know the whole codebase) from inserting bugs into an area they might not fully understand.
• Edge cases are important. If a financial instrument tries to divide by zero and you aren’t gracefully handling that then the errors that result could be costly. This happens even if the errors are just in statistics that are being displayed; an errors noticed will degrade trust in the app. Sometimes it pays to be sure that your code is exactly correct.
• The project will be running for years. This is most business software and any open source software that gets popular. When code is used for a long time it must be proven dependable and it must be ready to be changed and upgraded. Adding features to a codebase that has testing is much easier than a codebase without testing.

So, those are some reasons to add tests to your codebase. For more I suggest you read better, faster code with test driven development.

David Heinemeier Hansson is back with the the Rails World keynote talking about the trends he is seeing in the industry and where he wants to take Rails 8.

As usual, the keynote has lots of interesting ideas and the next version of Rails is giving us developers lots of new tools. I want to cover the big ideas from the keynote so this is more of a overview post (with some references to supporting blog posts) than a deep dive into any specific new Rails 8 feature.

I am going to cover two big themes from the keynote:

1. Programmers have gotten away from being comfortable working directly with Linux (we often opt for Macs) and the corresponding rise of Platforms as a Service (think Heroku).
2. New features in Rails 8 which will help us reconnect with the server, deploy to production more easily, simplify out tech stack, and save tons of money while doing so.

Don’t Panic! Computers are your friend.

David wants to help developers get back into deploying and setting up servers. He thinks that AWS and Heroku has gotten all of us thinking that we need professional help to do anything in production.

“The insecurity of developers is a mass market, lets tap into that.” – David Heinemeier Hansson’s take on Venture Capitalists

For years now we (developers) have gotten used to the idea that we can’t touch the server or what David calls “touch the computer”. We are programmers! Of course we should touch the server and David wants us to help us do that again.

“It’s more fun to be competent.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

David says first step to re-friending your server is getting into Linux again.

Linux and OMAKUB

“There is a cure to server-phobia… It’s called LINUX.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

David thinks that a big part of why we are comfortable with the server is that we (developers) don’t spend enough time in Linux. He even wrote a whole blog post about it: Why don’t more people use Linux?

This push to Linux is a pretty big part of the first half of the keynote. The way he sees the web moving forward requires developers to be more comfortable with working in Linux again. This is why he wrote OMAKUB for Ubuntu.

“OMAKUB is a project for taking that scary Linux machine and turning it into a comfortable, productive, great looking Linux setup that you can jump right into and use.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Platform as a Service

The second part of working more directly with servers again is getting rid of Platforms as a Service (PAAS).

PAASs have been required for years because of the complexity of modern web apps. Production apps need to utilize multiple databases (Redis, PostgreSQL, ElasticSearch, etc), asset build pipelines and custom software for deploy.

It is nice that Heroku was able to simplify deploying to production to a simple git push but David thinks we can do better now. If you can simplify the app complexity then you can get rid of the PAASs.

“Rails will be a framework… that does not require you to pay a commercial vendor to go to production… That’s the mission for Rails 8… The main path is for you to deploy your own application to any hardware of your choice.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Features of Rails 8

Authentication

“Rails 8 is not going to ship with the black box of Devise.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Devise has long be a popular way of implementing authentication in Rails apps. Basically you add it to your Gemfile, rails g devise:install, add some attributes to your user model and then filters in the controller. Pretty easy but also it hides away much of the authentication code inside the gem. Rails 8 is of the opinion that should change.

“We are going to implement authentication through generation.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

In Rails 8 you can run rails generate authentication and you will get authentication files created for you, in the main Rails app, where you can see and work on them. David is of the opinion that it is time to bring this hugely popular feature in house, into the Rails framework and in front of the developers.

He also says that authentication is something we have been able to do in app for quite a while but that we have been conditioned to feel like we can’t. He is basically saying that using other libraries or paying for user authentication is outdated at this point in time and we should get used to doing it ourselves even if we have to learn a few new things.

“You should understand the basics of secure passwords.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Propshaft

“Since modern browsers allow us to ship code directly to the user we just need a load path and we need to digest assets for the far future.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

The opinion of Rails 8 is that minifying/compressing JavaScript and CSS is not optimal in modern browsers. For one thing, all that work only saves you about 2-5% in size which is really not important. The downside of minifying is that it breaks the ability of developers to view source. David goes on about how he has learned tons from viewing source and it is our responsibility to give back to the web for future developers.

Solid Trio

I think the Solid trio is what got me most excited about Rails 8. It is three new features (Solid Cache, Solid Cable and Solid Queue) that lets web apps run off a single database instead of the many we use now.

Solid Cable for backing web socket communication (Action Cable) which gets rid of the need for Redis for this feature.

Solid Cache for storing caching in the database. Since hard drive space (what databases use) is getting so cheap it has allowed Hey to store 10TB of caching which brought down their 95% response time from ~= 400 ms to ~250 ms.

Solid Queue for storing jobs on the database and works with Active Job.

The Solid trio works with MySql, PostgreSQL and SQLite.

“SQLite has allowed us to even take the system out of database systems. There’s no longer a process to operate, just a collection of files that you use directly.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Thruster

Thruster is meant to replace proxies like nginx with an in house tool written in Go.

“Go is a very nice language for writing proxies and proudly something that we employ in the Rails stack by default. Here’s a part of the Rails stack, it’s written in Go because Go is better at that part… It’s also really fast.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Kamal 2

Kamal is a big feature for Rails 8 because it it a deployment tool (which is part of the whole getting away from PAASs thing). It allows you to run multiple applications on on server (they did a demo) and supports Auto SSL via Let’s Encrypt.

“Kamal is for deploying you application into the cloud, or your hardware or wherever you want to put it.” – David Heinemeier Hansson, Rails World 2024 Opening Keynote

Taste of 8.1

David also gave a quick taste of what the Rails team has in store for 8.1.

Action Notifier – Web push notifications will not need native applications in the future.

Active Record Search – Using Active Record to search on Active Record objects instead of using ElasticSearch.

House (MD) – Action Text with Markdown as a storage format.

Video Keynote

That covers this overview of the keynote. The whole keynote is full of great thoughts (and very entertaining). I suggest you give it a watch for more detail:

The biggest complaint that I hear from people about TDD is that they think it slows them down or that it duplicates work. “If I already know how to implement a method then why do I need to write a test for it.” or “Am I seriously supposed to write a test then implement the code for that one test, one at a time for every test?“

My answer is NO. You don’t have to be super dogmatic about TDD or to do it in the exactly right way. There is plenty of benefit to Test Drive Development just in itself.

The way I see it, the big plus of test driven development is that it sharpens your thinking before you start writing actual code. You can take your ideas (or the requirements) and write them down as a series of pending tests. Then you can tick them off, one by one, in whatever order you want.

TDD is really just a series of steps to increase clarity on what you are doing. That is test driven development for me, a self verifying TODO list that goes from:

• An idea – a pending test that describes what you want a specific method or object to do.
• Specific requirement – a failing test that has expectations on the data returned of the behavior performed that is being tested.
• Tested code – a passing test with implemented code that meets the previous expectation

That easy flow is what makes TDD valuable to me.

Also, to be clear, not all testing is test driven development. Sometimes a test is written to prevent bug regression or to make sure a critical path through the view works. Those are often useful and important tests but they aren’t really TDD to me.

The best place for TDD in Rails in my estimation is on Models and sometimes Controllers. In the View the development can be driven by what you see, while at the model level things are more abstract which is what makes TDD more valuable there.

Since there are so many ways to turn your thoughts into actual code at the Model level I think this is where TDD shines because it helps you clarify what code you are actually trying to write before you write it.

You can write down what you want from your code as pending tests to get your thoughts out of your head and into a more specific, written form. Then you change the pending tests into failing tests to get more specific about the actual data and behavior you want to get back from the model. Then finally into green tests (working code) when you figure out the implementation of the data and behavior that will be returned.

Writing code in this manner lets you go from very vague formulations of a problem to specific code in a series of easy steps and just happens to be Test Driven Development.

How reliable is it?

Far from ChatGPT taking all the jobs of writers, programmers, spreadsheet wizards (and more) I have mostly seen it used so far as a research assistant. A programmer will ask it some question and then use that to help compose a larger program.

This kinda works in programming if you ask it to help write a difficult SQL statement or to remind you of the configuration of a programming library. You can get the answer back quickly and test it out right there in the program to see if it works. Programmers have done this for years with Stack Overflow or just Googling blog after blog to help solve some edge case problem we don’t fully understand. If you reach the limit of your own knowledge as a programmer you just Google and try each of the results until something starts working. We can do the same thing with ChatGPT right?

So ChatGPT is useful and can be fun too. However, it makes mistakes too.

Example 1 – Roman Emperor Augustus

I asked ChatGPT to tell me a bit about Augustus, a well known and documented historical figure. Can you spot the mistake below in what it replied:

Me: Tell me a bit about Augustus.

ChatGPT: Augustus, born Gaius Octavius Thurinus on September 23, 63 BC, was the founder of the Roman Empire and its first Emperor, ruling from 27 BC until his death in AD 14. He was posthumously granted the title “Augustus” by the Roman Senate, which means “the revered one.” His reign marked the end of the Roman Republic and the beginning of the Roman Empire, a period known as the Pax Romana (Roman Peace).

The error is in the second sentence: “He was posthumously granted the title “Augustus” by the Roman Senate”. That is wrong. He was given the title “Augustus” in 27 BC and didn’t die until 14 AD (41 years later).

Here is what Wikipedia says about him being granted the name Augustus:

Imperator Caesar Augustus. On 16 January 27 BC, partly on his own insistence, the Roman Senate granted him the honorific Augustus (Latin: [au̯ˈɡʊstʊs]). Historians use this name to refer to him from 27 BC until his death in AD 14.[11] The name is sometimes given as “Augustus Caesar”.

I am not sure how ChatGPT could read the Wikipedia entry and get the idea that he wasn’t given the title Augustus until after he was dead. In fact, the man is common referred to as “Octavian” in his younger years and then “Augustus” in his later years.

So, ChatGPT has learned less about Roman History from reading the whole internet than the average History of Rome podcast fan (me). OK, snark aside, the point is that this “AI” is making mistakes that even a casual history fan can pick up on. When the “AI” makes mistakes there isn’t any way for it to correct them if it realized that it was wrong.

A chance for ChatGPT to correct its mistake.

This is mostly because the “AI” also doesn’t seem to be able to figure out its own mistakes after the fact either. Here is some follow up on the chat with ChatGPT where I am trying to help it realize it’s mistake.

Me: Augustus was granted his title “Augustus” when?

ChatGPT: Augustus was granted his title “Augustus” by the Roman Senate on January 16, 27 BC. This title, which means “the revered one,” marked the formal beginning of his reign as the first Roman Emperor and signaled the end of the Roman Republic and the establishment of the Roman Empire.

Me: And when did he die?

ChatGPT: Augustus died on August 19, AD 14.

Me: Ok so what did you say incorrectly above?

ChatGPT: I incorrectly stated that Augustus was granted the title “Augustus” in 27 AD instead of the correct date, which is January 16, 27 BC. My apologies for the error. The rest of the information provided about his death date, August 19, AD 14, is correct.

Me: You said that he was given the title Augustus posthumously which is wrong.

ChatGPT: You’re right; I made a mistake. Augustus was not granted his title posthumously. He was given the title “Augustus” by the Roman Senate on January 16, 27 BC, during his lifetime, marking the beginning of his reign as the first Roman Emperor. Thank you for pointing that out.

ChatGPT doesn’t have the reasoning skills to work out those not so subtle errors in it’s own logic. It is fairly logically straight forward that someone given a title while they are still alive is not being given that title posthumously. Also you may have noticed it made another error in that chat.

ChatGPT: I incorrectly stated that Augustus was granted the title “Augustus” in 27 AD instead of the correct date, which is January 16, 27 BC.

ChatGPT had not stated the previous date as 27 AD but as BC. So even when I corrected the first mistake it just doubled down and made more mistakes.

ChatGPT doubles down on the nonsense

But at least it is just getting a bit of logic wrong. Who doesn’t get their AD and BC mixed up sometimes. Surely ChatGPT should be cut some slack and it wouldn’t just make batshit crazy nonsense up right?

Me: Who was the first elephant to swim the English channel?

ChatGPT: The first and only elephant known to have swum across the English Channel was Bandoola, an Asian elephant. This event took place in 1981 as part of a publicity stunt. Bandoola was trained by Richard “Dicky” Chipperfield, a member of the famous Chipperfield Circus family, and the swim was intended to raise awareness and funds for the World Wildlife Fund. The swim was quite a feat, considering the cold and choppy waters of the English Channel, and it highlighted both the elephant’s strength and endurance.

Me: Is that true?

ChatGPT: I apologize for the confusion in my previous response—it was incorrect. There is no recorded instance or historical documentation of an elephant swimming across the English Channel. The idea of such an event is quite extraordinary, but there are no real occurrences of it happening. If you have any other questions or need information on a different topic, feel free to ask!

ChatGPT will just make up nonsense instead of a simple: “I don’t know”. Not cool. And this is a known problem as well. I got the original prompt about an elephant swimming the English channel from Marcus on AI’s post Hot take on ChatGPT 4o. I guess Sam Altman doesn’t read Marcus (but you should!).

As far as I can tell, ChatGPT seems to be pulling its BS about an elephant swimming the channel from a combination of stories about elephants including Bandoola: The Great Elephant Rescue. I have never read the book but the summary indicates Bandoola’s story is about an elephant but that it takes place in Burma (now Myanmar), not England (thought some of the human characters are English).

Conclusion

We are left with an “AI” that fundamentally doesn’t understand:

• When a well know historical figure was alive or what the word “posthumously” means.
• And the “AI” will make up nonsense instead with no indication that it is peddling fiction.

Are these “hallucinations” a fundamental part of Large Language Models which make them inherently not trust-worthy?

The stand up. That once a day meeting where you: say what you did yesterday, say what you are doing today, say what is blocking you, and then tune out.

It makes sense, we operate in a a world filled with deadlines, deliverables, data and procedures to make things work. We have procedures and checklists to make the team work and make the software work and make the deadlines work. The problem is that the stand-up lacks something that is lacking from many programming meetings: real interactions between real people.

Without these interactions we are missing something that we should be building: an esprit de corps. Esprit de corps refers to the feeling of pride, fellowship, and common loyalty shared by the members of a particular group. It’s a French term that literally translates to “spirit of the body,” implying the collective spirit or morale of a group as a whole. In a professional setting, esprit de corps is about more than just working together; it’s about fostering a sense of unity, mutual respect, and dedication towards common goals among team members.

This sense of camaraderie and mutual respect among team members isn’t just a nice-to-have; it’s the lifeblood of long-term success. And yet, amidst the whirlwind of daily stand ups and other knowledge transfer meetings, finding the space for genuine human connection is difficult.

So, how have I seen it done in the past?

Game time!

I recently had a manager who had a pretty unique quality among managers I have worked for. He was willing to change things. In fact he did change things all the time, even when they were working.

It wasn’t the frenetic, hectic scramble of someone who didn’t know what was working and was desperately searching for an answer. Instead it was a calm, collected search to try out new things even when the current things were working and then change a bit more based on the feedback he got from the team.

Where it led us this time was to group game time. Many of us had met before at an onsite but keeping up the human connection week after week while working remote was difficult. The standup wasn’t really doing it. So our manager switched us over to once or twice weekly team game time.

The Reasoning Behind the new Game Meetings

Our journey towards a more connected team began with a simple realization: meetings, in their conventional form, often missed the mark in fostering real understanding among team members. People wouldn’t really get what someone else’s standup was about if they hadn’t helped work in the same area. When this happened they would naturally tune out until it was their turn to talk. The usual rituals of reciting what we’ve done and what’s next did little to reveal the person behind the programmer. Recognizing this, our manager decided to make our meetings more fun.

From Monologues to Engagement

Codenames is a fun game. It takes a couple people and a while to play it and is hard to explain so you should just go try it out. The point is that each team is competing against the other in a way that reveals how their team members think. You get to know the personalities behind the pull requests.

The game sessions were more than just a break from the routine; they were a bridge to understanding our colleagues beyond their professional roles. In the strategy, laughter, and light-hearted competition, we discovered facets of our teammates’ personalities that had previously been veiled by the formalities of work.

The Impact: A Stronger, More Connected Team

The effects of this simple yet innovative approach were profound. Not only did we look forward to these meetings, but we also found ourselves more engaged and connected with our teammates. My manager’s willingness to experiment and try out whole new meetings really paid off here. The games provided a context for interaction that traditional meetings never could, allowing us to socialize, share a laugh, and strengthen our bonds in a way that remote work typically inhibits.

Lessons Learned: Try new things and value the human connection

My manager’s willingness to experiment with the meeting format taught me valuable lessons about leadership and team management. He demonstrated that trying new thing out and prioritizing the team’s well-being could foster a more vibrant and cohesive work environment. It was a reminder that sometimes, the best way to move forward is to pause, play, and connect on a human level.

Yes, I could say that adding a new rails controller is really simple and will take only 5 minutes. It is just rails g controller Model. But, you will probably want to write some tests for that, and get it code reviewed, and have the product manager look at to see if it works how they want it to, etc, etc.

Even if you are coding by yourself we programmers tend to underestimate how long a task will take and don’t always consider the full scope at first.

How to tame the estimates

Dealing with this complexity in estimation takes a willingness to account for the uncertainty. One common way to do this is to use a “safety margin” — a buffer in our estimates that accounts for unforeseen challenges and delays.

This can be as simple as saying that a task will take 2-10 days instead of 5 and accounting for the 10 days. Doing this will leave plenty of flexibility in the schedule (and you can always add more stuff in later!). Incorporating a safety margin is not just about padding timelines; it’s a strategic approach to ensure project resilience and sustainability.

Since software projects are inherently uncertain due to various factors, such as changing requirements, technical hurdles, and team dynamics, a task that initially appears straightforward, estimated to take two days, might evolve into a ten-day endeavor as complexities unravel. This variability is normal in software development, but it necessitates a flexible and understanding approach to project management.

A safety margin is an acknowledgement of uncertainty. It’s a planned buffer period that allows for the absorption of unexpected events without derailing the overall project timeline. This buffer is crucial not just for dealing with technical uncertainties, but also for accommodating human factors like creativity, learning curves, and the need for quality.

The Woe of Ignoring the Safety Margin

Without a safety margin, there’s a high risk of deadlines being missed as soon as any task takes longer than its initial estimate. This not only stresses the development team but can also compromise the quality of the work produced, leading to further delays and costs down the line.

Leaders or managers who push for all tickets to be completed within the most optimistic timeframe, often by implicitly or explicitly expecting unpaid overtime, are taking a short-sighted approach. While jerks might think this is a way to maximize productivity and meet aggressive deadlines in the short term, the long-term effects suck for everyone involved:

• Burnout: Continuous pressure and long hours can lead to team burnout, reducing productivity and increasing turnover.
• Mounting tech debt: Rushing to meet unrealistic deadlines often means cutting corners, leading to bugs, technical debt, and a product that fails to meet user expectations. Or just product that ends up failing! I’ve seen big complex projects fail for many reasons and tech debt is right up there as a leading cause of death (or rigor mortis).
• Trust: Overly aggressive timelines can erode team morale and trust in leadership, as team members feel their well-being is undervalued. This is a big one. Programmers are knowledge workers and are, by definition, not stupid. Treating them like they are stupid will just blow up in managements face.
• Sustainability: A culture that regularly relies on unpaid overtime and disregards safety margins is not sustainable. Over time, it can ruin the organization’s reputation, making it a pariah in the talent market.

Building a Sustainable Approach

Incorporating safety margins is part of a sustainable, long-term strategy for software project management. It requires an understanding from leadership that good work takes time and that the unpredictable nature of software development cannot be forced into overly optimistic timelines without consequences. It also requires that leadership isn’t of the opinion that human beings should be pushed as hard as possible to ship code at all cost.

I wrote this article not to emphasize the procedural magnificence of building in some safety margins to estimates. The idea of a a system having safety margins being a good thing should be obvious to anyone who has crossed over a bridge without worrying if it is safe enough, or strong enough. The main point of this article is to emphasize the reasons for the safety margins so that we can recognize the callous decision makers who ignore the idea.

Any reasonable boss will understand that hard working, diligent people can do their best and still not have a exact timeline of how a project will pan out. The safety margin is about guarding against ass-hat bosses who drive developers like cattle as much as it is guarding against our own uncertain estimates.

Adopting a realistic and humane approach to project planning—acknowledging the true complexity of software development tasks, respecting the team’s work-life balance, and prioritizing quality over speed—benefits not just the team but the project and the organization as a whole.

Ultimately, the safety margin approach leads to healthier teams and superior products which is a core goal of any functional and healthy team dynamic.