The implication is that you’re fronting. It’s fine, I’m a technical founder of an AI company. The business demands that what you say is true. But for me, and many others, the joy of programming is in doing the programming. There is not a more outcome-driven modality that can bring us joy. And we either reject the premise or are grieving that it might eventually be true.
I've been a software dev for 27 years, professionally for 21 years.
This idea is getting the causality arrows backwards. I'm not talking up AI because I'm in AI - I'm in AI because I believe it is revolutionary. I've been involved in more fields than most software devs, I believe, from embedded programming to 3d to data to (now) AI - and the shift towards Data & AI has been an intentional transition to what I consider most important.
I have the great fortune of working in what I consider the most important field today.
> But for me, and many others, the joy of programming is in doing the programming. There is not a more outcome-driven modality that can bring us joy. And we either reject the premise or are grieving that it might eventually be true.
This is an interesting sentiment. I certainly share it to some extent, though as I've evolved over the years, I've chosen, somewhat on purpose, to focus more on outcomes than on the programming itself. Or at least, the low-level programming.
I'm actually pretty glad that I can focus on big picture nowadays - "what do I want to actually achieve" vs "how do I want to achieve it", which is still super technical btw, and let LLMs fill in the details (to the extent that they can).
Everyone can enjoy what they want, but learning how to use this year's favorite library for "get back an HTML source from a url and parse it" or "display a UI that lets a user pick a date" is not particularly interesting or challenging for me; those are details that I'd just as soon avoid. I prefer to focus on big picture stuff like "what is this function/class/file/whatever suppoed to be doing, what are the steps it should take", etc.
I can only hope that the tech stack for server-served apps will be much more sane in a couple of decades (for the developers of the future; it’ll be too late for me). We are really in a very bad place now in that regard.
I actually don’t agree. Maintaining or not maintaining backwards compatibility is often a decision made on the technical level, e.g. by a tech lead, or at least heavily based on the advice from technical people, who tend to prefer not being restricted by backwards compatibility over not breaking things for relying parties.
> Stillwell recalled distinctly the final meeting of the committee at which this recommendation was agreed upon. They were disposed to adopt 50 cycles, but American arc light carbons then available commercially did not give good results at that frequency and this was an important feature which led them to go higher. In response to a question from Stillwell as to the best frequencies for motors, Scott said, in effect, “Anything
between 6,000 alternations (50 Hz) and 8,000 alternations per minute (67 Hz).” Stillwell then suggested 60 cycles per second, and this was agreed to.
This reminds me of the concept of “user” as presented in the 1982 Tron movie, where users were regarded as sovereigns with god-like powers by the software (“programs”). The notion of “user” in the article is almost the reverse. We should return to that older conception.
reply