[dvt]

Engineering has never been, nor will it ever be, about "repetition" or "memorization." This is a relatively new fable invented by those that have participated in ritualistic interview hazing. Imo, there are, broadly speaking, two types of engineers: computer scientists, and programmers.

Computer scientists do science. The end result is a new algorithm or theorem, and they work with lots of math, proof systems, formal languages, and so on. This is a profoundly creative and collaborative process.

Programmers build products for end-users. The end result is the user experience, the bottom line, stars on Github, or whatever. This is also a process that constantly needs feedback, from teammates and from clients.

These are broad categories and sometimes they overlap: an operating system or database engineer might do a bit of both, depending on the hardware targeted or on various constraints. Sometimes you need to be a bit clever to get to your product goal.

This cleverness has nothing to do with memorizing keywords or solving interview gotcha questions. This cleverness can't be augmented by AI, and it can't be rotted by AI: it's something that's innate to people. Their internal curiosity just happens to manifest in the context of engineering because they love the craft.

In many ways, it's like reading a book. You can't "make someone" enjoy reading, some people are just boring and uncurious. In many ways, I feel that people that are threatened by AI are like this. AI is an incredible tool, but it feels like an autistic junior engineer. Sure, it might have memorized more library names or more syntax or can reference some little-known fact, but it fails to understand basic data flow. It doesn't grasp ergonomics, ease of use, etc., etc.

A tool like fata is great if you want to be an AI, but it won't turn you into a good engineer.

[RealityVoid]

> Engineering has never been, nor will it ever be, about "repetition" or "memorization."

Having memory of how to do things and techniques and tools and patterns is absolutely important for solving problems. The very reason experienced engineers are just better at many classes of problems.

> This cleverness can't be augmented by AI, and it can't be rotted by AI: it's something that's innate to people

I argue "cleverness" is a learned and honed skill by exposure and exercise. I just reject the idea that some people are just incapable of original thought. They just didn't get the circumstances to flourish.

[dvt]

> I argue "cleverness" is a learned and honed skill by exposure and exercise.

Even if I were to concede this point, it's certainly not honed by the kind of exercise that OP is advertising. We are deep in Max Howell's "invert a binary tree" territory here.

[knollimar]

Doing leetcode absolutely makes your system design better and you don't deploy algorithms you don't know.

Invert a binary tree is kind of a strawman for the absolutist claim that you don't improve the cleverness by practice, but it's an example that not all the practice is useful

[watwut]

> Doing leetcode absolutely makes your system design better

Only up to the pretty low point. After that, it becomes completely absolutely useless. And people collectively spent astonishing amounts of time training that for job interviews long after the "absolutely useless" bar was passed.

[danielmarkbruce]

> Having memory of how to do things and techniques and tools and patterns is absolutely important for solving problems. The very reason experienced engineers are just better at many classes of problems.

At least in my experience, the best engineers have a vast catalog of problems and solutions, algorithms, architecture patters, data structures etc and almost nothing comes from scratch. The worst engineers do everything from scratch without much/any understanding that the problem they are facing (or a variation of it) has been solved before in 6 different ways with varying tradeoffs.

[apsurd]

“Master all prior art before naively trying to do anything on your own” - also, very much does way more harm than good in a learning context. (it narrows the top of the funnel for no good reason)

The gripe seems to be the negative effect on the team, business/project outcome etc, sure work doesn’t pay you to write your own compiler.

But again, its such a disservice to learning to dictate a shape, largely academic, largely top down (vs bottoms up failing & flailing).

[danielmarkbruce]

No one said anything about learning everything before doing anything, and nobody suggested they were told to do it or how they did it.

And, bad engineers can become good ones. All the good ones were terrible at some point....

[apsurd]

Yes, the main issue I had was regarding how anyone can get good without first being bad. Your comment highlighted a very particular worst engineer persona, as if there was an obvious way they could have avoided it preemptively.

Since we’re talking about learning in particular, my callout is it’s in no way helpful to shame people that aren’t good at something. It’s counterproductive.

[djoume]

Thanks for taking the time to comment. I agree that people have tendencies towards certain interests, I can't remember a time where I wasn't interested about computers, even long before I had access to one.

That being said, people are also inspired by other people or by products, and there are ways to make the learning more effective.

No tools is going to turn you into a good engineer, fata makes it easier to practice regularly and it's that practice that will make you improve your skills

[danielmarkbruce]

Engineering creativity does not come from a blank slate.... people create by combining primitives like APIs, algorithms, patterns, debugging techniques, product constraints, performance constraints, user needs, and blah blah blah.

You can argue that a particular primitive is bad or overemphasized but the ida that real engineering has nothing to do with repetition, memory etc is wrong.

[apsurd]

Well, the inventory of primitives has to be earned. Else they can't actually be composed. Composition requires tacit knowledge. There's a learning pyramid thing that describes it. Just asked chatGPT to jog my memory (heh, heh)

    Remember → Understand → Apply → Analyze → Evaluate → Create

citation: see "Bloom's Taxonomy"

Discussions on learning typically bring up the need for rote learning, repetition and vocabulary building. It is essential, but to focus on it "as the mechanism for learning" does more harm than good. It's necessary but in no way sufficient.

[danielmarkbruce]

> It's necessary but in no way sufficient.

Sure, agreed.

[hsuduebc2]

Sadly the "ritualistic interview hazing" is just reality how you can get ordinary job today. Usually it have nothing to do with the job itself, it almost always could be solved by just ordinary dialog but for some reason. I don't know if it was someone from HR or some proactive manager thought it would be a wise idea to do this type of tests.

I just started to perceive it as an contest full of stupid useless semi relevant bullshit questions when you win the job. I'm kinda invested in the hate, because I'm currently attending interviews.

[jacques_chester]

Focusing on your first point: Memorization isn't everything. But it's not nothing either.

Sometimes it's nice to be able to just bang out some code without looking everything up. IDEs in an IDE-friendly language make this awareness accessible in the immediate frame, but don't necessarily help with having a mental menu of possibilities to choose from.

That said: I find spaced repetition utterly crushing, so I only use it very sparingly.