> Knowledge comes basically from manual trial/error almost daily.

This is the important statement, although I'd swap the word "knowledge" for "experience" here. You can gain "knowledge" from books, but only trial & error will give you experience to know "which" knowledge to use in which situations.

And what's important about this in the context of working with AI is the "error" part.

You have to experience errors to become truly experienced. And part of the experience is to recognize when you're about to make an error - to avoid it.

AI-driven processes mess up our natural trial & error learning curve in multiple ways:

- the AI push forces us to ship features faster (cause if we don't, our competitors will), reviews are sloppier, we discover errors later on, the feedback loop gets longer...

- using AI to debug and fix errors means we spend less time understanding what the error was about, which means we learn less about how to avoid the error in the first place...

- AI itself sounds overly confident, so reading its outputs without previous experience you may be less likely to recognize when it's making an error, which makes it harder for you to recognize when you're making an error trusting it...

On the other hand, this last point I tried to make is also why I don't think avoiding AI completely is a good strategy. Whether we like it or not, AI is becoming a part of developer's workflow. And as such, we also need to learn the trial & error process of using AI - what makes AI make errors and how to prompt it to avoid that.

Multiplication is elementary school math which doesn't require any thinking and the learned approach is simple. You can't really compare the simple stuff that's taught to kids, like basic multiplication or riding a bike with stuff that requires domain-specific knowledge and experience.

Think more stuff like "find the angle of lines defined by (x-4y-1=0) and (x-y-2=0)", "write the number 2026 in base 7", "solve an equation sin^2(x) - sin(x) = 0".

I plucked these from our country's high school final exam from this year. Back when I was in high school, I did mine in 60 minutes without an error when the time limit is 150 minutes and I intuitively immediately knew how to approach each task since the moment I saw it. Also all needed formulas are supplied, you don't need to remember any of them.

I plucked these because for these I don't have the immediate "know how" now, I still understand the topics, and could solve them with enough time, but it would require some thinking and thus I would be slower at solving them than when I was in high school, even though I'm pretty sure I could still ace it in the 150 minute time limit.

But reality goes beyond high schoool... College-level math, like derivations/integrations, sums, algebraic proofs, is even harder and solving some of them could take me hours when I could do them in minutes when I was in college.

With code it's the same. I could solve simple Python/Pascal/C++ high school level tasks as fast or faster than when I was in high school, even if I didn't write any code for a couple of years. But we also had assembly class in college, and I would struggle at assembly if I had to code it now, 10+ years later, even though I didn't struggle with it back then.

> Think more stuff like "find the angle of lines defined by (x-4y-1=0) and (x-y-2=0)", "write the number 2026 in base 7", "solve an equation sin^2(x) - sin(x) = 0".

> I plucked these from our country's high school final exam from this year. Back when I was in high school, I did mine in 60 minutes without an error when the time limit is 150 minutes and I intuitively immediately knew how to approach each task since the moment I saw it. Also all needed formulas are supplied, you don't need to remember any of them.

It seems like with just a little bit of doing it again, you'd be back at the level you were though. Especially if you can do it with formulas right. You would be slower for only a very short amount of time. All those things are in my view if you understood them at some point in your life, you will understand them to the exact same extent with just a little bit of reminding. I would say with most of those concepts, it would take less than 1 hour to be back at similar level. Like for instance number in another base etc.

Depends on the complexity of the task. That's what I tried to hint at by also mentioning college-level math. For the high-school level tasks yeah, couple of hours and I'd be as fast as I was in high school again. For the number in another base it could be as quick as less than 1 hour as again that's a simpler task than the other two.

For derivations/integrations it'd take more time. Less than what it took me to learn them in the first place, for sure. But still a lot more than 1 hour.

Cause I forgot how to "do them" in the first place, which is what the discussion was about in the first place. I still know the "theory" behind, so I can "figure it out" if needed without needing anyone to "instruct" me, or needing "classes" to learn how to do them. But essentially all the "practice" I had back then is forgotten.

And again the same goes for code and technology knowledge, which is what the discussion was about in the first place.

As a senior developer with 10+ years of experience I've already encountered situations where I needed knowledge I knew I had at some point, but already forgot. In my case as a backend developer working for the same company for 5+ years my favorite example is payments processing. There are tons of special/edge cases - e.g. how a failed recurring payment during a subscription is processed. That's something you set up once, then don't touch for years, and suddenly need to study again if a change is needed. How a subscription goes "past due", what you can do in that case, what your code actually does, how it reverts to correct state once a retried payment follows through, what options you offer a customer if his payment method expired and he wants to switch it, ...

And this is also a good example why "domain knowledge" and "code ownership" is a good thing in larger companies. Because under usual circumstances I don't have to deal with these, cause we have a dedicated person who's maintaining the payment-related code. I only fill in in urgent cases happening when he's on vacation.

And juniors designing stuff like this AI-first without properly thinking about all these cases won't learn all the edge cases this flow can contain. So if something goes wrong, you end up with nobody who has the "maintainer experience" for that code - you don't have the one person who is knowledgeable about that topic - everyone in your company is in the same spot as me - having to research the topics again to understand them enough to be able to debug the incident which happened.

This pretty much. It's very hard to forgot theory, especially if it was hard-learned with lots of practice. But enough time spent away from the doing, and the details starts to blur and the only things is the intuition behind those things and a general sense of how it's done.

But with computer programs, the devils is in those details, so even if you're a senior designing the whole service, you either have someone on staff that's responsible for the implementation gotchas or you have to got familiar with them.

AI does not hold itself accountable for anything.

For me AI mostly reduces time effort. AI types code faster than I do, looks up stuff on the internet faster than I do, debugs faster than I do, but doing those never required much "brain effort" from me.

What does require "brain effort" from me is making educated decisions. Mostly during planning to figure out which pros/cons of each possible approach are actually relevant for our situation - AI does this poorly, makes lots of wrong assumptions if you don't steer it correctly, and noticing these + correcting AI on them requires "brain effort" too. Then the part of code review where you think about what can go wrong. AI still sucks at figuring out edge cases. It doesn't "know" the entire codebase like I do, its context only has "the parts of codebase deemed relevant".

Before AI I could jump from 30 minutes of hard thinking into an hour of coding during which my brain essentially rested, before returning to hard thinking again. Nowadays those hour-long coding sessions turn into 5-10 minutes of watching AI do something.

So for me using AI doesn't "free up brain juice", it instead makes me use my "brain effort" more, and in a workplace environment gives me less time to rest and makes me more tired, cause nowadays bosses expect us to work faster + colleagues working faster means more review requests.

I hear sentiments about farming from lots of burnout software developers.

I always wonder what made them become developers at all. Cause my primary motivation for selecting a job was that I explicitly didn't want to ever work manually, I knew that since early childhood and it still didn't change even after 2 burnouts. My secondary motivation was that I liked working with machinery/computers.

Also when I started coding, it immediately felt like my passion. And the thing I love most about coding is that mostly all changes I make have instantly visible results. I couldn't imagine working a job where I had to plant a seed and then wait a week to see if it sprouts.

Also what I love about development is that with modern Docker/Kubernetes setups you can make the environment where your code runs pretty predictable. And with proper backups configured and backup restore testing you aren't really worried about losing the stuff you worked on for months. Meanwhile while farming you can't predict how much sun is gonna shine or how much rain you're gonna get. And you can't prepare for natural disasters which can come anytime and ruin your crops.

So I wonder if it's all just people who never loved software engineering and just went into it for money, and now that they have money after years of working they start looking for their true passion.

I'd say it might be due to external factors such as a bad working environment

Someone who originally has coding as their passion, for example, might eventually come to dislike it due to overwork. And in doing so they overcompensate by imagining that the total opposite of office work, e.g. farming, would be a better way of life, even though it may not necessarily be true

That said, I think something like a week long course of farming targeted towards white collar workers, with all of the "fun and refreshing" parts but only educational exposure to the painful parts would be a great business idea (or maybe something like that already exists somewhere)

Personally I love a lot about software engineering (iterative problem solving, sorting through complexities, the predictability you mention or at least how things are logical and often deterministic, etc) but I also love being outside and moving my body. After years of sitting behind a computer all day I do day dream about work that fulfills me in other ways. I'm sure if I took a different job and spent all day in the field I would miss software in a similar vein; time is finite and the number of possible ways you can spend it is not.

I got into software because being an introvert, I always had trouble dealing with people and here were computers that always unquestioningly and faithfully obeyed all commands and that level of control always appealed to me.

Yet I like planting stuff and gardening as well - why? I think it's a side effect of growing up with parents and grandparents who did that sort of thing as a hobby and I feel it's a bit of a comfort zone for me.

Agree. My neighbour is too old to farm and his descendants aren't interested. He has offered to let me use his land for free but I just can’t get interested. Even just taking care of a few potted plants is too much for me.

I'm someone who started programming when I was in middle school and went into this career field for the passion. But my passion was and is programming, not corporate office work.

In my career so far, I've spent most of my time troubleshooting AWS configs, combing through cloudwatch logs, and wringing requirements out of people, and a lot less of my time actually solving interesting problems.

The walls of my office are gray, as is the carpet, the desks, and the walls of the bullpens. There are awful fluorescent lights overhead, and my eyes are dry and tired. I am exhausted at the end of the day because of the sensory overload of people being on constant teams meetings all around me. They speak with their outside voices, like children.

So yes, I love software development, and maybe someday I will find a better job in this field that gives me the kind of challenging work and problem solving that I signed up for, but working outdoors? surrounded by the sounds of nature with the sun on my face? I'm sure there's a catch, but it sounds nice.

Ya i think so. Because i resonate a lot with this comment. I workout and such, but i absolutely love this shit.

that's basically how it already works...

extensions choose on which site they're active and if they provide any available assets (e.g. some extensions modify CSS of the website by injecting their CSS, so that asset is public and then any website where the extension is active can call fetch("chrome-extension://<extension_id>/whatever/file/needed.css" if it knows the extension ID (fixed for each extension) and the file path to such asset... if the fetch result is 404, it can assume the extension is not installed, if the result is 200 it can assume the extension is installed.

This is what LinkedIn is doing... they have their own database of extension IDs and a known working file path, and they are just calling these fetches... they have been doing it for years, I've noticed it a few years back when I was developing a chrome extension which also worked with LinkedIn, but back then it was less than 100 extensions scanned, so I just assumed they want to detect specific extensions which break their site or their terms of use... now it's apparently 6000+ extensions...

You can have decoupled Controllers from Views using React. That's the basis of the "original" Flux/Redux architecture used by React developers 10+ years ago when React was just beginning to get traction.

A flux/redux "Store" acts as a Model -> contains all the global state and exactly decides what gets rendered. A flux/redux "Dispatcher" acts as a Controller. And React "Components" (views) get their props from the "Store" and send "events" to "dispatcher", which in turn modifies the "Store" and forces a redraw.

Of course they aren't "entirely decoupled" because the view still has to call the controller functions, but the same controller action can be called from multiple views, and you can still design the architecture from Model, through Controller (which properties can change under what conditions) and then design the Views (where the interactions can happen).

I was asking more in the abstract. Web UI frameworks usually sit on top of considerable abstraction (in the form of the DOM, eventing system, etc), so I'm not sure your reply exactly answers my question.

in theory "maintenance mode" should mean that they still deal with security issues and "no longer maintained" that they don't even do that anymore...

unless a security issue is reported it does feel very much the same...

"Critical security fixes may be evaluated on a case-by-case basis" didn't exactly give much confidence that they'd even be doing that.

My experience is similar, but I feel I'm actually thinking way harder than I ever was before LLMs.

Before LLMs once I was done with the design choices as you mention them - risks, constraints, technical debt, alternatives, possibilities, ... I cooked up a plan, and with that plan, I could write the code without having to think hard. Actually writing code was relaxing for me, and I feel like I need some relax between hard thinking sessions.

Nowadays we leave the code writing to LLMs because they do it way faster than a human could, but then have to think hard to check if the code LLM wrote satisfies the requirements.

Also reviewing junior developers' PRs became harder with them using LLMs. Juniors powered by AI are more ambitious and more careless. AI often suggests complicated code the juniors themselves don't understand and they just see that it works and commit it. Sometimes it suggests new library dependencies juniors wouldn't think of themselves, and of course it's the senior's role to decide whether the dependency is warranted and worthy of being included. Average PR length also increased. And juniors are working way faster with AI so we spend more time doing PR reviews.

I feel like my whole work somehow from both sides collapsed to reviewing code = from one side the code that my AI writes, from the other side the code that juniors' AI wrote, the amount of which has increased. And even though I like reviewing code, it feels like the hardest part of my profession and I liked it more when it was balanced with tasks which required less thinking...

> Literally every datacenter in the world was going to fail on this change

I would expect most datacenters to use their own local recursive caching DNS servers instead of relying on 1.1.1.1 to minimize latency.