The cloudy layers of modern-day programming
vickiboykis.com
The cloudy layers of modern-day programming
1–10 of 177 posts
Re: The cloudy layers of modern-day programming
#2I suspect this effect is a big part of why Rust keeps winning the most loved language polls - because it has some of that old school programming vibe that got lost somewhere along the way
Re: The cloudy layers of modern-day programming
#3I don't really understand the problem, or maybe it's more, I don't think this problem exists as an existential one for more than the set of people for whom it's an existential probem.
Programming and software engineering and their subdomains and superdomains are no longer a priesthood or an academic exercise or playground for Levy-style oldskool hackers, or rather, no longer remotely those things exclusively.
Most of what most people who fit in the supercategory do is work. The specifics of the work vary. If they aren't the ones that give you joy, change categories is a good and readily available solution.
If you want to hack on beautiful code, there are 1000x more ways to do so today spanning the purely aesthetic defined as many ways as you like (live coding, avocational language design, exercises in new tricks for old tools like the demoscene and emulator worlds), to the aggressively useful (small tools made by small teams of solo devs upon which empires balance).
You don't need to be a mid-level IC at MassiveCorp unless you can't give up access to the mana-tap of massive scaling. In which case maybe that IS your thing and the complaint is flat.
The joy hasn't left. Maybe it's just harder for the author to find? Or the problem is simply that no matter what you do for work, it's work, "chase your bliss" being of course a lie, because work IS work, and dissatisfaction like water will always find its level.
Re: The cloudy layers of modern-day programming
#4oh yea.
using a software framework like django for "rapid application development" gives me a feeling closer to writing configuration files rather than actually "programming" (where "programming" is writing hardcore algorithms).
but don't get me wrong, I liked doing that, I got paid to do it. But let's call it for what it is: that python code (django app) was really django framework config.
this is a simlar phenomenon but worse, at least I could look around all of the actual code of the program for which I was writing configuration as code.
then, the thing about hardcore algorithms is that they need to be written once, and then everybody can use them. this is a giant problem. as I think about this, such hardcore algorithms are digital artifacts, so they are subject to the same problems all other digital artifacts (media, videos) are. a problem also known as software piracy. but software has been about composing proven algorithms together since day 1. the problem by this point is socio-economic. not technical.
I see the whole debate around "who will pay for critical infrastructure software" as another instance of "how should artists make money in the digital era".
But this comment (which I'm editing) is already at 0 points. somebody doesn't like what I'm trying to say, but I knew this already.
Re: The cloudy layers of modern-day programming
#5Would you rather do some library gluing, or reinvent a thousand wheels with every project? The latter is neat the first few times. Whatever your preference, your value as an engineer is much higher if you can glue. Imagine if a carpentry workshop gives a carpenter a fully-fledged set of industrial power tools, but the carpenter insists she can recreate all the other tools with just her whittling knife because it's in the 'true spirit of carpentry'.
Re: The cloudy layers of modern-day programming
#6It's very unclear to me why the writer ran everything through GCP and Colab. Having everything on a single environment with near-100% uptime is certainly still possible by renting a VPS, which is usually a much cheaper alternative anyways.
There's also many other alternatives that could be used if memory efficiency is the goal, e.g. polars/data.table instead of pandas, an OLAP database instead of bigquery etc. While I agree that pasting together configs is tedious and annoying, a lot of this type of work is due to developers themselves trying to replicate new trends at $bigco$ instead of optimizing for their own needs.
Re: The cloudy layers of modern-day programming
#7What scares me about ChatGPT is less so that I’ll lose my job (though it’s possible), but more so that I’ll be using language models to work at higher and higher levels of abstraction doing mainly configuration tweaking. Some of the particular pain points expressed in the article should be removed with AI in the loop development, but it’s another step away from “real programming”, which is what attracted most of us to this field. Yes, creating things is the end goal, but I’m terrified that I won’t be able to extract nearly as much joy when my job becomes largely prompting GPTn to swap out frameworks and UI paradigms for me like magic.
Re: The cloudy layers of modern-day programming
#8Loved this article! Yes, I think this accurately described 90% of my consulting engagements!
Re: The cloudy layers of modern-day programming
#9[deleted]
Re: The cloudy layers of modern-day programming
#10Would you rather do some library gluing, or reinvent a thousand wheels with every project? The latter is neat the first few times. Whatever your preference, your value as an engineer is much higher if you can glue. Imagine if a carpentry workshop gives a carpenter a fully-fledged set of industrial power tools, but the carpenter insists she can recreate all the other tools with just her whittling knife because it's in…
I'd rather re-invent some wheels. The problem with VendorOps as I see it is that quite often the vendored "solutions" aren't solutions: they do not meet the requirements! Yet … they sort of get like 20% of the way there, so they get adopted nonetheless, and the devs toil away on trying to get glue code to push it the remaining 80% of the way.
But if we had a system that we owned, then it could be adjusted to fit the requirements, elegantly. But we don't, so we can't.
The other problem is the "Ops" part: vendor owned systems are opaque AF, and when something goes wrong, impossible to debug. Then you become a support ticket monkey, praying you can convince the powers that be on the other end that a. it is truly their stuff that's broken, not yours and b. we pay for it, so yes, you should support it.
When a. or b. fails, then you end up writing yet more glue code to try to work around the bugs and outages that your vendor just doesn't give a shit about.