Note, this is not an ai generated post

I have RSI, so writing this entire blog post would have either destroyed my hands, or I could have done it the way that I did, which is that this entire article was written using voice-to-text and run through an AI grammar checker. Every single word on this page is something that I effectively wrote by saying it out loud. No AI was used to write the content; it was only used to add commas, periods, and break it into paragraphs where necessary. Yes it added em-dashes, yes I took them out. But trust me all these words were said by me out loud (And I typed some small sections).

Over the last three years, I have spent a lot of time with AI. At my previous job, it was part of my role to understand and assist others with AI, specifically AI coding tools. I’ve been running my own company as CTO for the last five months, and although by the end of my tenure at my previous job I wasn’t quite as bullish about AI, I think now I have a pretty solid opinion: you should not use AI for coding.

On Software Complexity and Architecture

There’s a lot of discussion around complexity in software architecture. There seem to be two camps: those who advocate for doing the simplest thing possible, and those who build systems with the intent to maintain them with large teams for many years. Each camp will tell you their way is the right way, but I actually thing they just have different goals.

Learning Levels and the Dunning-Kruger Effect

I’m fond of this model of learning and skill aquisition. I can’t find a formal name, and I heard it casually in conversation. It appears to combine the Dryfus model of skill aquisition with the four stages of competence. Anyway it goes something like this:

My Thoughts on Rust After Starting My Startup

I’m about two and a half months into starting a startup, and during that time, I’ve produced around 45,000 lines of Rust code. While AI initially seemed like it could help speed things up, I quickly realized that it caused more issues than it solved. These days, I only use it for repetitive, boilerplate work—things like reproducing patterns across many similar objects. The majority of the architecture and implementation has been entirely my own, but technically, I didn’t write all of it myself.

AI Coding, a rough introduction

My journey in programming with language models started in the ChatGPT-3 days, when it wouldn’t even produce correct syntax. Version 3.5 brought some interesting developments, where I actually felt like it could produce code that ran, but was otherwise pretty much useless. For a good while—speaking in months, not years—AI would mostly attempt to use libraries that didn’t exist, methods that didn’t exist on real libraries, and wrap all complicated functionality in places that didn’t actually exist. It took quite a while for language models to become hypothetically useful, and even after they did, they were still not great.

Finding the Balance Between Cloud Services, Local Hardware, and Software Design

I’ve been thinking a lot about minimalism lately—not just in architecture, but in software development and design too. I don’t have all the answers, but some experiences and things I’ve read have got me thinking. So I wanted to share my thoughts on the whole cloud vs. local hardware debate and how software design choices play into this, especially when considering company size and growth.

Why talk about this?

A lot has been talked about regarding large language models. Large language models aren’t necessarily the best thing with regards to training and search engine replacement, but I have found a pretty good niche use for them that I actually really find very useful.

Some real advice?

The large language model hype is starting to die down, and a lot of the advice looks pretty much the same. Use it to review things, use it to summarize things, use it to help your grammar, blah blah blah. All of that is pretty obvious at this point.

Forewarning about A.I.

A portion of this article was written by Chat GPT-4. Those sections are clearly outlined. Every other word outside of those clearly marked sections was written 100% by me.

My early days of using VIM

I was taught vim in college, because I was part of the college of engineering’s IT support staff. I learned how to use all the old school tools like vim, and Linux, and the command line, etc. Since my programming classes primarily used Linux, and they supported our use of vim, I use it very heavily early on in my career.

My blog is about 4 years old, because of this, some of my oldest posts that held opinions of mind might be out of date. I have new thoughts and new ways of describing my old thoughts.

This post talks about something I’ve written in-depth about before. If you want to see the full 6 part series (Yikes!), you can start here:

1. Part 0: The intro

But that isn’t needed to understand this post. This post stands on its own. If this post intrigues you, feel free to check out the 6 part series.

Why are you talking about this?

I’m not a prolific blogger, but when I get that itch to write something down, I put it here. Today I want to talk about memory safety, Rust, C++, and other languages that compare themselves to the C family of languages in speed and development type.

In short, I’m talking about this because it’s on my mind.

What’s the deal?

Rust advertised itself as being a new programming language that was fast and efficient. It wowed people with abstractions that optimized down to speedy code. But many languages can claim to have these features, Rust was different in a more fundamental day. The ownership and borrowing nature of Rust allowed the compiler, with it’s borrow checker, to ensure that you, the programmer, won’t have certain fundamental memory problems if you pass the compiler checks.