Day 6: Non Linear Engineering
Day 6 - 100 Days of Full Stack DevOps: The Non-Linear Engineer š ļø
Life is unpredictable. New ideas and projects come up. Projects stall. Everything we do is non-linear.
Iāve spent the last few weeks deep into defining and building a distributed configuration and infrastructure management system called Codru. While this may sound like a combination of ansible, chef, terraform or other tools, it isn’t. It’s a different thinking patern. Since it’s meant to be distributed and thus using the actor model I love from Elixir & Erlang. I’ll give more details and release the sourcecode in the future.
Inventing my own programming language
However when working on this project I realized I needed to build a custom DSL (Domain Specific Language). This is ANOTHER jump. As a software developer I’d jump right in, but this time I actually spent time and energy on reseraching other DSL’s and decided to embed a scripting language and extend it as it would proove to be easier. THe problem was that I have some specific requirements. I thought about using existing programming languages to avoid reinventing the wheel.
From a big list of many embeddable programming languages I was left with Lua, JavaScript, Tengo, Lua, Lisp , Janet and TCL, Scriggo. I wanted something which I could easily use in other projects and provide others with the capability of
THe biggest problems where that most of them do not have a builtin sandboxing system to limit resources and potentially dangerous actions. I wanted something in Pure golang to avoid CGO. The only 2 which have such a sandboxing system is Tengo pure GO and Tcl which is C based however someone made a transpiler from C to GO for Tcl.
The choice was difficult so instead I decided to write my own programming language. I mean how hard could it be? Right?
If Unix could be done in 3 weeks…
Ken Thompson said he was 3 weeks away from writing an operating system. 1 week for a editor, 1 week for a assembler to compile the code and 1 week for the OS itself, so Unix was born.
Luckily there are a few great resources including the free crafting interpreters which builds Lox in Java then in C and the books about writing a interpreter in go and then writing a compiler in go.
THe reason I took this detour was to actually have the power of BUILDING and extending my own DSL and programming language instead of fighting with exiting systems. Plus It would be awesome to extend it with the actor framework.
If things go haywire I can always to back to using Tengo which I can fork and modify to do my bidding. After acquiring the knowledge of how building a new scripting language works.
The codename for the new programming language is Zbor (fly/flying for romanian).
It wasn’t in my “original” schedule for these 100 days, but thatās the reality of engineering: the most valuable learning often happens during the “detours.”
20 Years, 10+ Languages, and a Lot of “Messy” Progress
If you look at my CV, you might see a linear progression. But if you look at my hard drive, youāll see plenty of unfinished projects or unreleased, experimental 3D models and games, cybersecurity labs, and experiments in over 10 different programming languages.
Iāve spent 20 years jumping between paradigms. Why? Because I refuse to fall for the Sunk Cost Fallacy.
A lot of people get stuck. They spend 5 years learning one tool, one cloud provider, or one language, and they become terrified to leave that “comfort zone” because of the time they’ve already invested. THe sunk cost fallacy is what keeps gamblers loosing money because they’ve already “invested”. Don’t become a “one-tool” engineer.
The danger? If you only have a hammer, you try to solve every infrastructure bottleneck by hitting it harder.
Thus, please, do dive into other tools, other operating systems and other programming languages. Don’t settle for one.
Enrich your “Technical Vocabulary”
Whether you are in DevOps, Backend developer or whatever, learning a new language or a “useless” side project enriches your vocabulary and knowledge.
- When I write Go today, Iām using the concurrency patterns I learned from Elixir/Erlang and the thinking from other programming languages such as Tcl which helped shape my thinking.
- When I design infrastructure, Iām using the “adversarial” mindset I learned from Cybersecurity.
- Even working on a 3D world taught me more about performance and memory management than any standard web tutorial ever could.
Why I Don’t Rely on “The Agent”
We are told that AI is the shortcut to everything. But thereās a massive trap here: Psychological Bias.
AI agents (LLMs) are built on the “average” of what has already been said. They provide the most common path, not necessarily the best one. They reinforce our thinking biases which is unfortunate.
If you rely solely on an agent, you aren’t researching; you are just mirroring.
Real engineering happens when you step away from the prompt and dive into the source code yourself. Researching things manually provides options that an agentālimited by its training dataācannot even “imagine.” It keeps your thinking sovereign.
š Perseverance vs. The Wisdom to Pivot
Perseverance is required to solve hard problems. But wisdom is knowing when to give up on a dead-end tool or a failing paradigm. Trust me, I was a big fan of Tcl for 10 years before I gave it up due to the fact that it wouldn’t get any traction in the real world. I did the same thing with Elixir due it’s adoption being very niche, even though it had much more of community.
Don’t be afraid of “Work in Progress” projects. They are the gym where you build the muscles for your next big success.
Codru and Zbor are the results of a thousand “unfinished” ideas from my past.
My advice for Day 6: Allow yourself the “detour.” Explore that obscure language you’ve heard about. Break your local environment. Don’t be a linear engineer in a non-linear world.
Stay curious. Stay messy. Stay sovereign.