Why I Hate Frameworks (2005)

Essential complexity is exactly that. The entire game is to separate it from the accidental complexity. My career/life was revolutionized by a paper that is 100% focused on this very topic:

https://curtclifton.net/papers/MoseleyMarks06a.pdf

The solution to eliminating accidental complexity is ultimately presented as a flavor of relational model, which I simply read as "please just use SQL for most things". This perspective has served me exceptionally well over the last ~4 years now.

A quote I like from Chapter 8:

> The relational model [Cod70] has — despite its origins — nothing intrinsically to do with databases. Rather it is an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state. These features are applicable to state and data in any context.

Chapter 9 offers an actual proposed solution - Functional Relational Programming.

At the end of the day, suffering in a cesspit of complexity is a choice. The relational model is the answer for untangling highly-complex (aka high-dimensional) problem domains, especially ones that require arbitrary downstream views of the data. The central piece of magic with the relational model (as applied to the real world) is the query planner. You should start thinking of this as an actual code-writing super AI that can answer optimization questions 1000x faster than your best developers. All you have to do is give it a tiny pile of hints to work with, and almost any arbitrary request will be satisfied in a nearly-ideal amount of time.

If you plan to be a programmer all your life, and a journey-man one at that, then feel free to learn-programming-in-21-days.

If you're planning a career in software, then I think understanding fundamentals (database normalisation, the Order of a solution, the ideas of Coupling and Uncoupling, memory usage versus performance, the impact of CPU cache, multi-threading safely, operating system task priorities, compilers, and a good few more things that underpin the science behind building software, then a degree is helpful.

Not because of the books, you can get those at home, but because of the structure (ie the path through the carriculim) the mentorship from professors, TAs and so on, and most of all the exposure to your peers - the wonder of collectively pushing each other to explore beyond the curriculum, beyond just this week's assignment.

Most of all it teaches intellectual curiosity- that spark some people have to see something in code they don't recognise, understand the novelty of it, and go and find out about it. It's easy to keep up because you have the structural foundations to absorb new things all the time.

ChatGPT can't do the things I do, and even calling it ChatGPT is a shallow understanding of why not. Broadly speaking LLMs are a tool I can use to learn new things, which is great, it knows how to weild many kinds of hammer. But it doesn't understand the nuance and context of building a whole building. One which has never been built before.

Precisely because LLMs are good at regurgitating the past, but understand literally nothing, they only replace programmers who are good at regurgitating the past (writing code) but understand very little about what that code -means- (as distinct from what it -does-)

Of course each College is different, and YMMV, but if you gave the time, and resources, and opportunity to do a formal degree, then I think it worth it in the long run. But like most things in life you get out what you put in. The curriculum is just the hint of a starting point to what you learn there, don't go to "be taught", go to suck the marrow from each moment, to actively "learn" from the challenges you set yourself.

Factories in Java, like the URL hints at, are just bad. Maybe they made sense in older versions for reasons that I forget. Haven't felt the need to make factories in modern Java or in any other language.

For laughs: Interview with an Emacs Enthusiast in 2023: https://www.youtube.com/watch?v=urcL86UpqZc

And to keep things fair and balanced, an Interview with a VIM Enthusiast: https://www.youtube.com/watch?v=9n1dtmzqnCU

"I actually wrote a vim versus IDE comparison. Do you know how much faster vim was? 4.3 seconds! 4.3 seconds I saved every day! All those months learning were totally worth it."

I have since come to believe that this is a trap that many people fall into.

Even a colleague of mine at my current job might be sort of in this track himself at the moment I think. And I don’t feel that he is interested in listening to me at all. Even though we are supposedly on the same team.

I think these kinds of things, when you fall into the trap, is something that you have to eventually realise on your own why it was a bad idea.

Meanwhile I am at the verge of quitting because I find it frustrating that we are working on this thing where it seems I am not being listened to and we are implementing something in a way that I recognise from my own past mistakes as a patently poor way of going about things.

But at the same time, I love the company I work for, and the pay is really good, and I am scared that if I quit I won’t find another job for a long time that will pay well enough to support myself and my girlfriend and our expenses.

Anyway. Point is, I agree with you, there will always be people trying to build these frameworks and what have you.