Many of my recent posts have been about ethics and Generative Artificial Intelligence, particularly where Large Language Models (LLMs) are concerned. They're about retaining humanity and ethics and personhood in a world that decreasingly values people, particularly when it comes to profit margins and returns on investment.

It might appear that I'm against AI. I am not. I am for respect and dignity and humanity. This post, therefore, will appear to be different from my latest writings.

This post talks about an experiment working with an AI to develop a well-engineered tool that is reliable, maintainable, understandable, and correct. This is about writing something that's boring. Beyond the Principle of Least Surprise, my goal was to make this feel quiet and stable and honest.

This is not a demonstration of programming wizardry, excellence in Bash development, or fanciness. I'm not here to show any of that. I have a passion for Bash and script development because shell scripts are often seen as a list of commands to be executed in order of appearance. Bash is not associated with serious development. In fact, when I've taught classes on Bash development to senior, experienced engineers, the most common reaction is that they had no idea Bash could do the things I was demonstrating.

So, this is about my journey in building a tool that I needed using a language that I enjoy with the principles I use to shape my professional practices.

The experiment had a few core ideas:

1. I didn't want to write a single line of code.
2. The deliverable had to be accessible quickly and without a lot of setup.
3. The engineering practices needed to be well-done.
4. Common AI-related problems needed to be avoided.
5. Whatever was written had to be reliable, safe, consistent, and boring.

I Didn't Want To Write Any Code

Right from the start, I took the position that I wouldn't write a single line of code. I would review code, answer questions about code, assert my opinions about code, and I would take ownership of code. For this experiment, I would not write a single line. I wanted the project to be pure and demonstrate what could be done, not how much I knew about Bash shell scripting. Besides, I have a book coming out shortly that teaches a style guide for Bash shell scripting.

The Deliverable Had To Be Immediately Useful

There are many projects on GitHub. Many of them have dependencies. There's nothing wrong with that in any way at all. Projects that avoid reinventing the wheel, writing new code that is already available elsewhere, code that has been seen and reviewed and tested and used by many people often benefits from that exposure in ways that bespoke code specific to a single project can't achieve. This is not about avoiding dependencies.

This is about building something that can be delivered in one step with one file that could be useful immediately on the barest and leanest of machines. This is another reason why I chose Bash instead of, for example, Python. In many ways, Python is a far better match to what I was doing here than Bash. The only problem with that is in order to run a Python program, Python needed to be installed. My program is about bootstrapping an environment. It's not a post-install tool. This is the tool that makes post-install tooling possible.

Bash exists almost everywhere. While some very, very lean systems don't install Bash during the operating system installation, I can think of no other language, tool, interpreter, that is more common on Linux, BSD, and UNIX-like systems than Bash.

Proving My Concept

I recently lost the hard drive on my favorite laptop. My data loss was minimal but the time and effort that went into tweaking that system was non-trivial.

Installing Ubuntu took a few minutes, as expected. Upon my first login, I cloned my dotfiles / home environment repository and I was pleased with being able to get started being productive sooner rather than later. However, I expected to start running into missing tools very quickly. For example, I use the GTK variant of Vim (gvim). The basic vim application was installed with the operating system; however, the moment I typed gvim and received a "command not found" error, I realized I had some work to do. I use containerized versions of a bunch of tools already; so, when basic parts of my workflows broke because neither Docker nor Podman were installed, my mindset was confirmed: I had a bunch of stuff to install.

I've found increasingly that tools I've used for years (decades) are no longer installed by default. Tools like telnet, for example. (Don't worry, I don't use telnet to connect to remote systems; I use it for interacting with local services and testing sockets) So, when I'm working away and telnet isn't installed, whois isn't installed, traceroute isn't installed... I have to stop what I'm doing and context-shift to addressing that problem instead of what I was working on previously.

So, rather than install tools and packages piecemeal and in a one-off fashion, I wanted a unified mechanism to install all of the things in one shot.

Therefore, my decision was to not install a single thing on the laptop manually. I told myself that I would only use a tool that I would build. This was to be that tool.

Posts in this Series

1. Bootstrap, an engineering exercise (part 1)
2. Bootstrap, an engineering exercise (intro)