"Bybon son of Phola, has lifted me over head with one hand."

It weighs 143.5 kilos, or 316 pounds. Modern academics who have never seen the inside of a gym dispute the claim, but Cheick Sanou set a military press (two handed, with a barbell) record of 228kg (502.5lb), so it's not completely out of question that some ancient Greek farmer who never saw the inside of a library could go a little further. After all, everyone knows that the ancients were being poetic when they said they sent a man to the moon in a giant metal tube full of olive oil and liquid air. (Really? They expect us to believe that air can be a liquid? How could a donkey breathe liquid air? He would drown! And with no donkey, how else would they pull the cart they said they sent with the men? Complete nonsense!)

You don't get strong by not lifting weights.

You don't get 1337 by not writing code.

Vibe this, vibe that. Framework this, framework that. Library this, library that. You're oh-so-productive until something breaks and you don't know how to fix it because you never learned how any of it works. An entire generation will be stunted by the use of LLMs in their education. Previous generations were stunted by integrated central package managers like npm and pip. Generations before that were stunted by garbage collection and dynamic typing. Code keeps getting written but it keeps getting progressively worse. Windows has essentially no new features since XP but requires two orders of magnitude more ram to run and clicking the start button has noticeable lag. In some ways, Windows has regressed in features since XP. Ubuntu's latest system requirements are even higher than Microslop Winbloat.

There was a phrase in the startup world: "Kill it with iron." It means that a problem, implied to be any problem, can be solved by throwing more raw compute power at it. ("Big Iron" is an old nickname for large mainframes. ("Mainframe" is an old name for a big central server.)) Processors are cheaper than programmers, after all. In a way this is true; microoptimization of simple algorithms seldom pays off financially, nor does the performance difference between languages for small companies. Big companies, on the other hand, could save billions by cutting infrastructure costs in half by using Java instead of Python or C instead of Java. You don't have the option to do that if your developers don't know Java or C because they never bothered to learn because they could seemingly outsource thinking with npm install lpad or "Hey claude, create a React page for...".

The problem with this mentality is that those things don't actually replace thinking. They replace, at best, the need for certain specific bits of technical knowledge. Because you used the lpad package instead of taking 30 minutes to write and debug a simple for loop, assuming it was your first time writing such an algorithm, you never learned how to write string manipulation algorithms and never gained that extra experience with loop logic. Because you had Claude sloppy-paste a React page for you, you never learned to use React and therefore never learned what a big pile of shit it is and therefore never had the opportunity to gain the wisdom of not using React in the first place. You remain in arrested development as a developer.

Eventually you are going to have to think. Thinking is required to make something new or different. Thinking is what's left over after you subtract pattern recognition and dogma. There are a finite number of ways that existing modules and existing code can be cobbled together to make an application, and, by and large, all those ways have already been implmented by someone, poorly. If your application can be trivially made by installing a bunch of npm packages or telling Claude to slop it up real quick, then it's by definition not novel and therefore most likely worthless too. Even if you decide to use libraries as part of a novel application, you still have to think about the other parts that are novel, but your thinking abilities are stunted because you never bothered to put in the effort.

Previously it took a fair degree of technical knowledge to glue together a bunch of code written by other people. We called them "class cobblers" because all they knew how to do was connect together existing Java classes, classes that they didn't understand and couldn't build for themselves. There was utility in this because the technical needs of most businesses are very similar and they just need someone to make them the same shitpile ecommerce website as the next guy, except slightly different. Some entrepreneurs realized this and created services like Wordpress and SquareSpace and Shopify. It would have been cheaper for most companies to use one of those services, but the urge to own things for yourself is strong among CEOs. Ironically, this cautious urge seldom cascaded down into the development department which gleefully piled up external dependencies and vendor lock-in like it was on fire sale. Class cobblers were in high demand and made good money. Decent money, at least.

Now, with the advent of LLMs, some amount of this class cobbling will lose demand. Wordpress knocked the feet out from under the HTML-cobbler market, and Claude will knock the feet out from under the Wordpress-cobbler market. Much of it, at least; there will always be custom needs and stubborn CEOs out there. I say stubborn not because they refuse to slop-code their entire business, but because they also refuse to build quality software. If you're going to "do it quick" and "do it cheap" then use the quickest and cheapest technology out there, which is now an LLM, not a small army of junior-level developers. Some of the cobblers will move up and some of the cobblers will wash out and most of the cobblers will just transition to using Claude to quickly churn out unmaintainable slop instead of what they did before which was slowly churn out unmaintainable slop by hand. The results will be the same, and after a short time the total development pace will return to previous levels due to the sheer volume of bad code created, just like what happened when the PHP-cobblers turned into NodeJS-cobblers.

The impact on senior developers (developers who can design and implement an entire application from the ground up without help) is that their secondary ability to glue libraries together and read framework documentation and configure options files is of lesser value. The middle class gets eroded. Either you are doing more thinking than before or you are doing a lot less thinking than before, and those who go down the less thinking route will be of even less economic value than before especially as their skills atrophy from disuse.

The wise seniors, and anyone aiming to become senior, will lift more weights than before. The value of a proper developer will rest even moreso on their ability to think, solve novel problems, write quality code, and fix difficult bugs. Nobody cares that you can resolve a weird git problem, Claude will just rebase away the entire commit history. Nobody cares that you know the entire React API by heart, Claude will just plagiarize the latest online tutorials. Your value is that you had the wisdom to run the organization such that weird git problems don't arise in the first place. Your value is that you had the wisdom to use vanilla js instead of React, since what's the difference to Claude? Your value is that you know all the debugging techniques that the arrested developers never learned so when their slop breaks you can fix it quickly and properly. Your value is knowing the zen of software design and being able to reject klunky LLM proposals and instead manually write out a good structure for the LLM to try to fill the boilerplate of. Your value is knowing when the LLM is and isn't a net benefit to the organization. Your value is knowing how to avoid writing entire sections of code in the first place. Your value is in being able to create new algorithms or custom implementations when there isn't an existing module that can be installed or open source project that can have its license violated with a GPT condom.

But moreso, outside of the industry, your value is being able to make bespoke, heirloom software. Software that runs fast, sips memory, barely has any source code, depends on little to nothing else, and is rationally known to be bug-free. Software that doesn't need updates every month because you know when it is complete and when to leave it well enough alone. Software that people actually want to use. You can't make this kind of software by copying existing code or cobbling together existing libraries. The existing code is trash, which is why you're writing this software in the first place. An LLM would only make a copy of the existing trash, as they are categorically incapable of doing anything new. Digital rubble-piles are inherently the opposite of heirloom software and just add one more glitchy, bloated clump of shit onto the existing mound of Electron apps.

So what advice do can I give? For one, don't use LLMs at all, for anything. Not even as a search engine. They certainly hamper growth as a developer but it increasingly looks like they cause bad psychological effects all around. Worst case scenario you can start using them later if Gen Alpha turns out to not have goop for brains in ten years. You may feel like you're missing out on all the supposed productivity, but the point of being a developer isn't to sloppy-paste existing projects. The point of a developer is to make things that are different or better than existing projects. It's right there in the name: developer, not copyist. To do this you need wisdom and practical knowledge. Wisdom can only be had through careful reason and learning from mistakes. Practical knowledge can only be had through hands-on experience. You gain neither by using an LLM. In fact, you lose them by becomming dependent on an LLM.

Second, don't use frameworks at all. You may have to in a job because the goal of your boss is to shove barely-working software out the door as quickly and cheaply as possible. You will not learn nearly as much from this experience as writing it all from scratch yourself. Frameworks are different from libraries. I'm not saying you need to reimplement OpenGL from scratch in assembly, I'm saying you shouldn't use Irrlicht or Godot or React or Spring. Frameworks make structural decisions for you. Frameworks train you to think rigidly within those decisions. Frameworks hide all the important low-level details. You learn nothing by using them, and a high level developer seldom gains productivity from them either. Learn how sockets work. Learn the bare Javascript DOM. Learn Vulkan. Learn to write your own data structures from scratch with nothing but malloc() and pointers. Sooner or later this knowledge will come in handy and the only way to gain it is by implementing it yourself, not reading about it or prompting and LLM.

Often you find that frameworks have little value. They bring a bunch of bloat and headache and could be replaced easily in your specific project with a couple simple files and the right zen. Everyone knows the ancients were being poetic when they said they wrote Unix in two weeks. Other times you find out, all too late, that the framework has inherent limitations which are difficult or impossible to work around, or carry severe performance or development efficiency penalties. Frameworks, in general, only exist as an overarching structure for class-cobblers to glue modules onto because the class-cobbler isn't capable of clarifying their thoughts and properly designing said structure.

Third, never use a 3rd-party library for a trivial task. It's fine to pull in libJPEG or a SHA-256 function. Never roll your own crypto. It's not fine to pull in lpad or Boost. You should probably write and use your own JSON parser, and all your own basic data structures. Clearly you can use your own libraries in later projects. The point of your early projects not to have the final application, it's to learn how to write it, and moreso to learn how to do a better job next time. As you reach a certain level of skill and wisdom you'll find that the projects not already under your belt are increasingly specialized and sophisticated. You'll start to make judgement calls on whether or not a certain specialty is worth your time to learn compared to other specialties. The decisions on this level are things like choosing between learning how to implement an advanced texture compression algorithm or learning how to write fluid dynamics simulations. You, for example, may not have the time and mental bandwidth for both so one might need to be a lean and reasonable 3rd-party library.

Fourth, seek to understand the system at ever-lower levels, all the way down to how a CPU works at a detailed level. You don't need to know how to implement a half-adder with logic gates. You do need to understand how microcode is created and scheduled on the various execution units, and how memory caching works, and how out-of-order execution works, and how branch prediction works. Eventually. Start with where you are but continuously work lower until you reach the bottom and all the stuff on www.felixcloutier.com/x86/ makes sense to you. The code operates the machine so you can't understand the code without understanding the machine.

Fifth, beware of cults. Learn to recognize cultish behavior. Learn to smell irrational dogma. Cultists may or may not be right about any given thing but the issue is that they did not arrive at their beliefs based on logic or experience. Cults often have glaring hypocrisy in their belief system; Rust evangelists preach about universal memory safety, but then turn it off to do anything sophisticated or efficiently. What's the point, then? Haskell actually has perfect memory safety. So does Javascript. Neither pretend to be equal in performance to unsafe languages though. Memory safety brings inherent runtime costs because there's no way to know in the general case if you are going to overrun a buffer without dragging around the length of the buffer and checking. It reduces to the Halting Problem. There's no way to track memory lifetime without restricting what you can do with pointers to that memory, which means that the code must work around those restrictions, sometimes at a runtime cost compared to unrestricted code. Once again, the Halting Problem. The problem is not the design of the Rust language, the problem is the claims and behavior of the cult surrounding it. Treat all words coming from a cult as suspicious since they have already proven themselves to be irrational.

Disagreeing with a philosophy does not make that philosophy a cult. I disagree with the ubiquitous use of functional programming for every piece of software. I have rational behind this and so do proponents of functional programming. Our arguments can heard and balanced, and our assumptions questioned, and our specific technical claims validated or rejected. Then we can mock and flame each other afterwards like proper men on the internet. But most importantly the basis is reason and both of our positions are logically consistent considering our assumptions and value judgements. Cults are not like this. Cults cannot easily admit when they are wrong, nor see major flaws, nor recognize internal logical contradictions. A functional programmer can recognize that a hash table with side effects is significantly faster than a functionally-pure one. I can recognize that an immutable data structure is inherently immune to race conditions. We each believe that one benefit outweighs the other in the general case and also can agree that there are special cases where the opposite is true. Flight control software should err towards lack of errors, video games should err towards performance. Cultists would not be able to accept this. Everything must be Rust, always and all the time. Everything must be Object Oriented everywhere all the time. Because because.

Programming is based in logic and reason. Humans tend to compartmentalize their use of reason, so a vegan programmer is not necessarily irrational or unwise in his software philosophy. The code of a programmer who buys into obvious technological cults should be viewed with utmost suspicion, just like the nutritional advice of someone who doesn't know where several critical B vitamins naturally come from. Make sure you retain your rationality and are always questioning your assumptions and stepping back to watch yourself program to make sure that reality is not in conflict with your beliefs.

If you're just starting out and don't know what to do first, learn basic C then learn assembly then implement all the common data structures from scratch then start writing and finishing simple projects from scratch of increasing complexity as you gain skills. Read about more advanced C features in the process and learn how to make your code as simple and clear as it can be. Read about software philosophy and test those philosophies in code. Some will be disasters but this is how you learn. Seek zen in your code and keep pushing forward and never give up.

If you're already experienced, keep lifting weights. Lift heavier weights forever. You can blow out your back doing squats but ~~you can't blow out your brain~~ you can't wear out your brain writing assembly. When you quit growing, you start dying.

The Stone of Bybon