| ▲ | yulker 3 hours ago | |||||||||||||||||||||||||||||||
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? | ||||||||||||||||||||||||||||||||
| ▲ | graypegg 2 hours ago | parent | next [-] | |||||||||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||||||||
| ▲ | alex_x 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
A farmer producing meat is a better farmer than me even if I hire my own farmer. If we invent a meta-farmer profession (for those who hired a farmer) I will be great meta-farmer, but still suck as a farmer | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | dnoberon 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
Heard a quote I liked today. “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. | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | rootnod3 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
Because the abstractions of old still required you to read man pages and learn stuff. And manual steps are good. At least you know what is happening. The old Unix philosophy. Simple tools that combined become powerful. If you use _anything_ in production, you better make sure you understand the stack. | ||||||||||||||||||||||||||||||||
| ▲ | radlad 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
The best engineers hand-edit .git Edit: But actually, one of my favorite Git explainers is https://wildlyinaccurate.com/a-hackers-guide-to-git/ | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | bluefirebrand 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||
| ▲ | TheSamFischer 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
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? | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | munk-a 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | cortesoft 2 hours ago | parent | prev [-] | |||||||||||||||||||||||||||||||
[flagged] | ||||||||||||||||||||||||||||||||