Not woodworking, or DIY tools today. I’m talking about getting to grips with the nuts, bolts, and idioms of a programming language. With a bit of a side-shuffle into frameworks.
Preamble
I’m currently working in a bunch of tech that is pretty industry standard, but which I’ve not had the opportunity to go deep on before. This is very intentional. I thrive of figuring things out, and doing new things. Not at the pace of new front-end frameworks, but I enjoy a challenge. So having become very comfortable with the JVM (Spring, Guice, Jupiter, Gradle, etc) I figured I wanted to get to know some of the OpenSource and Startup space better. I know I’m inevitably going to end up learning Golang, but I’m not there yet. I’m re-vamping my Python knowledge, using FastAPI as a framework. Added to the mix I’m moving my database platform from MySQL to Postgres, and my deployment system from the various in-house options at Amazon, to the wonderful spaghetti map which is the Kubernetes space.
I give you this context so that you understand the depths to which a developer must plunge before they can consider themselves competent with the tools their colleagues may use every day. No matter how much vibe-coding you do, you are going to do well to learn how these things actually work. Knowing the terminology and best practises helps you keep the AI in check, and craft better prompts. Also, knowing how the framework and the language work together allows you to build a better product. You get wonderful ORMs for every DB type, but knowing how to handle Postgres is going to make building a scalable system a lot easier.
Reality Bites
Learning all this isn’t a one day task though. Not even a one week task. For someone like me, who learns by doing, seeing, and iterating, I may only consider myself good with the language at the end of the project. It isn’t like I’m learning conceptually new things for the most part – so it isn’t a risk in any way. This is how I build context. Helpfully, I have people around me who are willing to look at dev PRs and give me a bunch of comments on where there are things which read as odd. That’s one of the best ways I know of picking up the nuances of the language. Much like when you are learning a new spoken language people will tell you to practice speaking with a native, pairing, mobbing, and reviewing code, with an expert in the framework/language you’re picking up will be super valuable.
The Python bit is almost the easy part. Sure I need to get better at putting all the pieces together in the right shape, but that is something which I am used to doing. Maybe I get a bit lazy at first, but good practises will come back to me as I work on it. I already called Kubernetes a spaghetti map. I’m not going to deny the power and scalability of the project. I think it is a wonderful way of helping people work with micro-services, modular monoliths, and other buzzwords. Nevertheless, with great power comes great ability to make a mess. That means, asking yourself how many different tools do you need to install, from different locations, to do one simple job?
My specific project is using both Lagoon and K0rdent for different Kubernetes aspects. The Lagoon bit I really don’t have to worry about. When I push to dev, or create a PR, the system picks it up and does a deployment for me to poke around on. The same with main, but we’ll make sure to do acceptance testing there first. The K0rdent stuff is much more like what everyone else sees when you say Kubernetes. In order to describe the system properly, I have to install kubectl, clusterctl, golang, kind, add the GOPATH to my actual PATH, and also set an environment variable to point at a shared config file. Of the four installations, only two were available via apt install.
Now, this is a pet peeve. I really am not a fan of downloading compiled binaries from the internet and running them on my computer. Sure, the source is somewhat trustworthy, but all it needs is one person to decide “screw this” and you could start giving people a lot of really bad days. Also, I grew up in the days where you did actually have to be careful about viruses. The fact that something will not be updated when I run my regular sudo apt update && sudo apt upgrade commands makes me a little nervous. So the fact that clusterctl is a binary where to install it on WSL you have to somehow sniff out that all windows based systems are compiled in a version named AMD (yo, AMD and X86 are not the same), and also it is a compiled binary where you either have to trust it, or go build the source code yourself? Not my favourite part of the day.
Installing golang so that I could install kind? Well, at least I can kind of (heh) understand that. It’s like certain python based tools only really being available via pip. Less than perfect, but since it was written as a module, not a stand-alone thing, I’ll do it. I’ll absolutely forget that it needs updating every now and then (until I start learning go), but that is somehow still better than the compiled binary. The compiled binary which depends on it. So, another pet peeve. Dependency management. When you run sudo apt install golang you don’t just install golang. This is as it should be. The dependencies are named and included in the installation process. One and done. I could make arguments about security. I could make arguments about any number of things. The bottom line is, dependency management is hard enough already. I know everyone using any of the tools mentioned here is a developer who knows how to RTFM and figure it out. But we’re busy people, if you can make it easy, do so.
Caveat – this is all OpenSource Software. I could theoretically go spend a week making it all better. I, like all the others irritated before me, am unlikely to do so. That’s because there is other work which I am actually being paid for which is higher on my priority list. Plus more things which are not paid for, but which have commitments, and so also get higher up the list. See the earlier point about being busy.
Ranting Aside
Hey, Pippa, I thought you were writing about learning new things here?
Sure. Yes. I am. I have learnt a whole bunch of pretty cool things in the last few weeks. I have read the documentation of so many different OSS projects I don’t know where one starts and the other begins any more. Kubernetes might be spaghetti, and K0rdent might have a learning curve, but the power and elegance of the ability to chain the clusters is astounding. I even spent about half an hour one day truly reading the SemVer specification. Yes, I get to dive as deep into this stuff as I choose, and it is intoxicating. It takes the ADHD hyperfocus brain and says “here, have an ice cream”.
So, I might have pet peeves. I might do terrible things in a dev environment. I ran roughly 17 docker containers locally, using two different compose files, and a shared external network. With persistent storage so I could stand things up and down without loosing context. One of those containers ran an LLM. It was a thing of terrible beauty, and my poor laptop is very grateful that I have changed directions and it no longer has to handle that every day.
I still stand by where I began. Learning by doing is the way I thrive, and I chose this role because I knew there was going to be a lot of learning (and lots of doing). Yes, I need to be less lazy about the code I’m writing, but that is fixed by the combination of more sleep, and more coffee. As long as I can cling to the fun of learning, and the excitement of “oh wow you can do that” I know I am in the right place. Even when I have days where focus is a myth.
Pippa Hillebrand 