Links: Killing Abstraction - Developer Deconstruction
Why I’m Programming a Dog Food Machine From Scratch
Last week Anthropic released a jobs report that showed the currently rising rate in which AI is now automating jobs, and how that is expected to grow in the near future. Regardless of if you’re optimistic or pessimistic about AI taking your job, one thing I’m sure me and you can both agree on is not being able to turn on our computers or phones without seeing the latest news about which AI CEO is willing to bow the knee to the demands of the Pentagon, or how software engineering has been declared dead for the millionth time this week.
In typical Gen Z fashion, this has sparked a quiet rebellion inside of me, in a world where everything is being automated, I’m returning to technological first principles. Last year, this sent me down the rabbit hole of one of my computer science heroes, Ken Thompson. I learned the story behind why he invented the Unix operating system, co-authored the C programming language, and the career path he took that equipped him with the skills to do so after working on a failed AT&T operating system project known as project MULTIX, that had received funding from the U.S. government.
An article I read entitled, Why Abstraction will lead to the end of the world, the author makes the claim that in software, we continue to build abstractions to make working with the technology easier. While this is a great benefit for the advancement of technology, it comes at a steep price. As we rely more and `ages, and then to higher level programming languages), what happens is a smaller and smaller percentage of the population understands the details that the abstractions rely upon. As that knowledge gap grows, when something eventually breaks, there will be no-one left who knows how to fix it.
That article is hyperbolic in it’s claim about it leading to the end of the world, and this was made prior to the Chat GPT era of technology that we currently find ourselves in, but the point still remains. I don’t just want to create Chat GPT wrappers, as someone who has been a die hard Claude Code fan, something about the never ending cycle of prompting as the replacement for my everyday coding just sucks the soul out of software engineering for me. I want harship, I want adventure, I want to write code.
So in order to scratch this itch, I’ve been learning assembly, C, embedded systems programming, computer networking, and this week, I’m programming my own dog food dispenser using a 3D printer that I recently purchased, and programming it myself. First I had to research all the different softwares and electrical components that I would actually need in order to pull this off so I could get an idea about what it would cost me and how long it would take. I was able to purchase all of the components for ‘
Step one, I did some research online to find out what components I would even need in order to pull this off. Using Claude and some online Reddit forums, the first step was purchasing a ESP-32 micro controller. I have used Ardruino boards in the past but MAN, discovering the ESP-32 was a dream for me, it comes packed with bluetooth capabilities, wifi connectivity, and it only cost me about $30 for three of them! Next I purchased a step motor, bread boards, cables to connect the pins on the bread board, an electrical component to serve as the scale as well as a few other pieces.
I soon discovered that the ESP-32 needs a micro-usb data transfer compatible cable in order to work, now that most tech products I use have switched to usb-c, it had legitimately been years since I needed one, but after searching around I was able to find one, next came the programming. To get my feet wet, I started with a very simple test, turning the light switch on the ESP micro controller on and off, here’s a quick sample of the code that I ran:
The real meat and potatoes is in the void and loop functions, I’m currently in the process of integrating the step motor component as well, but for now let’s take a look at the first three lines. The #define is a preprocessor directive, which was new to me. I wondered, why not just use a good ol variable declaration? From what I could gather, since computers used to have much smaller memory, it was a way to keep your program file size smaller, a preprocessor directive is modified prior to the compiler even trying to understand your code, and (to use STEP_PIN as an example), every place where the directive exists is replaced with it’s value, so STEP_PIN becomes 26 in every location that it’s used. You still get the benefit of reusability, while saving some space in your program. Computer memory has improved significantly from the earlier days, that’s not a constraint for my dog feeder project, but it was helpful for me to understand the history behind preprocessor directives.
Then we have the setup() code, which does exactly what it sounds like, here I set some of the pins to active and print out some log messaging to myself so I can follow along with the program execution. Next is the loop function, which is essentially the main() execution for my dog feeder program, it just runs on continuous execution for the duration of the program. Then we have the dispenseFood function that get’s called by our loop function. Here is where I’m planning on testing the step motor to get it firing and then I can create a separate function to activate the step motor on command and thus dispense the food.
All in all, it didn’t take very long to get setup, after plugging the microcontroller into my Mac book, I just had to research a few things and I was able to get started. I’ve started assembling the micro controller to the breadboard so that I can integrate the step motor functionality, printing out the 3d parts, and assembling everything together, I’m looking forward to the finished design!