Exactly.
Personally, I gravitate toward book and topic-specific notes and highlights in the book itself and use the notebook for bigger-picture things for which book references play some role. I do a lot of highlighting in ebooks and lately I've started using LogSeq. I'll pull quotes from books into LogSeq and then tag them with whatever #bigger-picture topic I deem relevant, mimicking what I do on paper.
How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?
IMO, you are a better engineer if you understand how the abstraction works, at any layer of abstraction. You need to pick the point of diminishing returns for yourself, but I think it's pretty uncontroversial to say a developer that understands how a compiler works, and will dig around in a hex editor from time to time will be more knowledgeable and more likely to notice issues sooner than a developer that assumes the compiler is a magic hole in which to throw source code into and perfect executables pop out every time.
"But what about what runs the compiler! What about what runs the OS! What about the physics involved in electron transfer!" Diminishing returns I guess? No one's ever said you needed to understand everything, but understanding or at least being aware of a few layers under you seems to have been common sense forever. Taking one abstraction layer step up doesn't really change that.
Yea you're completely correct, any computer science degree worth it's salt will cover computer architecture, networks, basic maths, etc. Do I remember every little detail about how transistors,the memory bus, or every network topology works? nah of course not, but does having a reasonable overview of how it all works under hood help inform system design when you're tackling the hard problems, performance, reliability, security,etc? Knowledge is power, so more knowledge can never be a bad thing.
AI prompts aren't a new abstraction layer, it's automating the same abstraction layer, only with less understanding
It would be like saying being an engineering manager is a different abstraction layer. It's not. It's an entirely different domain, managing people and resources instead of programming machines directly
I don't think that's the point. The point is that if you outsource thinking to a machine, you will lose your ability to think and reason on your own, and overtime become a worse engineer. Maybe the software ai writes will be fine, idk... But eventually, you will be an objectively worse engineer than someone that doesn't need a machine to think and write for them.
“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.
To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.
> I write all my code in assembly on paper then manually translate into opcodes
LOL! There was actually a time (way back when dinosaurs still roamed the Earth) when that was actually how it was done. ;)
(I remember as a kid having to look-up hexadecimal 6502 CPU opcodes on a chart then type in a huge list of hex into the computer to write "machine code" if you wanted anything faster and more powerful than BASIC.)
That's exactly what I did when I was writing code in a paper notebook around 1995. Mainly because I didn't have a computer at home, and I wanted to program more than anything else in the world.
Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.
No wonder we boot up entire browser engines to write simple text editors. But hey, we gotta be first to market to get that VC money, right?
Abstractions are not a convenience, they're a cognitive necessity, compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads.
Technology exists to make it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.
AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.
There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.
Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.
> that you’re choosing to frame as a “best practice”,
I don't follow.
> because you do not want to put in the work.
Yes, just as nobody wants to type opcodes, or write their own http clients, or etc. It's why most of us use higher level languages. Leave the solved things solved, and work on actually interesting/new things! That doesn't mean not understanding, it just means not wasting time on the same boilerplate/code duplicated by millions of developers.
> just as nobody wants to type opcodes, or write their own http clients
This is how you get faster software. You literally look “into” the code, see why stuff is slow, remove the extra work in the library that you do not need, and now your software has a faster server.
Abstractions make software “easy” to build. We’re not looking for done easily, we’re looking for done well.
I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.
The window of what steps technical people should understand in our stack of abstraction is always changing - there is no permanent window we should hold as sacred (outside of a cursory knowledge of the lowest of low levels - being passingly familiar with how machine code works is valuable to everyone) but the levels we should be aware of should exceed the levels that we casually interact with - we should at least be rather comfortable with the level one deeper than the one we often interact with.
There's something interesting in maintaining items built to last when the objects themselves are maintained and kept for entertainment reasons. (Entertainment in the broad sense for enjoyment first and foremost over utility or practicality). I guess it strikes me like a master of maintaining toy trains or something along those lines, both evoking a sense of respect and sense of humanity for the craft and art of the thing, while paradoxically feeling that this is not "actually important" (whatever that means). Like someone being a great soccer player or michelin star chef -- the seriousness of this kind of endeavor is both inspiring and comical at the same time?
Maybe it should be viewed like the sign of a healthy ecosystem; if it can support "exotic birds" like these, it's stable and healthy.
it's incredible how volatile the product and pricing situation is right now. i struggle to find an equivalent industry that has been so all over the place and obtuse
I suspect it's the combination of wanting to capture market share (subsidised plans), being severely capacity limited in GPUs, and having bursty and absurd growth rates. There was speculation that Anthropic might be allocating fewer GPUs to training for a few days to allow people to use Fable.
The actual API pricing seems far more of a stable downward trend, if measuring by equivalent intelligence.
